Fear is the Teamkiller

Blue Tengu GhostOne of the most difficult things to manage when working with a team on any project is fear. Of course that applies to game projects as well.

It’s hard enough to deal with on a solo project, but fear grows with the size of the undertaking. A game jam is not as scary as a half-year project is not as scary as a four-year project. And fear breeds.

When one person is afraid, they make the people around them afraid as they seek reassurance by throwing that fear around.

Experienced game designers understand the relationship between fear, teams, and video game development because they often become the targets of that fear. It’s in the name of their role, but a game designer is the one “designing the game” so any unknowns are going to be classified as their fault. If an artist or a programmer “doesn’t know something” it must be because the game designer is not doing their job, right?

As the project rolls along and people start to wonder whether it will finish because of the mounting unknowns, they seek reassurance. They want to know that if they do everything that is being set down before them that the project will get done, get done on time, and get done well.

The problem is, game designers are a lot of things, but they are not predictors of the future. The best they can do is to deliver what needs to be done just-in-time. In fact, if the game designer is getting too far ahead, that’s a bad sign because it might signal that the team will end up with too much work to finish, or, at best, all of the work that went into those early designs will have to be redone or tossed when new information comes in. Inflexible and inefficient.

Agile does try to mitigate the process by getting something reassuring, a first build, up and running as fast as possible, but that’s generally not enough to calm people down. After all, no team sets out to make a barely functional game. They want to wow the world, bring something new and exciting into it, etc. And, especially for developers who teethed on the waterfall software development life cycle, not having a long, winding road map to the end can be distressing.

That distress can ferment and bubble to a crisis point where the non-game designers team up to start forcing the hands of the game designers. They seek more specifications, more detailed plans, more scheduling, etc. and, in the worst cases, end up taking over the game design role. If that revolt succeeds, the game usually falls apart. Why? Because they’re acting on misplaced fear. They’re panicking. And panicked people rarely make good decisions.

Dealing with fear on projects isn’t easy, but it’s something that will come up. If the directors and producers in charge are well-equipped to handle fear, they can usually bring things back into focus, but if they’re offsite, or worse, afraid themselves, things go haywire.

One situation that can be handled in advance by game designers is the trouble that can come from having one game designer loosely in charge of everything. This is often the cause of legitimate fears because things that need to be answered begin to go unanswered. On big projects, there are too many game design decisions that have to be made for one person to make all of the decisions, and responsibility should be doled out accordingly. As Bizarro Spider-Man would know, great responsibility requires great power. The game designer who is used to being in the middle of everything has to cede control and that awesome adrenalin rush to his or her teammates, including final say regarding their area of responsibility because, without ceding that, all of those decision balls come bouncing back into their court.

Many game designers become leaders on a project because of their experience, not necessarily their management skills, but being a leader means knowing how to lead (another one of those roles where everything is in the name).

One key management hot tip is that people will respond to the roles they’re given. If they know someone is standing over their shoulder, ready to reverse their decision or save the day when things get tough, they’ll delegate decisions back up the chain. If, on the other hand, they know they have to do it or it doesn’t get done, then it usually gets done. One other management hot tip is that people are full of surprises. Until someone is given great responsibility and great power, there is no way to tell whether they’re Spider-Man or just someone in red tights who jumps around the room a lot. The job of a leader is to try to pick the right people to delegate to, to give them space and time to grow into the role, and, if they don’t, to change them out for someone who might. The job of a leader is not to make all of the decisions, that’s a different role (cf. “dictator”).

One way for game designers to manage fear on Agile projects, which are particularly unnerving for many developers, is by keeping proper track of burndown (the amount of tasks that are completed every cycle). Using Agile as nothing more than a method for doling out tasks is like using an Alienware PC to play Solitaire. The true power of Agile comes into being when tasks, estimates, and final results are properly tracked. With a proper backlog (a to-do list), a list of estimated tasks, and an accurate burndown chart, dispelling fear is often just a few calculator punches away. Of course the game developers who are anti-Agile probably won’t settle for that, but if you’re dealing with an open-minded team, it should help assuage some of the doubt. Also, keeping that information clear, out in the open, and updated is one way to tackle fear before it has a chance to brew and ruin the project.

Leave a Reply

Scroll to Top