I think you’re a good producer. Because you actively tried to understand the issues. Like basically listened to people in the team. A good producer tries to genuinely understand what different parties want and what are the main obstacles in the way. The problem is that skill is mostly about listening. And producers are usually not very good at listening. Even though that’s the key component in any kind of leadership or managerial role. So yeah.. tl; dr – I think you have what it takes to be a good producer.
– Unnamed team member from six years back 1

“Dev needs Production” came across reading like the title of a bad romance novel by Chuck Tingle2, but based on my now 20 years of game development experience, I thought I’d share some of it just to, I don’t know, be helpful? Be nitpicky? Because I want to and because it can’t possibly do any harm?

The Literature

Okay, so I don’t have much in the way of literature here, but I do have some.

  • The Practice of Creativity: A Manual for Dynamic Group Problem-Solving. George M. Prince, 2012, Echo Point Books & Media
  • Synectics: The Development of Creative Capacity by W. J. J. Gordon, London, Collier-MacMillan, 1961
  • Gender and Genius: Towards a Feminist Aesthetics by Christine Battersby, 1989
  • Praktisk Projektstyrning, Tieto, 2005 (Practical project management)
  • Scrum and XP from the Trenches, Henrik Kniberg, 2015
  • Brotopia: Breaking Up the Boys’ Club of Silicon Valley by Emily Chang, 2018

Challenges, challenges!

One of the unfortunate trends of perhaps, attitudes among almost every game developer I’ve known 3is that production gets in the way or causes issues with creating games. If I’m allowed to hazard a guess, I think the attitude stems from 1. game development being a creative profession 2. we’ve still got this romantic notion that we’re underdogs and less rigid than other industries 3. we often end up in crunch, which is blamed on production, but honestly can be brought on for many different reasons 4. we’re individualists and a bit of a rebellious breed 5. we always think we know best.

Creativity can’t be scheduled

Yes it can. I’m sorry but this is not a valid statement at all. Creativity, or as I’d like to call it – problem solving – can too be scheduled. There’s no magic to it. It isn’t a black box. What it is is do you due diligence, gather requirements, ask the right (and sometimes the wrong) questions, build something.

Just like everything else, you have to work at it. Have you ever heard a writer talk about their craft? “Slog through it. Write, write, write.” That’s what they usually say.

Game development is the same. Work through it. Design, design, design. You might not come up with the Best Design Ever™, but you’ll come up with something, and since that something is probably good enough, you can polish or come back to it later.

Unfortunately, we’re surrounded by stories about the solitary, male genius that give us this idea that creativity can’t be forced or learned. I call bullshit on all those statements. What you really need is:

  1. Discipline
  2. Focus
  3. Multiple sources to draw from
  4. Requirements (a.k.a. framework)
  5. A clear goal

This is probably not a very popular idea or thought, because by golly we like to think of the creative process as something outside ourselves. I’m not going to lie, sometimes it is, but mostly it’s just work.

The reason I bring it up is because scheduling creativity is something designers sometimes resist. They’ll tell you it’s impossible to be creative on demand and grumble when they have to be. So here’s my advice.

  1. In a discovery phase – be generous with the time and allow time for research and noodling around. Don’t be too strict with the output, but also don’t expect nothing. You always have to have some goal, even it the result is what not to do. Timebox.
  2. Ideally, you’re done with ideation once you get to the exploration part of the idea, meaning prototyping and testing. In my experience, getting designers to make decisions is like pulling teeth. Or herding cats. Or herding cats and pulling teeth at the same time. But you have to make it happen or the project is destined for crunch and misery. Always leave an out, of course, such as a change request, but make sure everyone understands the cost of such a change. You don’t want people to feel trapped by a decision. You also don’t want to make it cheap to roll it back, because usually it isn’t cheap.
  3. Do the work. No, I’m serious. Do the work, and do it to a standard the project has agreed on. “I’m not good at documenting” is something I hear a lot. Alright. Then find a way to learn or use the skills you are good at to communicate your ideas. But you have to communicate them, and probably in a way that lets people go back and make sure they’re working to spec. The absolute worst thing you can do is not have a trail of design decisions and why those design decisions were made.
  4. Make sure the team understands what they’ve committed to and that you (and themselves) hold them to it – but only what they’ve committed to. Don’t add to their workload without their consent. Honestly, this is one of the things I see the most often. Trying to sneak in additional work when there’s no time for it, and the team gets to pay the price. I think this is one of the reasons trust is hard to come by.

The main takeaway is probably that we don’t like to be scheduled or to Write Stuff Down™ because scheduling counters the idea of the Creative Genius™4 who cannot be reined in by such trivial things as a schedule.

My belief (and no, I don’t have any hard data on this, only anecdotal and a series of lectures and workshops that I took at university) is that this is one of those cultural things. We’re steeped in the belief that things “just come” to us. Personally, I think Da Vinci and Tesla had bad days as well. Not to mention Lovelace and Lamarr. But I also think they did the work.

There’s nothing magical about creativity, and I will die on that hill.

Nah, we just do it and it’s magic

Having worked in an organisation with several thousand employees that have to be able to communicate in understandable ways from division to division and country to country, I understand the need for administration.

Without it, things easily unravel and fall apart. Or at least they take a lot longer than they might have otherwise.

That said, I also understand that the rigidity and rules needed for an organisation such as Ericsson Mobile Communications is not needed for a game studio with 150 employees.

However, if you have 150 people working on the same thing, you still need some structure, or things really will fall apart.

Despite this, a lot of game desvs I’ve worked with doesn’t really want to acknowledge that this is the case.

The idea – that the devs still know each other well and can work out any kinks together – is noble, but in reality this leads to cliques of people who are informed and large swaths of people who have no idea what’s going on. The devs are coming from a genuinely good place, but as humans we tend to fall back on known patterns. What works for 10 people doesn’t necessarily work for 50. What works for 50 people doesn’t work for 100 etc.

Garage development, not caring about rules or authority, sure that worked when you were smaller and when everyone came from the exact same cultural background and the exact same socio-economic strata.

Even though games are still terribly monocultural, we who are “different” are starting to join in. We have other ways to look at the world and we need other things from the organisation.

Ultimately, rejecting the “authority” of planning if what gets us in the mess of crunch. I’ve been to so many places where most agree that tracking our velocity and capacity is a good thing, and yet 60 – 70% of the developers in the teams I’ve worked with are unwilling or resistant to providing this data.

The only solution I’ve found – and believe me it isn’t the answer to all problems – is to explain why. Why are we doing this, what are we trying to accomplish5 So my recipe is:

  1. Explain why we’re doing it.
  2. Explain how we’re doing it.
  3. Make sure your team agrees and understand their commitments.
  4. Hold yourself and your team accountable.
  5. Fight for your team and their capacity/ velocity.
  6. Never stop explaining why we’re doing this.
  7. Chase people down, stand behind them until they’ve added the data you need, until they do it on their own.
  8. Let them know when they do good.
  9. Take responsibility for mishaps.
  10. Don’t be afraid to be wrong.

As a dev, follow the guidelines of data entry. But hold your producers accountable. As a dev you have a right to know why we’re doing what we’re doing. The data will give the production team the data you need to fight for you. If the data doesn’t exist, it’s harder to say no.

Zug, zug

Bad planning, bad or no data and no decisions lead to crunch. How do I know this? Because I’ve been in the trenches of several game projects where the decision process was unclear and the data was crap. Result – overtime. A lot of it.

So here’s the thing. If we don’t know what we’re doing (decisions are being made and unmade constantly) and if we don’t know how long it’s going to take (bad data), how on earth are we able to tell when something is done?

The answer is of course that we don’t.

So. Crunch can on occasion be brought on by “indecision” which in turn comes from the unwillingness to commit to one idea, work it through and let it go. Part of this is probably insecurity and the ever lurking spectre of the creative genius curse. We need to be awesome! More awesome! Awsomest!

There’s also the issue of being unable to see the whole game in your head. In a large team, its difficult to get a clear overview of what’s going on. So seeing game systems work in concert (or not, as it were) can often lead to not wanting to nail down specifics. In an exploration phase (pre-production) this is totally fine and even encouraged. During production it is a shooting offence. Or at least a change request, and as I mentioned earlier – change requests should be expensive.

In addition to that, a general unwillingness to document also leads to a general sense of the left hand not knowing what the right hand is doing because no-one writes anything down. A company with rigid rules might be slow, but they do get things done. Even if it takes time.

To some I probably sound like Attila the Hun when I talk about these things, but I honestly believe that documentation serves an important purpose besides communication. It holds you accountable.

Without documentation you’re free to change your mind. With it, people can ask you why this specific part of the design changed. It’s a bit of a blocker for “indecisionitis”.

Documentation also takes us the long way around to planning. Without a clear goal – this is what we’re doing – we’re unable to determine how long it will take. If we – in addition – don’t have any data… You see where this is going, right? Right into the jaws of crunch. Nom nom, the beast says as it chews on people until they can’t bear to be in the industry anymore.

But I can’t work this way

I don’t work well your way. We all have to make compromises to work together, but sometimes it feels as if big egos can get in the way. To be honest, 90% of everyone I’ve ever worked with have been absolutely lovely, but then there’s that 10% lump of antisocial or racist or misogynistic individuals that just won’t conform to the rules, such as they are.

Adding insult to injury, the reason these individuals are allowed to stay in the company is because they’ve always been there, or they’ve made themselves indispensable or (more rarely in my experience) they’re really good at what they do.

Because these individuals lack or don’t care about social skills, their influence can be devastating, especially if they start questioning or ignoring methods. People like these are often also why marginalised people leave the company.

Let’s clarify a bit. By anti-social, I don’t mean introverted. I mean rude and narcissistic and often clever enough to avoid detection by HR.6

Be wary and aware if you have a disruptive presence on your team. If that person belongs to a marginalised group – cast your net wider. They may be a problem, but they may also only be reacting to someone else in the team. In other words, dig.

My advice:

  1. Explain why we’re working this way.
  2. Explain how.
  3. Find a good middle ground that allows both production and development to work as painlessly as possible while still supplying what the project needs.

When I was a producer

I admit. It’s easy to think that you know best, but everything, all projects, are contextual.

For project management to work well, you have to look at the context. What’s the company culture? How would the team react if you add this piece of admin to their every day? Are you explaining how we do this? Are you explaining why? Are you letting your team have a say in how things are done or is it more of a command?

Because production – just like design – is primarily about people you have to look at context. Ramming down a rigid production method down people’s throats – especially smart, somewhat antiauthoritarian and very individualistic people – is not going to fly.

Keep explaining how and why and do retrospectives where people can react to and improve on the process. Keep your promises.

Hold yourself and your team accountable.

To be honest, the production teams I’ve worked with in games sometimes suffer from the same impatience as the dev teams. “Whoops, this method doesn’t work. Let’s change it!” A process takes time to take hold. You have to be patient. Explain why. Explain how. Hold yourself and your team accountable. Keep your promises. Secure buy in. Do your best. Keep in mind we all have to compromise.

  1. Okay, I’m tooting my own horn here, but I was just reminded of this by Facebook and I was so happy when I was told this I had to tell people about it, because my self confidence sucks, okay?
  2. I have never read a romance novel by Chuck Tingle, but I hear it is a life changing event.
  3. Okay, hyperbole. Maybe 60 – 70%.
  4. The Creative Genius™ is most often a man. Weirdly enough, women rarely cause the same amount of ruckus and they usually deliver on time. With documentation. To be fair, though because this is game dev, my sample size is very limited.
  5. And sometimes that leads to people dragging you into a room and explaining to you why you are wrong for two hours. Weirdly that never seems to happen to my male colleagues. Huh. Imagine that?
  6. I’ve worked with a guy who was very genial to everyone else but he was an open misogynist. Since this didn’t affect anyone else but me in my immediate team (being the only woman in that part of the project), it mostly went unnoticed. Honestly? This guy – and to be fair, a couple of others, totally messed up my confidence by gaslighting the hell out of me. Because of his and his fellow sexists antics I was labeled a problem and troublemaker. I left. He stayed.