Category Archives: Game Industry

The Problem With Promotions

The game industry is rife with bad management.  You could probably say this about any industry; it’s a common sentiment: “I’m really good at my job, but the people above me keep messing up.”  If this seems like a completely alien concept to you, congratulations, you won the lottery.  Keep doing whatever you’re doing, because it’s hell out there.

The common explanation for this is the Peter Principle, the idea that people get promoted because they’re good at what they do, and this puts them into a position that requires them to do things that they’re not, actually, very good at.  It happens all the time in game development.  A great character artist gets promoted to lead the character art team; what they’re really good at is making art, not giving direction, managing people, writing up schedules, prioritizing goals, but now that’s what they have to do.  Or, a great programmer gets promoted to lead because they understand architecture, but they’re incapable of interfacing effectively with people outside the programming team.

They’re not bad people.  In fact, they’re often as miserable in their new roles as the people under them are.  If you got into game programming because you love programming, and you want to spend all your time programming, being promoted to lead is a disaster.  Now, you don’t have time to program anymore.  Instead, you have to go to all these meetings, and every time a problem comes up in the code, you know you could fix it, if only you had the time, but you don’t because you’re busy being a lead.  It can drive you crazy.

But, promotions mean raises, and everyone likes money, right?  It takes a particularly mature and self-aware person (rare in any field, much less the game industry whose rank and file are filled with 20-somethings) to turn down a raise and a promotion because the type of work it entails is not what they are well-suited for.  So, how do you avoid this?  I mean, recognizing the problem is a start, but solutions are what matter.

First, it’s important to test people on both their skills and their comfort levels before promoting them into a position.  At Stomp Games, our policy was that if you wanted a promotion, you had to demonstrate that you were doing that work effectively before the promotion would be considered.  Some people wanted this the other way around – promote me, and then I’ll prove that I’m up to it – but that’s a huge risk to take with a team, and people who need to be given authority to take on responsibility don’t make very good leaders.

You can use trial periods, probationary promotions, sub-project level responsibilities – no two studios, or teams, or projects, are the same.  But, you need to be upfront with the people you’re asking to do the work exactly what the changes are going to be in the new role and you owe it to the team to make sure (as much as you can) that the person you’re promoting is going to be both passionate and skilled enough about the new role to learn how to do it well.  Plus, you need to plan for bumps in the road as they learn how to do it.

Second, and this is the harder one, as an industry we need to recognize and create space for the truly phenomenal individual contributors who do not have the skills, personality, or interest necessary to be an effective manager.  You may not be able to change the entire industry in one fell swoop, but ask yourself if there are promotion (and raise) paths for team members that do not involve managing other people.  Can you be a senior concept artist, do concept art all day, and get paid what a lead concept artist is paid in your studio?  If not, there’s a problem, and this applies to all disciplines.

Design is probably one of the worst.  How many great systems/content designers stopped making great systems/content because they were promoted to lead?  In many studios, senior designer is a step on the road to lead; that leaves no space for great in-the-trenches designers, which means we turn over the bread and butter to junior people, who make the same mistakes that we all made when we were junior designers.  In general, if all your most senior people are management, you’re missing out on great, experienced talent and making a high-risk bet that you can grow your people to top level before your game ships.

The good news is that we’re learning.  The change is slow, to be sure, but looking over the arc of the last fifteen years, it’s definitely getting better.  Bad management will continue to be a problem for years to come, but thankfully, in fewer and fewer places.

Triangle-Class Problems

Most project managers are familiar with the phrase “fast, cheap, or good, pick two”.  It’s a classic formulation of a resource constraint tradeoff.  If you need it fast, you can spend more or lower the quality bar; if you need it cheap, it’s going to take longer or be lower quality; if you need it to be top-notch, you’re going to have to either spend the money or the time to get it there.  This triangle of constraints represents (in some ways) a particular version of balloon-class problems: squeezing any one angle is going to put pressure on the other two; if you try to pressure all three, it’s likely to explode in your face.

In my experience, though, things are rarely so clean.  For example, where does scope fall in these constraints?  Is it a sub-set of quality?  And labor cost factors into both fast and cheap; even if you’re running a small team, burn rate X time = money.  The idea that spending more money can make things faster also runs into problems with critical path and non-segmentable work (see The Mythical Man-Month on why 9 women can’t have a baby in 1 month).  In team situations (and almost all game development is team-based), you also run into problems because communication efficiency scales inversely with team size, and scaling a team is a risky and time-consuming proposition.

People have tried to refine this triangle by making diamonds, or Star-of-David type diagrams, which really misses the point.  Project management is not a problem you can solve in the abstract.  Every team, every project has its own dynamics.  The triangle is a tool.  Like a forking move in chess, it allows the project manager to present clearly to other stakeholders that they must make a choice, and regardless of which choice they make, they are going to have to give something up.  It is a defense against outside forces who often want everything, or, for that matter, against inside forces that are not setting priorities realistically.  Its simplicity is its strength; it embodies the problem.

Even though it’s not the most precise formulation, it’s still a useful tool.  It allows you to negotiate without saying no, a valuable move particularly when you’re managing up.  On the flip side, if you recognize that you’re getting this a lot from your team, you need to revisit the project priorities, risks, and mitigation plans; something has drifted out of alignment, and you may well be the one who is drifting.