Manager In A Strange Land: The Czar Chart

In my years in the industry I've heard a handful of horror stories about rock stars. By rock star I mean this: somebody at the top of the org chart thinks they're a rock star, and they lord it over people. Whatever they say, goes. They are the auteur. It's their vision. Their game, not yours.

What happens is obvious: everyone else on the team cares less about the product. They phone it in. They do as little as they can without getting fired. If they have ideas for improving the product or process, they keep those ideas to themselves. They send out their resumes.

Fickle employees are a part of business. Loyalty is a forgotten concept--these days, if you have talent, you ask, "What can the company do for me?" first, and "What can I do for the company?" second. And there's nothing wrong with that--since the typical company's goal is to give their employees as little as possible, and get out of them as much as possible, it's not surprising that people have this attitude. If they didn't have this attitude, they'd be taken advantage of.

When it comes to videogames, we are mostly volunteers. We have talents that could probably earn us more money if we worked in other fields. Some of us are here because we've heard anecdotes about a few people who got rich, but most of us are here because we want to make good games.

It's because of these things that management guru Peter Drucker says that you should treat your employees as if they were part of a volunteer organization. Which isn't as lax as it sounds: Drucker is talking about volunteer organizations like the Boy Scouts and the church--organizations where people set goals for themselves and if they fail to achieve those goals, are let go.

When a rock star tells us--or even just implies--that it's not our game, it's theirs, we look for some other place to go where we can make a game we can call ours. We go volunteer somewhere else.

That's just one of the reasons I like emphasizing a czar chart instead of an org chart. I don't think it's horrible to have an org chart, but I think you should probably keep it hidden in a desk drawer somewhere. If you have to refer to the org chart to make a decision, you may have already lost. As a replacement for the org chart, I suggest a czar chart. This is just a table of responsibilities. We do this for the coders on Spider-Man 2: each subsystem has a coder who is the czar of that subsystem. Front End, Tools, Script Language, etc. We also do this for the missions: who is the czar of the script for that mission? Who is the czar for the models? And you can extend this to management responsibilities: who maintains the schedule? Who graphs the bug list? And whenever a ball gets dropped, add that responsibility to the czar list and make somebody the czar of it from then on. There's no reason why one person can't be the czar of more than one thing--as long as they have the bandwidth to handle it. Hey, what would you rather be: A junior programmer or the front-end czar?

I was talking to a district attorney at a wedding the other day and he said they have the same sort of management system where he works. He was the "Murder Czar". He agreed; the system works.

I was halfway through writing this article when I read Jack Trout's Power of Simplicity. He says the same thing, and he said that Robert Townsend said it first in Up The Organization, which I haven't yet read. They didn't call it a czar chart, but they do use a flat directory with names--alphabetically--on one side, and what that person does on the other. And Joel Spolsky talks about something similar in his article "Command and Conquer and the Herd of Coconuts".

In case you don't want to read his article, I'll sum up. Turnover at Microsoft is low and turnover at Juno is high, and Spolsky theorized it was because Microsoft's hierarchy was extremely flat and Juno's hierarchy was extremely vertical. At Microsoft, when you're put in charge of something you own it--to the point where if extremely senior people get in your dish they're the ones who get in trouble, not you--and at Juno there was a long chain of people who would get in dishes all the way down to the worker bee. At Juno, people would quit because they "Didn't feel the room for advancement" and at Microsoft, they wouldn't, even though most people there would never get promoted to the point where they have reports.

Similarly, Treyarch has low turnover by industry standards. This could be because, at Treyarch, we tend to trust people to make their own decisions. Because we let most people own their dish. Not all the teams have an actual physical (or even virtual) czar chart but czar-ness is implied: so-and-so is the particle systems guy, so-and-so is the rigid body physics guy, so-and-so is the animation guy, this is so-and-so's mission, etcetera.

A lot of you may be saying, "Wait a minute. That's more or less the way we do things on my team, already. Hell, even if I wanted to micromanage all my reports I wouldn't have time to." If so, congratulations; not every game development team is like yours. Some close the lines of communication between disciplines: "A coder can't talk to an artist directly; he has to talk to the lead artist instead." Some have deep hierarchies: the designer reports to the lead designer who reports to the creative director who reports to the producer. (Actually, we have that on our team, but we don't take it too seriously.) Some have leads that say things like, "What the hell do you think you're doing? This is my game." to their reports.

There is, of course, a dark side to responsibility ownership. It decreases your "bus coefficient"--the number of people on your team that can get hit by a bus without ruining your project. We've definitely seen this at Treyarch, as, say, a programmer suddenly has to leave and somebody has to step up and complete his 90% finished code. ("The first 90% takes 90% of the time. The last 10% also takes 90% of the time." I got that line from David Cook, by which he means you're never as far along as you think.)

It also creates what Jim McCarthy calls "the guy in a room" phenomenon. You put all of your hopes on one guy, and then wait. And wait. And wait.

Extreme Programming people would advocate pair programming at this point, which may be a little…um…extreme. I think the risk presented by those busses and guys-in-rooms is worth it, and can be mitigated by standards, meetings, e-mail groups, thinking ahead, and big safety buffers in the schedule.

Don't get me wrong. I'm not advocating anarchy. There has to be someone in charge. What I'm advocating is to find ways to flatten your hierarchy, help people feel like they own their work, and avoid micromanagement. Org charts are good for the mafia and the military, but they're not what you want for videogame development.

______________________________________________________