     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Manager In A Strange Land: Meetings We have a poster from Despair.com on the door of our meeting room that says, "Meetings: None Of Us Is As Dumb As All Of Us." Sometimes I think you can learn all you need to know about management from Despair.com and Dilbert. Meetings, when overused, become a bad thing. People are so busy talking that they stop doing. And it's easy for a whole room of people to simultaneously come to the wrong decision. Still, without meetings, we'd all be doing our own thing, without regard to how it affects the project as a whole, and I believe that--despite groupthink--the chances of a group of people coming to a correct decision is greater than a single leader deciding something by fiat. On a large team, it's worth having the leads meet once a week. Try to keep the meetings short; when they inevitably digress, somebody should pipe up and say, "Can you guys take this offline?" For the individual disciplines, every other week is fine. At the discipline meetings, you can quickly go around the table and let each other know what everybody's working on, just to touch base. There's nothing wrong with spontaneous meetings. James Zachary, our lead animator, has a rule: three e-mails by any one person in a given e-mail thread means you should meet in person. (I tend to let it go a lot longer than that because I type really fast.) Feature meetings, where everyone involved in a feature gets together on a regular basis to look at the feature and discuss what still needs to be done, are a great way to keep everyone on the same page about the particular feature/level/whatever. We hold these meeting once a week if some people aren't devoted to the feature full time; but usually everyone is working on the feature in parallel. If it's a key feature that everybody is depending
on, it's sometimes worth a lot more attention. Here, you can have
a "standing meeting"--a meeting where nobody is allowed
to sit down--of the people involved every day, to keep them updated
on the progress. Offices If you only have one person per office, it's easy for them to concentrate, but not likely that they will communicate. If you have too many people per office, a lot of communication will happen, but no actual work. Tom DeMarco talks about the importance of "flow" in Peopleware, and there are plenty of anecdotes about how noisy offices are unproductive-if person A asks person B (or even person C) a question while person B is in "flow," person B has supposedly lost n minutes of work to save person A the n seconds it would take to look something up. In my experience, though, I've usually worked in crowded, noisy offices, and I've still somehow managed to ship a lot of games. How could this be? I have a couple of theories:
Here's our rule of thumb on Team Spidey, the group working on Spider-Man: programmers are two to an office, artists are two-three, designers are three-four. Producers get cubicles in the hallways. Some exceptions are made for expediency. Small offices for the coders (since only two share), big offices for the designers (since there are probably four of them). Cubicles--particularly cubicles with high walls--are Satan. All the distractions of a giant shared office, very little of the communication benefit. Reorganization Almost every project I've worked on has started small and grown massively as time went on. When this happens, it's tempting to take the trickle of new team members and slot them in wherever you can find them. After a while, you'll find you have an office floorplan that is not optimal for communication. Which is why we tend to move people around a few times during the course of a typical project. We've done this so many times now that we've become experts at it: we come up with a layout for who goes where, write a list of the moves that have to be made to get everybody in the right spot, and then make them one by one. In a couple of days, the floorplan has changed. We call this the "Busse Chain" since Chris Busse pioneered the technique. When you move everybody around, it means people come in contact with new people. You can make a graph of who communicates with whom on your project--every person is a node, and you draw links between the ones who communicate. When you reorganize, this graph will tend to change. New links will form between the nodes, and the old links may weaken but won't go away completely. The amount of communication on the team will go up. For a while, during the original Spider-Man, we mistakenly decided it would be a good idea to organize the team by the level they were working on rather than their discipline. Although this was a bad idea--designers could no longer ask each other questions on how to use the script language, artists and designers wanted different levels of light in the offices--it did help create a few new links in the communication graph, and was not a total loss. Let The Hubs Be Hubs Conventional wisdom says you should put your leads in private offices to help establish the image of authority. This is fine for a certain kind of lead, the sort of lead that spends more time overseeing and less time making critical decisions. There's another kind of lead, frequently without title, who leads simply by being a "hub" or "go-to guy"--the person everybody asks for help. On your office floorplan, it's good to drop these leads right in the middle of things, surrounded by the people who will need their help. Also, this way, they can keep abreast of important decisions that people are making on the fly. And even your overseer-type leads should have offices near the center of the team, rather than those isolated (but prestigious) corner offices. You can also do what Peter Akemann, our founder and CTO, does: have the prestigious corner office, and set up a workstation in the hallway right in the middle of everything, and spend most of your time there, in the trenches. You can even work on the game a little, if you make sure to stay off the critical path. Best of both worlds. It's even better than Management By Walking Around: it's Management By Being Right In The Middle Of Things. Let It Be If there's a theme here, it's that communication
will happen; all you have to do is remove barriers and let it. One
tempting blunder to make is to try and close off lines of communication--I
know after seeing a programmer working on someone else's pet project
I've been tempted to say, "Don't talk to one of the programmers
without going through me first, okay?" But there's nothing
wrong with people on the team talking; the problem comes when someone
goes off-task onto a low priority item. Just make sure that everyone
understands that they're not supposed to switch task unless their
lead or the project manager knows about it--and let them talk all
they want.
|
|||||||||||||||||||||||||||||||||||||||||||||||
Old-Fashioned
Communication
Features
|
|
|