Game development is difficult no matter how seasoned the development team, especially since the more experienced the team, the more likely the game we are developing is more sophisticated and has a larger scope. However, I have managed both veteran and neophyte game development teams, and there is a difference in how I must lead them if I want the project to turn out successfully.

Newer team members need a lot more direction from me on performing their tasks. Having developed many games in my career, I try to keep them from making noob mistakes, such as tackling the easier or more fun parts of game development first rather than taking on the tasks that are on the critical path for developing the schedule on time, such as ensuring that an efficient pipeline is established for developing the art assets, that they figure out a way to resolve technical issues they haven’t dealt with before, and that the core game mechanic is actually fun. Left alone, a neophyte team might start on only the tasks they already know how to do (which are few, considering they are new to game development) or what feels more like they are making a game, such as producing levels, even though they don’t yet understand the game they are making.

As team members get more comfortable with their tasks and roles, I may transition from a director role to more of a coach role, where I still provide team members lots of direction, but much of my time is spent in training them to help them hone their skills. This means that I need to know about their own disciplines and the tools they use, so that I can help them become better at doing their jobs.

Managing a veteran team is different, because they already know their jobs well and (hopefully) learned from past mistakes. Therefore, I give the design, programming and art leads on the team much more leadership responsibility, because they know how to do their jobs much better than I do. My role as a leader is then to be more of a sounding board and a cheerleader for them, while still keeping a watchful eye out for things not going according to plan.

However, I still need to fulfill a support role for them in which I talk with them about the issues and obstacles they are dealing with, but let them decide on the solution and apprising me of their solution — unless it involves a conflict with another lead, in which case I must play the role of King Solomon, deciding which lead has more responsibility for ownership of “the baby”. One thing I do need to look out for, though, is the “not invented here” syndrome, where developers are so confident in their skills that they think they should develop everything from scratch themselves — even if there is a pre-existing solution that will get things working much more quickly.

Once the leads settle into a productive working relationship with each other, then I can focus on more of a delegation role, allowing me to focus on areas beyond the immediate development tasks, such as localization, quality assurance, and marketing.

Regardless of whether I am managing a new or veteran team, it is vital that I gain team member’s respect and trust early on. With neophyte teams, this is so that they gain confidence in themselves and in the project, while with seasoned teams, it helps to keep an arrogant developer from challenging my leadership and trying to perform end-runs around me when he or she has different thoughts about how to do things.

As I said, game development is extraordinarily difficult work, but the job is much easier if you switch up your management style to accommodate the needs of individual teams and team members. Veteran developers still need leadership, but it’s a different kind of leadership — one in which you tap into their talents experience and not limit them with your own.