Production Fundamentals

I’ve been working in Production for 5 years now, prior to that I worked my way through the QA hierarchy. Over this time I’ve learnt a lot of lessons, been intrigued by a few fads, and butchered SCRUM more ways than I can count. Through all of this though it’s been the fundamentals that have kept me improving, and when I’ve had a dip, it’s the fundamentals that bring me back up. I wanted this blog post to cover what I believe the fundamentals of production are, or at least, what they are to me. I may miss a few, add a few, or simply ignore a few, this is an opinion, but I do firmly believe that the fundamentals will do more for you, the team and the game than anything else.

It’s also worth mentioning that production is different things to different people and companies. We’re sometimes called Producers, Project Managers, Product Managers or everything in between. The below is my take on production based on my experience thus far.

Waffling aside, below are my fundamentals of production.

Risk

I was going to give this a better title, something you’d see on a YouTube video when the image and the content don’t quite match, but I couldn’t think of anything, so risk will do. I believe a producer has numerous goals in relation to risk.

1.Is there risk blocking the team achieving their ambition?

We’ve all seen it. The team have an amazing idea X months into a Y month schedule. As the Producer you know there isn’t the time, so you say no. That’s the standard approach, I do it myself most of the time, but, too often I feel producers get stuck in the habit of “no” and take on the mantle of game director. In some studios this may be the case, but let’s take a quote from Blizzard as an example…

“A producer’s primary goal is to keep fellow team members free of impediments that could impair their work”

In my previous paragraph, time, resource allocation or priority are an impediment to an employee or teams work. They have a great idea, I believe it’s the producer’s goal to explore further if this idea is possible. Be that through de-prioritization of other features, resource allocation, and reduction of scope or quality or through added time. Of course it may simply not be possible, the situation on your current project could be that it’s behind and any resource time investigating how do we a feature is noise the team does not need, it all comes down to an assessment of the project and its current status, that’s a call you need to make.

There’s a downside to the above of course, investigating every change request to such a degree could take your eye off the prize (release!) so you need to tread carefully and keep an eye on the project state, however I raise this point as I have fallen into the trap of saying “no”, without asking myself “How?” first.

2.Is risk clearly communicated?

Another trap I feel producers fall into is risk communication. More often than not after the risk evaluation phase the producer’s mind is made up. Team X has too much work or can’t achieve a stretch goal, the decision is simple, drop the feature or change course. Often this will be the correct course of action, but too often it feels producers shield their team from risk in a negative way. Talking to your team as a unit about what is a risk, why this is a risk and the impact it can have is important for numerous reasons. It allows the full team to understand why something may change, but more importantly it allows the team to, as a unit, figure out what is possible. If the risk is a code issue, let’s say with UI, it could be another programmer has a suggestion to resolve it. This example assumes that these two coders have not spoken, but that happens a lot. As the point of communication it’s your job to make sure the risk is raised and heard by the correct people before a course of action is taken.

Lead by example

One of the most important but most underused fundamentals of production (and management.) By this I mean, if you’re on Facebook, Twitter, taking 20 coffee breaks or talking about how bad something is that will spread. Negativity and bad habits spread quicker than positivity and good habits, I don’t have data to back this up it’s just my experience. Work and lead how you want others to work and lead.

Enthusiasm moves the world

Very similar to the previous point, an enthusiastic team lead, or anyone for that matter, can have a huge impact on those around them. Be positive about what you’re doing, what you’re team is doing, and what is happening in general. If something isn’t going well, or simply needs revisited, come at this problem from an enthusiastic and upbeat manner – sure it isn’t going well, but let’s figure out HOW to make it better, not focus on why it’s awful and everything is doom and gloom.

For me, this point is huge and I could bang on about it for a long, long time. Inspire those around you with feedback, it won’t always be good news, but the delivery of the message and the focus on moving forward is crucial.

The blame game is a game no one wins

Let’s say a bug was found in the live environment, in this situation the default position I often experienced was “who let this happen?” versus what I felt was the correct approach:

These approaches have, in my experience, such varied outcomes. For my example let’s say a QA team missed the issue that went live, while the code team are fixing the issue and QA are prepping to QA the new build for release, by focussing on who let this happen from a negative stand point you put pressure onto the QA team, more often than not the least experienced in the studio in terms of man years. This can lead to them being anxious over missing something and over testing, or on the other hand rushing a fix to try and please upper management and causing more issues.

My advice is to approach the situation calmly, the bug is already live so stressing about it won’t help your team. Work with the code and QA team to tackle the flow of fix > QA > sign off > release. Once this is gone, let the team know it’s good they responded to this fix quickly and then sit down with the guys to cover what happened and can we stop this in the future. Mistakes will always happen, we’re people, in my opinion how you handle them has a huge impact on your team.

Great can always be greater – aka iterate, iterate, iterate

A simple quote I heard from entrepreneur Lewis Howes – Great can always be greater. If you think you’ve nailed the above, you do it all perfectly, you’re the shining light of production at your company, maybe even the world – DON’T STOP. You can always be better, you can always improve, and you can always be greater. Keep going.

--

And that’s it!

As I mention, I no doubt missed some obvious additions, however this is what has helped me through the tough times and good times. I’d love to hear your examples or feedback below.

Find me on twitter - @RetroCrumpet