Manager In A Strange Land: Sliding Democracy

I had a high school English teacher who said nothing good ever came out of committees. (The same woman also told us that the human body underwent a weight loss immediately after death, due to the departure of the soul, and that she was visited by Jesus in her bathroom.) Similarly, the leads who want everything their way also tend to dis design by committee. Hmm. Maybe we should reevaluate the merits of the design-by-committee approach versus the democratic approach.

In theory, a committee is a good thing. We all have blind spots. If we get together, we can shore up each other's blind spots and arrive at better-informed decisions. So why do committees get such a bad rap? Maybe because committees frequently fail to arrive at the correct decision. In the absence of a leader, you can't blame a specific person, so your democratic process gets blamed. On the other hand, if a specific leader fails to make the correct decision (which also happens frequently), then only the leader is blamed, even though the dictatorial process ought to be blamed.

Why Committees Sometimes Fail

Wrong people making the decisions. Frequently you'll have a group of managers making all the decisions without including the people who are actually going to do the work and know their jobs. So you're handing out job assignments to people who haven't bought in to those assignments in the first place. I saw this with one game. I happened to be in the room when a programmer didn't want to implement a design his boss was suggesting.

This was a minor point that might or might not have contributed to the game's failure, but if the leads habitually fail to consult the experts when making decisions, it's obviously bad.

The opposite problem is when the people doing the work neglect to include their boss or client in their decisions and end up doing something the client didn't even want them to do. I've been guilty of making decisions in meetings where important stakeholders were absent and it usually ended in tears: either the work had to be redone or there wasn't enough time to redo the work, so some people got into trouble.

Fear of hurting each other's feelings. Somehow an idea that wasn't that good from a committee made it into your game. Now how did that happen? Someone on the committee should have recognized that it wasn't a good idea. Maybe everyone was just too nice to say anything.

At some point, brainstorming has got to end, and hard decisions have to be made; otherwise, you will end up with bloat-ware, as everyone's pet feature got integrated into the game. If you don't want to reject a feature outright, you could soften the blow by saying something like, "Well, it won't be our highest priority, but we'll get it on the schedule" (knowing full well it's going to get cut later as things slip). Even then, you're wasting resources.

To quote Bill Dugan, executive producer at Treyarch: Personally, I think the fear of hurting each other's feelings is a major problem in this industry … it's really hard to say, "Hey, the whole feature you just spent three months designing and implementing isn't fun; we need to change it fundamentally." I think this fear is a constant drag on any game's quality, from beginning to end. Imagine if we were designing a 747 and everyone decided to just be nice to the guy who's everyone's friend and who designed the rudder.

False consensus. Peter Drucker, in The Essential Drucker: The Best of Sixty Years of Peter Drucker's Writings on Management (Harper Business, 2003), talks about the social experiment where a group of people is asked if two different lines are the same length. Every member of the group but one is a plant; they agree that the different lines are the same. When it gets to the test subject, he almost always caves and agrees with the rest of the group. This phenomenon is yet another way a group can collectively agree on a bone-headed decision.

Peter Drucker then points to the story of Henry Ford, who, at a committee where everyone agreed on a new idea, freaked out and said he didn't like all the yes-manning that was going around. Sure enough, they reevaluated the idea and decided it wasn't so good after all. This cute story doesn't actually tell us anything: for all we know, it might have been a good idea and Henry Ford lost out.

Not the best ideas. The ideas that a committee comes up with are not the best ideas in the group but ideas submitted by the most persuasive people. Often, the most persuasive people are those in lead positions, so there's a sort of unconscious bias. According to Dale Carnegie, persuasion has little to do with the "rightness" of your argument and more to do with how you argue.

Nothing gets done. You can spend eternity in meetings without doing any actual work. When thesis and antithesis compete, it takes a while to reach synthesis. At the beginning of our latest project, we spent half our time in meetings for the first few months. I think the time was well spent but one could argue that we'd have more to show if we just dove in and started making stuff.

Imbalance of responsibility and authority. If nobody in the committee can be blamed for a decision, than what motivation does anybody have to make the right one? If a single person's job is on the line, that's another story.

Let the Boss Decide

So what if you just let the boss decide? Although you're less likely to be bitten by the "fear of hurting other people's feelings" and the "nothing gets done" scenarios, you'll now be more likely to be bitten by the "false consensus," the "wrong people making the decision," and the "ideas are not the best ideas but those from the most persuasive persons" scenarios. In other words, only three of the items in my "Why Committees Sometimes Fail" list apply exclusively to committees. The real problems are the "fear of hurting people's feelings" and the "false consensus." Both can be controlled.

In my opinion, one guy is simply more likely to screw up than a team. The fact that someone is responsible (whoever will be fired if he or she screws up) for running the show doesn't reduce the likelihood of that person screwing up.

Also, if you include the person who'll actually be doing the work, you're less likely to end up in a situation where people are working halfheartedly on jobs they think are bad ideas in the first place. (Although you're also likely to deadlock on that age-old disagreement in development: the programmer says, "We need to chuck it all and start over," but the boss says, "That's crazy talk!")

If you still think design by committee is a bad idea, consider this: the Half-Life guys did it. But they took three years to ship, you point out. Well, how about this? The Deus Ex guys did it. In my opinion, Deus Ex is one of the biggest success stories in all of recorded videogame development: quality delivered in a timely manner on a reasonable budget. Here's something from their postmortem:

Should you get to name your character or not? A holy war almost broke out on the Deus Ex team about this. "If you can't name your character, it's not an RPG," said some. "If we don't name the character, how do we write and record compelling conversations and create a cool story?" said others. "Story isn't the point…" "Yes, it is…" and on and on and on. We compromised: we gave the player character a code name and back story, but let the player select his real name, which came into play in various ways (though never in speech).

In my view, this is not a compromise but consensus building on a point that seems trivial. That's how important it was to them to keep the team invested. Finally, we've done it at Treyarch: on my last project (which I'm not going to name so this article doesn't have to go through a host of legal approvals), we were frequently accused of being overly democratic and committee-oriented. But we actually shipped a very successful, well-reviewed product on time (although we did enter crunch mode for eight months).

Give Democracy a Chance

Say I've convinced you and now you want a more democratic process. How should you proceed? If you're at the bottom of the totem, there's not a lot you can do to make your team more democratic. You can make yourself heard and encourage your teammates to make themselves heard, but take this too far and you could get fired. I've seen it happen on other teams and at other companies. Too much disagreement in the name of democracy or honesty or good faith can be harmful to your career. "He has a bad attitude. We don't need him," the leads might say.

I am backpedaling from one of my earlier articles, where I said, "A hobbit can contend with the will of Sauron." A hobbit can also get crushed by an Orc. If you're going to stand up and disagree with your boss -- all because you want to make the game better, of course -- be careful. Remember your people skills. And try to make sure you're indispensable if you're going to make waves; this is particularly important for middle managers, as the less actual work they do, the more dispensable they become.

A lot of us remember that game development was born out of small teams with democratic processes. It's natural for us to think that we should get plenty of say in the design of the game we're working on. That's the way it used to be. But now we have to remember -- democracy at a company is a privilege, not a right. Technically, if our boss tells us to do something we disagree with, well, that's what we get paid for. If we don't like it, we can always send out a resume to some place else.

Now, if you're a manager, then the situation is different. You can encourage some democracy within your domain. I'm not advocating either anarchy or putting everything to a vote. What I'm advocating is sliding democracy, where your project starts out with lots of brainstorming and committees and consensus building, and then increases the amount of dictatorship as time goes on, until, at the end of the project, whatever you say goes, end of story, ship the game.

The team still needs a leader, whose behind will be on the line if mostly incorrect decisions are made. And the way you should make sure those decisions are more likely to be correct is to have lots of meetings: ask for as much input as you can, and try to build consensus.

Building consensus is hard. There have definitely been times where all those reporting to me expected me to do one thing and I insisted on another. I now feel that the correct thing for me to do in those cases would have been to keep hashing out the problem until we found a solution that was mutually agreeable.

How do you build consensus? One excellent resource is Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher, William Uly, and Bruce Patton (Penguin Books, 1991) Then there's a short guide here that I just found via Google. So if you want it spelled out in excruciating detail (and don't mind wacky space-cadet stuff), then take a look at the McCarthy's Decider Protocol in their Core system [PDF link].

Jim McCarthy has a trick for avoiding false consensus and saving time: simultaneous voting. When you want to get a general idea how a room feels about a decision, just vote: count to three and ask everyone to put their thumb up or thumb down (or a fist if they aren't crazy about the idea but wouldn't mind trying it). You'll find out how everyone really feels without too much bias.

I once called for a vote after a long session of argument, only to see everyone -- over a dozen people -- voting the same way. What the hell were we arguing about? Were half of us just playing devil's advocate? Devil's advocacy is great, but sometimes you just need to get stuff done.

To sum up, remember that you're fallible and use your employees to shore up that fallibility. But also remember the possible pitfalls of design by committee and take steps to avoid them.

______________________________________________________