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.

1.Be the most organized member of the team. Don’t be late for meetings. Don’t forget meetings! Bring all the documents you need when you meet. Respond to e-mail immediately.
2.Lead by example. Don’t expect others to file bugs correctly, use your documentation system, handle e-mail, or do any other task the way you want it done unless you do it too. Obvious but missed by many. If you consider yourself an exception, so will everyone else.
3.Don’t dodge problems. They don’t go away. This might be a team member who is not performing adequately… you have to accept that you need to deal with their performance, it won’t improve on its own. On the other hand if there’s a problem that is unsolveable and others are coming to you for a solution be clear that you have no solution… don’t pretend that you’ll deal with it.
4.Be Available. A daily roll-call style of meeting is less effective than ensuring that you are always at your desk at a set time every day to discuss problems. Make sure you walk the circuit daily — talking to both the designers you manage and the other team members (and not just the other leads).
5.HR is not a necessary evil. Realize that things like employee reviews, company meetings, and other time wasters are not necessarily of value to anyone. If you are spending all your time, or your team is spending all of its time, away from the project there’s a problem. As a senior lead you need to help fix it. In regards to employee reviews it makes far more sense to give feedback as the project progresses rather than at set intervals. Some employees prefer the structured once yearly reviews but I think they grow more from constant interaction.

Fonte: Gamasutra "Brent Knowles"