Collaborating with People Is The Job

I’ve had #gamedev jobs since 2007, which seems like a long time now. I am not an indie developer, I work mostly in AAA game studios, and thus much of my professional experience focuses on building games with large groups of people. I got my first director role in 2011, and I’ve been gradually learning how to improve as a director in video games ever since. Today I’m writing about something I’ve learned along the way : collaborating effectively is very important, and very difficult.

A Director’s/Lead’s Job Is to Build Consensus

If you take a large group of creative people and get them to approach a problem together, they will at first mostly suck at it. This is true for a number of reasons, but highest among them is that human beings are opinionated, anxiety-driven, ego machines who all have their own unique perspective and ideas.

If you have a director job, the dev team is relying on you to provide clear direction in service of an amazing game.

Most AAA devs would say that the audio director decides the audio direction, the art director decides the art direction, the animation.. you get the idea. This can lead to a very narrow understanding of the director role. “Having a vision of [Level] design” is very important but it’s a small part of the job. The individual directors’ roles are very important, but they are not deciders. They’re just contributing to a process.

The process of making the game is the real force that decides what is in the game, at the end. There are reviews, budgets, playtest and publisher feedback, a festival of opinions moving in both directions, and the game is kind of a result of the whole process. Will the process be chaotic, or well organized? Will people agree efficiently, or will they waste a lot of development time struggling to reach agreement? THAT is the part that is up to directors.

Being a good director (I like to think I am, some days, but it depends on the day) relies on discipline-specific knowledge… but more than half of the job is about getting people to understand something together so they can work on it together.

Creating great gameplay, storytelling, or player experiences relies on consensus. Let’s talk about different ways of building consensus.

Consensus by Using Authority

Sometimes, high level directors or producers have to just call the shot. This is worth discussing first because it’s a technique frequently relied upon. The Creative Director is actually expected to do this from time to time, and just say “We are going with option A” , indicating that a choice has been made. By virtue of the high ranking teammate’s authority, most of us as employees will get in line and now we have consensus. It’s not the prettiest, but it works. Also: it’s fast.

The downsides to using this technique are many, however. The people you didn’t have time to consult might be frustrated for reasons invisible to you, because you didn’t take the time to absorb their perspective. Very genuine problems might not get surfaced when we build consensus by authority. If this occurs too frequently, you may find yourself losing the trust of key players on your team, and it may jeopardize your chances of using more collaborative techniques that require trust.

Personally, I find that the biggest downside to building consensus by authority is that it burns the most of my energy. I don’t want to take every decision. Making big games involves thousands of design, technical, and creative choices, and at some point one realizes that they do not want to be implicated in all of them. It’s far more fun and relaxing to build consensus with a group.

Consensus by Group: Free For All

Building group consensus is “good” in that the team will likely make better choices, and trust inside the team is certainly better when the group collaborates to make choices about the game.

Getting people to agree and reach a consensus takes good conversation and good political skills, because you need to reach all the key collaborators. People will need to be heard, and that means they have be able to communicate their ideas in a way that works for them (which is hardly ever the same way for everyone in the group).

If this sounds like it will take up a lot of time: yep, it will. It’s still “good” but it does take time. Many directors enjoy talking too much, and the ones that don’t usually need to be coaxed into sharing their insights. People will waste even more time talking and won’t listen efficiently if they haven’t practiced the collaboration-dance enough to build trust. It’s a whole thing.

Some people want to nail every uncertainty because they’re uncomfortable with uncertainty. Others place such high value on group “pleasantness” that they may not raise difficult questions because they don’t want to bring stress to their colleagues. Both of these profiles are worthy teammates, and every dev team has a mix.

Generally, this ‘useful discord’ plays out as follows: the more time the group spends together, the better they get at building consensus. Directors start to speak in fewer paragraphs once they trust each other more. The conversation becomes more practical, less performative. But there is also a shortcut: use a process.

Consensus by Group: Process

Dancing is a wild, personal act of expression. Some people are meticulous and follow precise steps, others flail happily without a plan. Conversation and building agreement are similar: if you want to get a group of people to get aligned, get them to practice dancing to the same drum beat.

In consensus building, it’s valuable to quickly establish a process to reach consensus.

To achieve this, it’s best to have the group set up a simple structure, like for example:

• What do we want to decide?
• What information do we need to make this decision?
• When do we need to deliver an answer?
• What things do we need to communicate with our answer?

The group typically can help build the answers to these things first. This is actually (shh) sneaky first-collaboration before they collaborate, but they won’t mind.

Next ask the group how they want to participate, via email, or a meeting (usually you need at least one, but some people are happy to give their information and then trust the group to make a choice).

Finally, take the participation rules and build a workflow of “what we do by when” and communicate it to the group.

It helps if somebody is a “process owner” or “meeting MC” when actually running through the agreed-upon steps, but you will build consensus more efficiently, and it reduces social uncertainty and conflict because the group understands how they are expected to participate.

Having a process doesn’t smooth out all blockers to building consensus, but by bringing structure to the conversation the group has a kind of “music to dance to” that can make differing points of view more comfortable, and ensures that the final communication is complete enough to be useful by the dev team.