My Biggest Production Hack

Today we’re talking production hacks. What do I do to save time? Like all good hacks it sounds like I’m lazy. But really it ends up being good production! What is it? Stay tuned to find out!

First up: thanks for the question, Excited Producer.

After reading this initially, my brain went off in a different direction to think about hacks that would break game production entirely or something. But I’m pretty confident the intended definition is this:

a hack is an inelegant, but efficient solution.

A lot of production is actually not very hacky at all. It’s a lot of grunt work where you’re talking to everyone to understand what’s going on, adding tasks, updating tasks, and generally doing a whole bunch of things the team may never notice unless it’s not done.

So it was a bit of a struggle to think what I could share, until I remembered the biggest thing I do which is…

I don’t stress about getting the “correct” or “official” terminology And I don’t stress about executing a process exactly as defined in a book or even as I defined it to my team in my initial plan.

This may sound like I’m being lazy and that I haven’t been properly trained in production. Mayhap! But in the end my way works because it comes down to a few factors:

1. 1. There is no “perfect” way to make games. It will change depending on your game genre, team size, funding source(s), remote policies, company culture, development phase, and so much more.
   2. Terminology is super inconsistent across the games industry.
      • For example, many people can’t agree on what should be in an Alpha build . There doesn’t even seem to be consensus on whether the Alpha build comes at the beginning or end of Alpha Phase, ie being “in alpha”!
      • It is good to learn terms and techniques from other people to get more tools in your toolbox. But even when you decide to use something that seems “official”, you’ll have to define everything from scratch since your team may have different interpretations or may not have encountered it before.
      • By defining everything, it gets us all on the same page about what we’re going for. Then the name of what we’re talking about can even be made up by team members which gives them ownership over the process and helps them engage more with it.
   3. Plans need to change: No plan survives contact with the enemy. (Attributed to Helmuth von Moltke the Elder).
      • In this case, the plan we’re talking about is your supposedly perfect production process and the enemy here is actually your wonderful colleagues who aren’t enemies at all.
      • It’s very difficult to predict the needs of every unique person on your team. So if you dictate a hyper-specific process upfront that you refuse to change later, your team will likely disengage, ignore you, and more problems will stack up.
      • It’s much better to customise a solution plan, then as the team tries it out, learn what’s working and what could be better. Then iterate on the solution and keep iterating until it’s time to shelve that solution and create an entirely new one.

So in summary: definitely spend time learning from books, talks, mentors, other producers, and (of course) absorbing my generally good advice. But it’s much more important to:

• Listen to your team, dissect current processes, customise solution plans for this team working on this game at this point in the development cycle, and then iterate to improve the plan.

This brings me to a bonus hack I do: I ask the team for their solutions and suggestions rather than trying to come up with everything myself.

That’s it for today. Thanks for reading.

Remember: This is general advice and it might not be right for you and your team, even if you’re the one who wrote in the question! For me to help better, it needs to be a dialog between me, and you, and your entire team. You can hire me to consult for you —> jennsand.com