GDC 2014 Afterthoughts

I’ve always been a fan of GDC.  When I was younger, the amount of information people were willing to share blew me away; as a learning addict, it fed that desire in astonishing ways.  I still love the conference, but for different reasons now that I already know about most of the things people are talking about.  Here are some of my impressions, in no particular order.

  • The format continues to evolve.  This year, there were a lot more roundtables, maybe as much as twice as many.  There were also fewer sessions, with the Friday afternoon schedule, in particular, having been cut back, probably to allow people to fly out that night.  The summits and tutorials section has expanded a lot; next year, I may have to spend the entire week in SF.  The upshot for me, doing business as well as going to sessions, is that the Vault subscription that comes with being a speaker is going to be a life-saver.
  • No one knows where the business is going.  I talked to a lot of people about the big picture, as I usually do.  In previous years, there have been clear trends – the rise of free-to-play, the explosion of social games, the move to mobile – but not this year.  Everyone recognizes the problems, but there were no clear solutions.  If you haven’t seen Greg Costikyan’s rant yet, go read it now.  It’s a grim picture, but frighteningly accurate.
  • Diversity remains an issue.  Several talks, even entire roundtables, were dedicated to issues around diversity – gender, race, and sexual orientation in particular.  While some people took this as a sign that we’re turning a corner, I have a more cynical view.  We wouldn’t need to be putting so much energy into this if it weren’t such a glaring problem.  It will take years to make progress on this.  We are still in the early days.
  • The people are more important than the programming.  In spite of my years of experience with this conference, my hit rate for sessions was still about 50% (half of them gave real value).  On the flip side, every time I got together with people outside of the sessions, I learned things, had great conversations, and got great value for my time.  This year, in particular, I had a great time talking to a couple of folks who were involved with the very early years of the industry; it was a blast just listening to their stories.
  • Expectations can lead to disappointment.  Much like you are more likely to be disappointed by a movie if your friends have been talking it up for a while as the best thing, so with sessions.  Soren Johnson’s talk on transparency in games brought this home to me this year.  There wasn’t a lot wrong with it (I can quibble, but that’s always true), but it just didn’t hold a candle to the awesomeness that was his talk on Civilization IV.  I was surprised by how many people were enthusiastic about it, but it turned out that a lot of that was just being grateful for a talk that was in-depth about game dynamics; that says something distressing about the quality of programming in the game design track.

That’s it for now.  I’ll definitely be back next year, if I can.  GDC remains one of my favorite things to do, in spite of any issues.

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.