Intensely Practical Tips for Growing an Indie Studio

People of Earth, your attention, please. Uh I'm Alexis Kennedy. Uh this is what I'm talking about. And in a nutshell, this was my motto for uh many years. It's not a bad motto, but I think this one is better. And that is, I hope, what I'm going to help you do today is to learn from my mistakes, uh the ones I made and some of the ones I didn't make. This is my biography slide. Uh I've been making software uh like 20 years. Only 10 of that is in game dev. Uh I founded Failbetter Games, which is where you've heard of me from if you've heard of me. Uh I made Fallen London. I made Sunless Sea. Uh I really enjoyed running Failbetter, and then I needed a change. I wanted to do more hands-on work. I'll talk about that later in the in the talk. Uh but I went

off and did a kind of ronin year doing a bunch of work for triple A's and learning a lot. Uh and now I have founded with Lottie Bevan, who's sitting in the front row, Weather Factory, uh another studio, where we are making a game which you may notice some subliminal messaging attached to. Uh which has already won a design award, uh although we haven't uh finished it yet, which is really nice. And we do a lot of mentoring of other indies because there are things I wish people had told me coming up. So, here's the the road map for today. First of all, I'm going to talk about what I mean by growth, which isn't necessarily the traditional San Francisco definition. I want to talk to you about what you want out of running a studio. I want to talk about the specific advantages that indie studios have that others don't. We have disadvantages, but we have advantages, too. I want to talk about staying human because I think two things. One, doing the right thing is the right

thing. Two, doing the right thing is the best way to get value out of your team. So, do well by doing good. I want to talk about why I left Failbetter and hopefully highlight some lessons that might be useful to you if you did a studio you founded. And I have one more piece of advice at the very end. So, growth. I do not mean being the next Facebook. I don't mean the kind of aggressive 10x growth that you will hear about in Silicon Valley. I am not rich, and I cannot give you advice on how to get rich. What I can talk about is how to build a human-scale studio where people enjoy doing interesting work and have enough financial stability to be able to continue doing interesting work, because that is key. Without financial stability, nothing else counts. One of the myths that leaks into indie culture is this idea that we are not subject to the same rules that

big corporations are. We are. Kindness isn't enough. Creativity isn't enough. Good intentions aren't enough. They're really important, but everybody is subject to gravity. And what I mean by gravity is crunch. I mean, you start out with good intentions, and people end up working overtime, which [ __ ] their lives. I mean, being one of the 30 or percent of Kickstarted games which don't deliver. I don't believe most of those 30% of games that don't deliver started out as crooks. I think people have good intentions and sometimes fall prey to gravity. And that's the last thing you want to happen to you, right? Running out of funds is much, much worse than not getting funded in the first place. And above all, gravity is people not being paid, not being able to make payroll at the end of the month, whether it's you or whether it's your team. If you take nothing else away from

today, before you write another line of code, before you write another line of dialogue, before you do another picture, make sure that you have an answer for each of these questions. How much is it going to cost to make the game? How much money is the game going to make? And when's that going to happen? So, I am very confident that a number of people sitting in this room going, "Well, duh. It's a business. Of course I have those things." But I'm also very confident that a number of people are sitting in this room going, "Uh I don't actually have answers to every one of those questions." You must. Otherwise, you're not running a business. You're not making a project. You are engaging in an act of faith. And if you have a team, that's irresponsible. So, you should be able to answer every one of those questions without referring to documentation. That has to be the bones of the things built to survive gravity.

So, the reason that you are here today is, unless you are press or unless you've strayed in here looking for the bathroom, which is on the left, then is because you want to run a studio or you are already running a studio. This is why people want to run studios, indie studios. But that's just the how, it's not the why. If you spend eight hours a day, five days a week making games, making games is a really kind of broad category of activity. What do you actually want to spend those eight hours a day doing? Managing people? Coding? Drawing? Designing? Marketing stuff? Giving talks at conferences? Often, people seize onto an inspiration, a studio that they want to be like. You see people do good work, you want to do similar work. You see people um out in the industry who seem to be having a good time. You want to be like them.

This is a good place to start, but you can't replicate a studio by looking at the shape of it from the outside. If you put wings and a nose and a tail and a cockpit on something without thinking about how it actually works, what you get is unlikely to clock much time in the air. Here's a concrete example of what I mean. I'm going to show you a quote, uh something somebody said to me back in about 2010, 2011. They weren't a stupid person at all, but didn't know what it was like being at Failbetter. At that point, Failbetter barely generated any revenue at all, let alone uh you know, floating happily through life in sheer creativity. It's very easy to look at a studio from the outside that has published games and that has like a website where they look kind of professional, where people show up at conferences badges, and assume that things are serene, and if you copy them, you'll end up in the right place.

It's very dangerous to do that. Even you have a more detailed idea of what you want to do on a project, again, if you try to copy the detailed idea without understanding why decisions have been taken, you can end up with something that isn't fit for purpose. This was my business plan, if you can call it that, in 2009 when I founded Failbetter. Yeah, right. Uh has 10 million players. It's got [ __ ] story. So, I'll make a game that's kind of a social Facebook RPG, cuz that's what people were making in 2009. It'll have a great story, so it'll do twice as well. And yeah. So, that didn't happen uh because I completely failed to understand why people were making social RPGs and what made some uh social RPGs successful. As it happens, I'm really glad I didn't uh because if we had got 20 million players, I'd have ended up trying to run a a business that was servicing 20 million players and not making games.

But there was no chance of that happening because I was doing this. So, this is a pithy insight I'm indebted to Lottie for. You wouldn't sit down and say, "I'm making a game that's going to be kind of like that game." I mean, you might, but it's probably not going to be a a a great strategy. You want design pillars. You want key um goals for what you're doing. You want reference points for what you're trying to do. So, do the same with your business. If you're building a studio, think about what you want the studio to be and do, and build it around that. Here are some contenders for design pillars for a studio. Take a moment to look at this and see which of these things apply to you. All of these are perfectly decent ways to run a studio, perfectly decent things to focus on. To me, uh broadly speaking, I'm in the

left-hand column, uh which isn't isn't particularly a category, it's just a list of things that I like. I do enjoy the business side of things, but it's not my main focus. I like getting hands-on, uh more about that later. I'm a story guy, and I really enjoy developing in the open. I like crowdfunding. I like working with the community to get feedback and to find out how to improve games. I find it very validating, and I find it a very clear way of fixing my mistakes. On the other hand, take someone like Subset Games, who made Into the Breach and FTL. They do great work. Uh they are world-class devs, and Justin Ma, one of the founders, told me a couple of years ago that they were never going to run, he said at the time, another Kickstarter after the FTL one. The FTL Kickstarter was successful, uh they made a really good game, um but they just didn't enjoy developing in in spotlight. So, they went away and they made into the breach over 4 years and polished it

in the dark till it glowed like a star and they released it, which is again a perfectly acceptable way of doing it if that's the kind of thing you want to do. So, think about how you want to approach your work. There are a dozen ways to skin a cat. Think about it not just now, but over the next decade. What you want to do today may not be what you want to do next year. This caught me out. So, always keep an eye on what you're in this for, what you want to spend your 8 hours a day doing. These are the design pillars for Failbetter that we iterated towards 2015. This was a slide at the all-hands end-of-year thing. The key things here were everybody keeps their job, everybody enjoys their job, and we do great. So, the third one is the aspirational thing you put at the end of a mission statement because God help me, this is a mission statement. Design pillars for studio are a mission statement. When you hear the phrase mission statement,

you tend to think it's some [ __ ] on a plaque somewhere. And frequently, it is some [ __ ] on a plaque somewhere because it's what people have compromised to fit on a plaque on the wall of an office. So, what you want in your mission statement or your design pillars is a clear idea of what your priorities are. Don't make your mission statement we are going to succeed because everybody wants to succeed. Nobody puts a mission statement on their walls saying, "We are the kind of company that [ __ ] up." Think in terms of priorities. These are those things restated, safety, fun, and profit in that order. And that's important. There's no reason those three things needed to be in that order. We really wanted to make sure everyone stayed employed. We wanted to make sure people had a good time. And after that, money's nice. There's a difference between going for the kind of money that keeps everyone paid and the kind of money that buys you a big gold house. These are the priorities at Weather Factory which Lottie and I run now. And you'll notice we switched the top two

because Weather Factory is quite well funded and it's got a very small team, so it's a low burn. Uh the whole idea was to do a bunch of interesting experiments fairly swiftly, get them out the door. So, we're taking more risks. We're compromising our safety a bit in order to have more fun. Think about what's important for you. And one of the things I realize this can sound extremely theoretical if you're at the start of your career or the start of your studio's journey. If you are thinking, "How the [ __ ] can I get paid next week?" then why think about whether I'd rather be safe or having fun? This can seem theoretical, but I wish I paid more attention to it in 2009 2010 when I was getting started. And it will become, if you are successful, a practical problem much, much quicker than you think. So, you've probably seen the documentary film Aliens. Here are the two of uh the characters

from Aliens. Uh on the left, we have the Colonial Marines M577 armored personnel carrier. On the right, we have Rebecca Jordan, uh also known as Newt. Uh they they have different character builds. And if you've seen the film, you'll know that one of them gets a lot more screen time than the other because one of them leans into her strength, hiding from aliens in ventilation ducts. And the other one doesn't get to employ its um fire-resistant polymer armor um or its outward-facing laser ablative tile in a useful way. Think for a moment about which of these characters you would tend to compare to indie studios and which you tend to compare to AAA. So, every talk you attend during the next 4 days, think about whether the advice you're listening to is useful to Newt

um or to the armored personnel carrier. One of the mistakes I made a lot in the early days of Failbetter is I'd go to talks given by uh people from big mobile studios, for example. And they'd say, "You need to do these eight things in order to increase retention by 0.03%." And I'd do that and we'd increase retention by 0.03% and that would mean we kept four extra players each week because we were tiny studio without big numbers, so that was useless and didn't show up on our bottom line at all. Here's good advice. Uh it's good advice in the context of this talk. I think it's good advice generally. I don't know if Paradox qualifies indie. I don't know if Paradox know if Paradox qualifies indie. Uh but you are going to have dozens and dozens of things your company is bad at or unremarkable at and a few things your company is good at. If you try to spend your energy fixing all the things you're not great at, you're going to waste all your energy.

Here's the bad advice from a much more talented and eminent game designer than me for indies most of the time. If you are making Nintendo's crown jewel platform launch exclusive game and you need to hold it back for 6 months to get 10 out of 10 rather than 9 out of 10, this is probably good advice. If you are three indies working from their back bedrooms and you're going to hit uh negative cash flow in 3 months, then you probably want a game that isn't great rather than a game that isn't out. Same guy. Great advice for indies. Uh just because it's it's not uh an indie source doesn't mean it's bad advice for indies. This I wish I'd listened to I wish I'd known when I was making Sunless Sea. Sunless Sea, we made the home port for London first and then did everything else. And it worked out okay, but what should have done, and what I think is often good advice, is to get the core loop of the game and

the core activity right first and then go back and look at the introductory experience. Here is some more bad advice from an unimpeachable indie source. And I know it's bad advice or I believe it's bad advice because Rami said it was bad advice when he gave a talk last year here, I think. Rami told a group of game design students when asked, "Should I stay in school?" "No, you should drop out because then you'll learn more stuff and you'll get life lessons and um afterwards the talk organizer came up to him and said, "For God's sake, um this is not the Netherlands. South Africa does not have a social safety net uh and what you've just told these students, you know, could destroy their lives uh because staying in school is their best chance of having a good life." Every talk you attend, think about whether it's going to be useful for you. The biggest trap is is, you know, big studios will have a voice that may not be useful for you. But even other indies may give advice

that isn't useful for your specific circumstances. Think about it critically. These, I think, are the things that most indies have in common as advantages that big studios often don't. You don't have to spend all the money. You don't have to do all the things that big, real, serious studios with lobby art do. You are not prevented from making decisions quickly by five layers of management. You're also not protected from the consequences of your decisions by five layers of management. I'll talk about that in a moment. You're a small team full of people who are engaged. You will have a deeper bond than you will in a big organization where people only meet at the water cooler. All else being equal. Low budget's really straightforward. This is a a UK-based entrepreneur uh who I asked for advice a few years ago um what I said is the thing you would say to a studio first that is trying to grow. And he said

this. If you put more pounds into or more dollars uh into a project, you don't necessarily get more dollars out. There is a relationship, of course there is, but the relationship is much less direct than people think. And if you really, really, really, really want the game to succeed, it's easy to start flying your whole budget into it. Every pound you spend on the game or every other currency of choice you spend on the game is a pound you have to make back in sales at the end. If you don't spend it, you don't have to make it back. Always bear this in mind. Constraints. So, you will hear people say or you will say yourself something like this. What does a proper business do? So, first of all, a proper business has budgets, schedules, revenue projections. And you want those. Those are essential. Proper business has employees. You probably want employees even if you're the only employee of your studio. You need a team. You can't make games

without personnel. Proper business uh companies, proper businesses have offices. You don't necessarily need an office. Lots of indies work from home. Or maybe often in their living rooms. You probably need payroll. You probably don't need a payroll department. You probably need an HR policy. You probably don't need an HR department. You definitely don't need lobby art. Don't copy what proper businesses do without thinking about it in an attempt to become a proper business. And here's a really good example of what I mean. Press releases that look like this. And I've I've put out press releases that look like this. Uh and I nod off rereading them. We know what press releases look like. We know what press releases are supposed to look like. If we want to be taken seriously, we tend to put out things that look like this. When we could do this.

Dan Marshall's a solo dev in the UK. He's a very funny [ __ ] Uh you know, you can't say this in a press release. I'm not wasting my time day in day out needing for football without some sort of kickback. We're very excited to release our new football game. No, I I don't know how well Kick Men did. Pretty well, I think. Um but I'm telling you about it at GDC a year after release because he did something unusual and distinctive and he didn't just try to to copy other press releases. Not everyone is as funny as Dan Marshall. I'm not. So, not all of us can make entertaining press releases. But don't just do things because they're done that way. This is me in my living room with Sonia, my daughter, um doing a live stream for the Cultist Simulator Kickstarter. Sonia is explaining um what Habibi babies names are um and which one she likes more

because I was doing a stream and she wanted to get involved and she insisted on getting in. If you are doing a stream, if you're recording a Kickstarter video, it's it's very easy to get sucked into the idea you need to look professional. You need to have a printed backdrop and you need to sit there and look serious and give the impression you're in a meeting room in a AAA studio. People who are backing your Kickstarter know you're not in a meeting room in a AAA studio. They know you are one or three or five people sitting in a room somewhere. You don't need to pretend to be a proper business. This is how Cultist Simulator did in Kickstarter. It didn't wasn't a problem Sonia being um in the live stream. It wasn't a problem Sonia being in the live stream because she now wants to be in every live stream I do ever. Uh But that's a separate issue. Right, immediacy. I said earlier that you can make decisions quickly and you are not protected from making bad decisions by five layers of management. So, what you've got as an indie is very short iteration times.

Make a decision, act on it, see the effects, change your decision, act on it again, see the effects. In order to make this useful, in order to catch the bad decisions you're not protected from, everybody has to know these three things: what they're doing, why they're doing it, and why they want to do it. So, your job as a studio head or a team lead is to make sure they know those things. This is your number one job, right? It's managing information flow. Think about how you would manage information flow if you were designing a game. A lot of information flow in companies is works like this. You get an email explaining what you want to do and you do that for the next month. Imagine designing a game where you get a big text dump at the beginning of the month. Never refer to it again and then then check in at the end of the month to see where it's done. So, you want small snippets of information constantly. You want to work and inform people all the time. You want to check their understanding to make sure that they

know not just what they're doing, but why they're doing it so they can change direction intelligently if something goes wrong. And here's a really useful tool for giving people information constantly in small digestible snippets. Design pillars. Safety, fun, and profit. Of course, we're making a game that is going to have a modest budget in order to ensure that we all have jobs rather than pushing the boat out and plowing money into it. Same with actual game projects. Same with actual design pillars for actual games. Loneliness, exploration, survival were the core pillars of Sunless Sea and I banged on about this all the time. The effect of this was when I said the boat needs to look really small in the middle of a vast dark ocean, uh my UI developer said straight away, "Of course, yes, because loneliness is is one of the core values of the game." Any kind of design pillars, snippets of information you keep revisiting, decisions you make up front and then refer back to

for periods of time as well. So, last year, the game sold well. We actually have more money than we expected. This year, we're not going to focus on improving our cash flow because that's okay. We are going to focus on finding bigger audiences. Everybody in the studio knows that. Everybody in the studio acts on this all the time. When you give somebody a jump button in a game, you immediately give them a wall to jump over to check they've understood the jump button. If you give somebody a crouch button, there will be a pipe. If I'm trying to make sure my daughter knows it's her bedtime, I will say, "What are you going to do, Sonia?" And she'll say, "Clean my teeth and get into bed and wait for you to come and read a story for me." Ah. You need to check understanding with your team as well. But if you check understanding with your team by saying, "Repeat back to me what I've just said to you," they'll lose patience fairly quickly. So, here are three non-annoying ways to get them to to indicate their understanding. One is to have them explain it to somebody else while you're present. This has the added advantage they will

probably understand it better while they're explaining it and the other person will understand it. At the end of it, you can pick up on issues of um confusion. Another is to get them to write documentation. Another nice outcome of that is you have documentation at the end of it that other people can refer to. And another is to build out a really quick prototype. Do you get what I'm saying? Okay, let's see how it looks in the build. Let's spend half an hour doing it. That's not quite what I meant. Let's let's sort this out before we go further. And one of the other advantages and disadvantages of having an indie studio without five layers of management where people are making decisions on the floor day-to-day is there is nowhere to hide from responsibility. And that's great because you want people to be responsibility responsible for their tasks. To make them responsible, you need to distinct the buck. Every task, if you want people to be responsible for it, one person has to be responsible for

it. If three people are responsible for it, nobody is responsible for it because everybody thinks it's somebody else's job to do and they'll focus on the task that they are solely responsible for. So, make sure anything you want to be done in the studio has one person responsible for it, whether it's you or whether it's a number of the member of the team. And they can pass on the buck, of course they can. You ask a team lead to get something done, they will pass that to their team. But it needs to be passed, not thrown. Somebody needs to acknowledge they have the buck and that they're responsible for it. If somebody doesn't acknowledge responsibility, they don't have responsibility. And this is what you need to make sure everybody understands. If you have a buck, the tasks problems are yours. And you have to ask for help or to call out delays. That's essential. If a team member has too many tasks or the tasks are delayed, they need to be able to flag it and you need to listen to

that because deadlines come in two kinds: lions and sharks. Deadlines that you can see coming, deadlines that you understand your liability for, whether you are going to hit them or not, are lions. They can kill you, but you can see them coming a long time off. Sharks, just as dangerous as lions, but you won't know they're there until your leg is already gone. So, deadlines are not less dangerous if you think they're okay. You need to make sure people can flag when tasks are being delayed and when deadlines are at risk. Right, the next four slides or so I'm going for possibly the highest um profanity to to minute ratio of a indie talk so far, so I apologize. I should have said disposition. Everyone [ __ ] up. Responsibility means that if you [ __ ] up on a task, it's your [ __ ] up and you have to fix it.

You need to give your team room to [ __ ] up. If you are looking over people's shoulders to the extent that they don't have room to [ __ ] up, then you are [ __ ] because you have paid a team full of people to do work that you are now doing yourself. If you give somebody ownership of a task, that means giving them room to [ __ ] up. If you give them responsibility, they will learn to avoid the [ __ ] ups themselves without you looking over their shoulder. But if somebody [ __ ] up in an indie team where you have a number of self-motivated people who care about what they're doing, are engaged, usually the most you need to say is, "Please don't do it again." Let them know they [ __ ] up. Don't belabor the point. Don't try to make it a big deal. Move straight away to how the problem is going to be fixed next time. There's two reasons for that. One is so that the problem will be fixed next time because good intentions, "Please don't do it again," often aren't enough. If they were, they probably wouldn't made the mistake to begin with.

The other is that you give somebody a way to save face and channel their embarrassment or their annoyance into fixing the problem. Give them room to fix the problem. Don't make a drama of it. You very nearly rarely need to make a drama. Super important. When you [ __ ] up, and you will, tell your team. There are three reasons for this. Number one, they probably already know. Number two, people respond very positively to leaders who admit their [ __ ] ups. If you keep on admitting [ __ ] ups, then you're probably incompetent and need to change jobs. But if you if you if you do a good job except when you don't, people respect owning it. The third and by far the most important thing is psychological safety again and again comes up as one of the things that makes teams work. People need to be able

to admit they [ __ ] up. If you as the boss find it embarrassing or difficult to admit your own fuck-up, it's going to be twice as hard for your team who aren't the boss and don't have higher firepower. Ever difficult for you, it's more difficult for them. Show the way. So often this is fine. Often everyone's on the same page. Everybody wants to to make a good game. Sometimes people keep [ __ ] up. Here are some really practical pieces of advice on how to deal with somebody who keeps [ __ ] up. Don't procrastinate. If you leave the problem, it will just get worse. As soon as you have a three is a you know good heuristic for a a number of things three specific examples in the fuck-up. And I mean specific. I don't mean I don't like your attitude or I don't think your work is of a standard that that we think we should be doing or I mean you know this thing happened this thing happened and you said you would do that and you did. As soon as you have the three

specific things, sit down with them and talk about how you can make sure things are going to be different in the future. Come on the suggestions about how to change stuff, but listen to theirs. You never have the whole picture. Maybe they didn't [ __ ] up. Maybe they did, but there were reasons for it you're not aware of. Maybe they have a better idea of how to fix problems than you. And make sure when they leave the meeting whatever steps you've taken to resolve it, there is at least one thing they can focus on. Indie studios are um places of complicated intellectually demanding absorbing work where people think about a lot of stuff all the time. If you give them five things they need to do in order to fix the problems, they'll forget four of them before they're out of the room. They'll forget the rest of them by by the following morning. Give them one thing they can focus on in between their other tasks so it makes it possible and practical. You've got a team of five.

You're managing five people directly. I think five people is about the number you can manage directly. You should be having a one-on-one with them every week and you should be spending probably half an hour. That means two and a half hours a week. It means 10 hours a month. For an indie studio head, that is a lot of time. If you're anything like me, you can probably feel the creeping finger of panic at the idea that you're spending 10 hours of time away from doing the other things you need to do. But look at the middle bullet point. Remember your job as a studio head is to manage information flow above everything else. And it's to make sure that everybody else works effectively as they can. You can focus on your own work being as effective as it can be or you can focus on five people's work being as effective as it can be. The multiplier effect is much more powerful. So one-on-ones take lots of time but they are a really valuable way to spend your time. And here are two things about one-on-ones I think people often get wrong. I've got them wrong in the past.

Don't think because you are sitting at the desk next to somebody 40 hours of working week a week that you don't need one-on-ones. Let me say that without double negatives. If you are sitting next to somebody 40 hours a week talking to them all the time, you still need one-on-ones. The kind of things they say to you when you're alone and not in front of a team will be different. There are things they won't be comfortable raising in public. The kind of things they will say when you ask them specifically to reflect on what the problems are at the moment how the thing worked out last week you agreed to do are different from the kind of things they will think about when they're sitting staring at a a a copy of Unity trying to get the damn build to compile. So give them space to think about what their blockers what their problems are what the things in the studio you haven't noticed are, what the relations with other people are, what their concerns about the upcoming deadline are. Give them time and space to tell you that. And secondly

don't skip one-on-ones. It's very easy to do. You've got lots of stuff you need to do. If if you skip it, you have to change it, schedule it the next [ __ ] day or the next [ __ ] afternoon. Because if you skip a one-on-one, you are saying to your report you are not my top priority. As a manager, your priority is your reports. You want to make sure they are as effective as possible. Talky [ __ ] mammal warmth. One-on-ones are a really good way to build rapport. I could have said rapport. I really like the phrase mammal warmth because it annoyed the hell out of my old co-founder. But I I like the greasy feel it gives. If you're working in a team of uh less than two dozen people, it's very hard to hide bad news. And I've just spent several slides telling you how important it is to share information as effectively and constantly as possible. If you try to hide it your left hand is fighting with your right. And you probably won't succeed. People

who work in indie teams are smart. People who work in game dev generally are smart. Uh it's an intellectually demanding uh job. People will gossip. People find back channels to find information. They'll either find out the bad news you're trying to hide or they'll make up worse bad news. And they won't trust you. And when you have to give them actual bad news publicly they won't trust what you say about it. So be as transparent as you can at all times. Like a lot of other advice in this talk, it's not just about doing the right thing which is the right thing. It's also about doing the pragmatically best most effective thing. Takes a lot of effort to hide information in a small team. Another pragmatically uh uh another morally appropriate but also pragmatically useful thing is credit people by name. Not you know every sentence you give every time you you you you mention the game recite the list of credits because that turns into an Oscar speech every time you open your mouth. But when somebody has done specific work, when somebody's responsible for a

piece of really great art or UI work, when somebody's responsible for keeping the back end stable and that's under appreciated because nobody ever looks at a really stable game goes wow. That's some great work. Uh as a player mention the people by name. Be generous. It costs you very very little. It's always tempting as a studio head to get egocentric. And people really appreciate it when you don't. So back to doing well by doing good. Here are some ways to ensure that your team feels well treated and build rapport better. This is an unglamorous one. Every decision you make that affects how your team is going to interact, how the business is going to work, get it in [ __ ] writing. And it doesn't have to be lawyered up. Obviously often you want legal contracts, but if you just put something in an email so everybody understands what's going on

you're going to clear the ground for people having better relationships. Some concrete examples. Lots of teams get going. They make a game. People are coding together. They've got a prototype. It's going to be on Steam at some point and you know there's the indie apocalypse so we don't really know how much money there'll be in it and it's a bit vague and and you know we'll decide how [ __ ] that. If somebody offered you a job and you said how much does it pay and they said uh you know we'll work that out later and you said when do I get paid when's payday and they said well you know it'll it'll be at some point. You shouldn't take the job. And you shouldn't make that arrangement with other people as well. Decide what the compensation is going to be for working on the project up front with your team. Be specific. IP assignment. You're all working on something. People are doing little bits of writing. Somebody's done some art. It's all coming together. The game might never be finished. It might not be worth

anything. So you haven't talked about whether the IP belongs to the company or the individuals. Get it in writing. Next week somebody says we I think this really should be science fantasy and somebody else says no we agreed it was film noir. How do you decide who's right? Who owns the IP? One of you wants off the project. They still feel they have some sort of involvement with it because they drew that great art. You need to know who owns the IP. Even if you then do something generous, you need to have a basis a firm basis to do something generous with. Lots of indie teams have loose structures. You get people who are core. You get people who are salaried employees. You'll get people who are doing bits of freelancing. You'll get people who uh have stock. You'll get people who who are sort of hanging around helping out. If you go to GDC uh with a colleague who's a freelancer and they want to give out business cards, whose business cards they are handing out? Are they promoting your company or are

they promoting their own freelance work? Both are perfectly reasonable approaches, but I've seen people fight over this because their expectations are different. You're at GDC on my dime so you should be handing out my business cards. Well, you know I need to make a living. Make sure the relationship is clear. This one's lethal. We trust each other so why do we need to put things in writing? If you are working with a trustworthy friend you've known for years who does not and will not screw you over, what happens when a close family member gets ill and they need to leave town and they can't work on the project anymore? Maybe they do and maybe you come to a really generous arrangement um where uh they draw salary while they're they're off for for 6 months, um or they keep their interest in the project. But, you need to have a firm basis to make that decision on. Agree with them up front. Things that proper companies do and

don't do, things that you might do. People need to get paid. There are a bunch of of ways you can motivate people by paying them that aren't immediately the pink ones are the things I tried at Failbetter. The the lavender one, the attractive lavender one on the bottom left is something I wish I'd tried at Failbetter. So, I'll talk about that first. I think in an indie studio, people should know how much each other are paid. I chickened out of doing this at Failbetter and I regret it. It's hard to share this information. People generally know if somebody is paid what might seem to be over the odds, whether it's because they're a founder or whether it's because they have an unusual skill set or whether it's because you had to pay them to make them come on board more than you'd expect. People want to know that. If you get some sunlight on it, at least people have a chance of understanding it. Hiding information often breeds resentment. Lots of projects have revenue share arrangements. If you're running a studio, I kind of

prefer having a profit pool for the whole company to revenue share for projects for a couple of reasons. One is that if the company doesn't does badly, doesn't make much of a profit, you can just withhold the profit pool. But the other is that if you've got several projects people are working on, and one of them makes all the money and one of them doesn't, that could be resentment very quickly. Everybody gains something from a um from the company doing well. Everyone feels some participation in the business. When you motivate somebody by paying them, giving them a salary rise is quite an inefficient way to do it because they get a salary rise and the next month that's the salary they've always had. You have to keep on giving them salary rises in order to keep on increasing their motivation. And that's usually not sustainable. Profit pools are nice because they happen once a year because people get a burst of enthusiasm from knowing that they have benefited from the work they did over the course of the year. Minimum decent salary, this is one of

the things we we did at Failbetter that I believe they're still doing now, which I'm quite proud of. We decided a number that we needed to be able to pay people for them to have a fair shot at renting a reasonably nice place and being able to cover transport and not having to worry too much about money. We never paid anybody less than that once we established that policy. However junior they were. So, that meant people understood we had a basic commitment to our staff's well-being. It meant that junior people at the start of their careers were living in relatively comfortable circumstances. And it meant that um we could actually expect a better quality of work from people who didn't have to commute necessarily for the very long periods of time that you might need to do to live in London. So, you'll notice I put that at the right-hand end of the cost axis because, you know, you can only do that if you're a reasonably successful studio. It's completely impractical for a starting out studio, but think about it. Talking of things that tend to be irrelevant to startups,

um and very relevant to studios that have been going for a bit. Think about benefits. It's easy to think these are the things proper companies do, but there are reasons people want this stuff. Some companies Some countries it's more important others. Some countries have better social security than others. Family friendliness is something that's very easy not to think about when you are starting out, especially if you have a young team, and it becomes more and more important as the years go on. Catches up with you. Sunless Sea wouldn't exist if we hadn't been a family-friendly company. I was having to pick my kid up at half past three and then work Saturdays. It's also a concrete tangible signal you can send that you are interested in gender parity on your team because disproportionately, although of course not exclusively, maternity leave tends to be a point of tension in companies. So, it is that if you are interested in diversity, there's a tangible commitment you can make to say that women are welcome on your team. Right. A topic I have strong feelings on.

This gentleman is Alexey Stakhanov. Alexey mined coal in Soviet Russia in the '50s. And on one occasion, he put a few hours extra in. He worked really hard. On a single shift, he mined 227 tons of coal. Single-handedly person. He didn't. Of course he didn't. He had a team of helpers. The thing was a propaganda operation to ensure to encourage people all across the country to break their backs putting in extra time. This obviously has some similarities to labor practices persistently in the software and in the in the games industry. The myth of the hero. And as I said at the beginning, all of us are subject to gravity. Just because you mean well doesn't mean that you are immune to the allure of crunch and the dangers of staff burning out. So, I'm really proud of this. This is a thing I posted in the Slack

channel at Failbetter when Sunless Sea was nearly done. People responded very well to it. The game launched on time and did well. But, this is the key point. I could give that speech because the hay was in the barn. Because the game was in a place to be released. If I decided the game actually needed eight more weeks work and we were to launch in 2 weeks, I couldn't have given that speech. 20 years ago, somebody said this to me. I've never forgotten it. The point at which you decide to crunch as a team is not 2 weeks from release when you say, "Well, can you put in a few hours extra at the weekend?" It's when you don't build an accurate enough schedule or when you don't require your team to build an accurate enough schedule.

And don't get me wrong, estimation is [ __ ] hard. I've been making software for 20 years. I'm still not very good at estimating time. A couple of good talks yesterday about people having problems with estimation. It's difficult to do. I've got some tips about doing it, but first of all, I want to address this. It's a very tempting myth. You have to bleed into your keyboard or the magic phoenix of art won't arise. Nobody says this. Nobody says this. Building's are late, but nobody pretends you can't schedule a building. And nobody thinks the Moscone Center is less complicated than the average game. I do not believe that the human body is less complicated than the average game. All these are complex difficult fields of endeavor. All of them people have to

estimate for. We can estimate for things. We can build better schedules. The fact that it's difficult should not dissuade us from trying because it's vital. And if you don't believe me, believe this man. Google it. You may have seen this on Gamasutra a year or three ago. Money points there are crunch generally makes things worse. Of course, if you manage to drag the game over the finish line, you'll feel you saved it. Maybe if you hadn't crunched, it would have been a better game. It's very hard to say that, but again and again, Tzour found that the 770 projects he his team reviewed, ones where people had crunched did worse. And crunch [ __ ] people up. Look at this. Health, productivity, relationships, morale, employee engagement, even increases the risk of alcohol abuse. So, don't do that. The reason There are lots of reasons, but the biggest reason that we are so bad as humans, as game developers, as software

developers at estimating stuff is that estimation is something you tend to do at the beginning of a project or a sprint. And then you don't think about it again until you next estimate something. And you don't know whether or not the estimate was right the first time. So, in terms of the iteration loop, in terms of improving your skills, it's very hard to do. So, fix the loop. At the end of every sprint, assuming you're using some sort of agile methodology or every month or some other time period if you're not, look at the estimates you did in the previous sprint. See how accurate they were. Use that information to feed into your next set of estimates. Make sure your team does the same. Nobody wants to. It's one of the least fun parts of game development, but it stops people crunching. It's like flossing. Nobody enjoys it. Here are three ways to try to make people, including you, do it and do it a bit better. First thing, another pithy adage from Lottie, which really struck home to me when I first heard it. You can be in the business or you can be on the business.

It's very hard to be both at the same time. You want, ideally, somebody who is on the business, looking at the big picture, thinking about deadlines and estimates, and people who are in the creative and technical trenches. Ideally, then you want a producer or a project manager or somebody who is interested in the business side. If you're in a small team, you can't always get that. That's life. In that case, put your producer hat on maybe one day a week. Stop thinking about when you're going to add this feature and exactly how the code is going to work. Pull back. Look at the estimates. Look at the deadlines. Don't put it off. Top down and bottom up. Everyone's bad at I got better at estimating when I started thinking top down, okay, this this level will take 3 days. Other similar things have taken about 3 days. Bottom up, also this level contains these many assets. Each of those takes that many hours. Add 10% for this, add 15% for that. Okay,

these are ballpark the same. Let's meet in the middle. It's a really fudgy way of doing it, but it gives you a basic cross sanity check. And any estimate is always better than no estimate. That's really important. The third thing is a dirty trick to use on your team. When they say, "Ah, I don't know. You know, how long does art take?" And you say, "Okay, well, I'll put that on our Steam page. How long does art take?" Release date, I don't know. And at that point, you know, they may as as they often did before I left Failbetter, say, "Fuck you, Kennedy. I don't know what you're doing." But often it was, "Fuck you, Kennedy. I don't know what you're doing. Okay, it'll be 5 to 10 days, but don't hold me to that." Brilliant. 5 to 10 days is more information you had 2 minutes ago. Also, next time round, you say, "Last time you said 5 to 10 days." And they say, "Oh, yeah, actually it was about 6 days. So, you know, I was a bit pessimistic. Maybe I can work with that." Most important thing about schedules, this 20% contingency.

You put together a schedule, it's 100 days. You've only got budget for 90 days worth of work. You need 20% contingency because people say that's a good heuristic. Broadly speaking, you can expect that kind of overrun. So, you put in 5% contingency. 105 is closer to 90. Remember deadlines. Remember deadlines are sharks or lions. Contingency is time you put in a project for the stuff that will go wrong that you don't expect. And you can't know it'll be 20%, but after two decades of making software and having talked to a bunch of other people who do the same, 20% is the broadly speaking the number that keeps coming up for this kind of thing. Not Yeah, I saw you guys recognizing some of this stuff. Uh not you're a bit slow, or you're a bit lazy, or you could have worked harder, but [ __ ] happens that you cannot predict. It doesn't snow in England. Uh it snowed in England over Christmas, and I lost 2 days cuz I had to look after my

kid for 2 days out of a 10-day sprint. 20% contingency. The only chart in this I'm very proud of of of this. Uh this is head count at Failbetter during the time I was there. Only one person ever resigned uh because they um actually their spouse got a dream job in the US, and they had to move away. Uh we lost three people in 2012 because the company was 6 weeks away from not making payroll, and I had to lay people off. Some things about that. You want to retain people if you possibly can, because the longer they're with the company, the more valuable they are. You treat people decently. This is the doing well by doing good thing, right? If you may build a human studio, people are more likely to stay. And every time an employee of 2 years or 3 years or 5 years standing walks out of the studio, they have a head full of detailed information and knowledge about the processes, relationships they built with other people, understanding of how the team works, all this stuff. You want to keep that. People get more valuable as they go on. People will eventually move on, and you need to bring in fresh blood, but keep

people as long as you can. And if people know that you're making keeping them a priority, they will trust you more. Sometimes [ __ ] goes wrong, and you run out of money. Here is some basic advice for the day that as a studio head, you will probably have to face at some point. Get it done quickly. Do not leave people lingering. Give them an answer as soon as you can, and get it over with. Think about how not to have a colleague walking past a desk full of a table desk table full of other colleagues, island table full of other colleagues, carrying a cardboard box and weeping. If you have to send people to lunch early, or you have to meet with somebody early in the morning, so you avoid the humiliation of the last day people will remember at your team. Find ways to do that. Never say this. It's not true. If you are letting somebody go, you still have a job, and they don't. And if

you tell them that it's hurting you more than them, uh they they won't react well, and they shouldn't react well. And really important, when you are interacting with the people in your team who may become friends, who may invite to your house, whose shoulder you may cry on, or who may cry on your shoulder, always remember that you may have to have this conversation with them. So, I ran Failbetter for 7 years, and it was my dream job for a lot of that time. And towards the end of that time, I became became aware gradually that I wasn't having fun anymore. I had lost track of why I was doing what I was doing. I was spending less and less time doing hands-on work, more and more time doing managing managers. And the thing about mental fatigue,

the thing about chronic human fatigue, is it builds up over time. When you're running a studio for 7 years, some of it can be very tough times indeed. And I gradually started to realize I wasn't enjoying it, and then it it I I quite suddenly realized I wasn't enjoying it at all. So, I decided to really quite suddenly to leave. It took me a week of of thinking and soul-searching and having serious conversations, and then I wanted out. Because I wanted to do something with very little responsibility during the roaming year I mentioned at the beginning, working for larger studios. And um I wanted to do smaller projects that I was more hands-on with again. But we had a problem. And this is one of these problems that's theoretical and sounds like a great problem to have until it happens. I wanted to walk away. I owned most of the studio. There wasn't enough money in the studio to buy me out. We did have a couple of preliminary conversations about selling the studio, but nobody wanted to be sold. So, what did we do? [ __ ] it. Boo [ __ ] hoo. I only get

360k pounds. It's still more money than I expect to see in my life, honestly. I left a lot of money on the table so that the company could continue to exist without going bankrupt. Because priorities. Because you decide at the beginning whether you're in this to make a lot of money, or whether you're in this to build a human studio. You decide which of safety fun and profit is most important. And I think this is true, and this may be relevant to you someday. The fact that you've been in the studio from the start doesn't mean that you are all there is to the studio. Quick advice. Plan for it. Get a shareholder's agreement, whatever the equivalent is in your your country, uh just in case you need to leave. Don't make the mistake I made as a typical founder mistake of acquiring jobs over time, accruing things I didn't quite trust to give away, so the fatigue built up. Keep your email address as for your company and your home address separate. I nearly didn't come to the US to do this talk because my ESTA, ESTA, uh

reminder went to my old Failbetter address, not my personal address. Uh and my ex-wife still gets mail addressed to Failbetter, uh which which annoys her to this day. So, keep it separate, even if you're convinced you're going to stay with the company forever. It's just good sense. And do think of it like a divorce. It's going to be weird when you walk away, even if you do it on amicable terms. Always always keep track of this. Why you are in it. What it's for. Illustrative statistic about probably the number of things you'll want to do on any given day or any given week running an indie studio. Illustrative statistic about the number of things you will actually get to do. Time or resources or energy. 100 minus five.

So, you are going to have to reject um most of the things you want to do. And either you can let them happen by accident, you can let it fall on the floor, or you can decide which things to drop. So, decide which things you focus on. Make that a conscious decision. Know you cannot do everything, and fix on it. And here, if you remember nothing else in this talk, here are the five things I think are most important. Have a [ __ ] budget. If you already have one, great. If you think you'll get around to one, do it before you write another line of code. Never forget why you are running a studio. Making games for a living is the how. It's not the why. If you [ __ ] up, own it now. Put everything in writing. And not 10% contingency, 20 [ __ ] percent. And that's it. Some little message.

We probably have time for one or two questions if you'd like to ask. If you'd like to ask a question, please come to the mic in the middle there. And uh I have one myself. Go. So, on your your list of new priorities, it's the hands-on auteur kind of uh thing for your new for your new studio. Does that mean that you're trying to hand off more of the studio head kind of things to to other people in the team so that you can do more of the, you know, direct design, direct hands-on work? So, right now, uh what I'm doing is is uh the team is on this stage and in the front row. Uh there's two full-timers and half a dozen freelancers. So, we're working more with freelancers, which keeps the studio small, and it means that there's less management involved. In the longer term, I will want to grow, and I think, yes, one of the mistakes I made at Failbetter was not handing enough off enough. It was a little bit of a benevolent autocracy. And I think that what I said about giving people responsibility also applies to management as well. That's what I say.

Okay. You go ahead. I You mentioned one-on-ones being a really important thing. Yeah. Sitting down, taking time with people. Can you give me like an example, like one or two examples of questions or topics that you brought up that you felt Yes. So, there's two There's two things you should do. And this will basically get you three three questions really. One is What is how's things? Um But the the two questions to ask people are What problems do you have right now? Because everybody has problems. And everybody who If they don't have problems, they'll invent them. They want to talk about them. So, ask people what problems they have, what's stopping them doing their job. And ask them the problems we talked about last week that we agreed these things to fix, how did that work out? Because it's very easy to forget doing that. It's very easy not to plan for one-on-ones and just just kind of say, How's things? What are the problems? And then people feel like they mention the same problems week to week, and you don't address them. So, specifically address the things you raised the previous week. Okay. Thank you. Great talk. All right.

I had a question about [ __ ] up. You talked a lot about the idea of uh uh being comfortable saying when you [ __ ] up. Um but uh on the the flip side of being comfortable being able to tell somebody like, You know, you [ __ ] up. Don't do it again, kind of thing. My experience shows that um [ __ ] up is never black and white. And there's a lot of um gray areas where somebody doesn't think that they [ __ ] up, but you think that they [ __ ] up. And that kind of that whole realm of gray areas. Just curious about your thoughts on that. Uh my thoughts are it's a whole other talk, honestly. Um I was aware that there's some simplifications I did that slide. Um when I was rehearsing it, I was very conscious of it. Uh but it's um Uh the the key point, I think, that you have to be open about this stuff uh is the most important bit. But you're absolutely right. You may be wrong when you think somebody's [ __ ] up. Uh you both may be going different direction. You may not have the whole picture, all this sort of stuff. And uh

Yeah. A whole other talk. I don't know if I can use this all in the next 2 minutes. I think being open, I think that that is a Yeah, I think that that that that's it really. It is people have to be able to to talk about this stuff. And the moment the moment anybody feels criticism is shut down, the moment anybody feels that it's not possible to point out things being wrong, that's when the studio starts to rot from the feet up. Right. Thanks. Yeah, that's got to be our last question. Okay. Sorry, if you have If you have further questions for Alexis, please come up to the front, and if we need to, we can take it to a wrap-up room. And make sure that you fill out your email surveys to give Alexis feedback on his talk. But before we go, let's give him one last round of applause. Thank you very much.