Managing a Game Design Team

As cool as it is to be in charge of the design scope of a game there’s also some heavy responsiblity.

I’ve performed poorly as a manager at times. And I’ve learned a lot from that. The following is a brief summary of what I thought worked and what did not.

WHAT IS YOUR RESPONSIBILITY?

Your job duties may require you do many things (write reports, design the game, interact with upper management, schedule and so on) but your two most important responsibilities (if you want to create a great game) are really the following — Running Interference and doing Quality Assurance. Everything else needs to be squeezed in when you’re not doing these two things.

RUNNING INTERFERENCE

If you make sure that the designers are able to manufacture fun, often and generouslly, you’ll have a succesful game. For them to be able to do this they need you to run interference — get the art resources they need, remove obstacles to them working on the game (bullshit HR requests and such), and make sure they have a clear direction in regards to what is/is not acceptable.

You do this and you’ll look like a brilliant lead. If you get to manufacture a little fun yourself, great but at this point you produce more fun as a unit by removing the distractions your team faces.

A single designer on a project who really cares about the project can do brilliant work. A dozen of them can produce miracles. But they can’t do this if they’re bogged down by a weak art team, a lack of programming resources, or a company structure that promotes bureacacy over innovation and effort.

Let your designers inject surprises into the game. Not everything has to be designed by you, to the letter. That makes for lame, forgetable, and ultimately boring games. And a terrible working environment.

QUALITY ASSURANCE

As a design manager you need to be the ultimate tester. If your game is testable and you don’t have time to test it there’s a major failing in your company’s workflow.

Don’t dismiss the talent of the other teams on your project but do realize that there are few people on a project who understand how all the pieces need to fit together to deliver the experience that players want. You don’t need to plan it all but you have to understand how it all fits together. On projects I lead I was always in the top 10 in regards to number of bugs reported. This is important.

At the same time don’t take yourself too seriously. Playing the game and verifying quality is not just about showing people what you know but also learning from them. You might review a designer’s level and find several faults in it (and you should then use these as teaching exercises to improve that designer’s skills) but you’ll probably also see them introducing concepts unfamiliar to you. Don’t instantly reject these. Study them and see if these concepts might make sense elsewhere in the game. Has a designer just created a ‘piece’ that you now realize fits into more places on the puzzle that is your game?

So test, file bugs, verify bugs, and repeat.

OTHER TRAITS

Here are some additional tidbits that I felt made me an effective lead.

Any other tips out there? Anything you disagree with?