Do you manage other programmers, in any capacity? Then take Kathy Sierra's quiz:
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:
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?
The comments to this entry are closed.