Manager In A Strange Land: The Second Law of Bad Management

In Tom DeMarco's Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency he discusses the "Second Law of Bad Management", which is put yourself in as your own utility infielder. That is, if you want your project to fail, dive in and do the work yourself instead of overseeing the entire project. I've seen people break this rule frequently, as good programmers and artists get promoted to lead positions with no management training, then dive in and try to do all the work themselves. Often they're told to do just that from upper management: we're putting you in a management position, but that doesn't mean you can slack off and do no actual work yourself. Not only do they do an inferior job on the area of the project they're working on -- because of the constant interruptions that comes with the territory of being a lead -- the rest of the project goes down in flames behind their back.

It's the Peter Principle in action; employees promoted to their level of incompetence. Every now and then we get lucky, and promote someone who really can handle a leadership position without training, but most of the time they sink rather than swim.

An obvious solution to this situation is to hire managers for their management skill rather than technical skill or artistic aptitude. This solution is wrong. This replaces the Peter Principle with Scott Adams' Dilbert Principle. You frequently end up with managers that nobody respects or managers who can't call out their team-members when they're about to embark on a stupid course. "You need to rewrite the entire engine from scratch? Um, okay."

There's nothing for it. We need to promote experts into management positions. But how do we avoid the Peter Principle?

I recently stepped down as technical director on my project -- because I've always really wanted to be a game designer -- and had to find a coder to step up to take my place. I looked for these qualities:

For the reasons I mentioned before. They need the respect of the team, and they need to be able to catch unwise decisions before they're made.

Most of what a lead does is tracking and maintaining the schedule and the bug list.

A lead sets clear goals for their team-members -- or helps them set clear goals for themselves.

If they're a hub, they're already a lead in practice, if not in title. Also, it's probable the reason they're a hub is because they have a deep understanding of some important aspects of the game. They're used to being interrupted, and putting their own work aside to help someone else. Finally, since they're already being interrupted so much, they're probably not getting that much actual work-work-type-work done anyway. (That last one was supposed to be tongue in cheek.)

My first candidate for the job, Jason Bare, was the guy who had worked with the engine the longest. He held up a cross and said, "Keep your damn dealing-with-people job away from me!" Okay, I'm exaggerating.

Believe it or not, once I arrived at Michael Vance as a candidate, and okayed it with the heads of the company, I had a meeting of the coding team and asked them to vote on whether they'd be okay with Michael as their new lead, using Jim McCarthy's "Decider Protocol," where anybody has a veto. Most approved of the decision, and nobody vetoed it. Michael was in.

There is an additional measure that helps us avoid the Peter Principle. If Michael screws up, or decides the job is too much for him, he can always step back down, and I can step back in. This gives us a safety net that is not there when a new project is begun and a bunch of people who have never been leads before are moved to run the new endeavor.

Finally, there's training. I'm nearby if Michael needs any help; and I've given him some advice, which boils down to a lot of what I'm writing in this column, and this:

Don't put yourself in as your own utility infielder. That is, expect to not get any programming done. I think the rule of thumb for a lead coder should be the amount of time they spend coding is inversely proportional to the size of the coding team. If there's only one other guy on the team, they can spend almost all their time coding, but it quickly drops off as the number of others increase. Since there's a dozen other coders on our team, Michael isn't scheduled to do any coding at all, although he can pitch in and get little things done here and there as the need arises.

This means that if there's a system or module that only you know, you need to hand it off to someone else. When that system needs work, task that other person. Coach them as much as they need so they can be independent. But when you say, "Damn it, I'll do it
myself," you're spending less time leading.

There are times where you need to lead by example. There are times where the way you let your team know they can ford a river is because you've already forded it yourself. But these times are few and far between.

Which raises a point: being a lead sucks. I like to actually work on stuff. I like to write code. Which is why I stepped down as lead; I wanted to get in and do something. I'm thinking that taking turns handling management responsibilities might be a good way to run a long-term project. I don't think it's switching horses in the middle of the race; I think it's more like the flying "V" of birds, where they take turns at point, until one gets worn out and another one moves in to take their place.

By the way, the converse of the second rule of bad management isn't true. Just because you don't do any work-work-type-work yourself doesn't necessarily mean you're a good manager.

______________________________________________________