Do you manage other programmers, in any capacity? Then take Kathy Sierra's quiz:

1. Do you pride yourself on being "on top of" the projects or your direct reports? Do you have a solid grasp of the details of every project?
   
   
2. Do you believe that you could perform most of the tasks of your direct reports, and potentially do a better job?
   
   
3. Do you pride yourself on frequent communication with your employees? Does that communication include asking them for detailed status reports and updates?
   
   
4. Do you believe that being a manager means that you have more knowledge and skills than your employees, and thus are better equipped to make decisions?
   
   
5. Do you believe that you care about things (quality, deadlines, etc.) more than your employees?

A "yes" to any of these -- even a half-hearted "maybe" -- means you might be creating Micromanagement Zombies.

That's right, Zombies. Mindless automatons who can barely do anything except exactly what they are ordered to do, and even then, only when someone is strictly monitoring what they're doing and how they're doing it. Micromanaging the people you work with is arguably the exact opposite of what a competent team leader or manager should be spending their time doing. So if you're micromanaging at all, even the teeny tiniest little bit, step back and take a long, hard look. It's a sign of deeper problems.

Beyond that, who the heck wants to work with zombies anyway? Shouldn't you endeavor to work with the type of people who are good enough at their jobs that they can make sensible decisions about what they're doing? And they're not constantly trying to eat your brain? Well, figuratively speaking.

Building teams is like building software. It's easier to describe what not to do than it is to identify the intangibles that make good software development teams jell. But it's pretty clear that micromanagement is one of the biggest risks. In Peopleware, DeMarco and Lister establish seven anti-patterns they dubbed Teamicide:

1. Defensive Management
2. Bureaucracy
3. Physical Separation
4. Fragmentation of People's Time
5. Quality Reduction of the Product
6. Phony Deadlines
7. Clique Control

Wondering what number one encompasses? You guessed it: micromanagement.

If you're the manager, of course you're going to feel that your judgment is better than that of people under you. You have more experience and perhaps a higher standard of excellence than they have; that's how you got to be the manager. At any point in the project where you don't interpose your own judgment, your people are more likely to make a mistake. So what? Let them make some mistakes. That doesn't mean you can't override a decision (very occasionally) or give specific direction to the project. But if the staff comes to believe it's not allowed to make any errors of its own, the message that you don't trust them comes through loud and clear. There is no message you can send that will better inhibit team formation.

Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager's eyes or in your government's eyes) is irrelevant; it's only the right to be wrong that makes you free.

The most obvious defensive management ploys are prescriptive Methodologies ("My people are too dumb to build systems without them") and technical interference by the manager. Both are doomed to fail in the long run. In addition, they make for efficient teamicide. People who feel untrusted have little inclination to bond together into a cooperative team.

In the end, isn't trust what this is about? If you don't trust the people you work with -- and most importantly, actively demonstrate that trust through your actions -- should you really be working with them at all?