I recently made a post on Building Better Software about micromanagement ("Demoralize Your Teams Quickly And Efficiently With Micromanagement") and how it drains a development team's will to live. I've been studying micromanagement for a long time—not often voluntarily. It's a nasty little trap that people can fall into.
What's worse, you don't necessarily have to start out as a pointy-haired boss type to become a micromanager. You don't even have to be a manager, or even a team lead. You just need to have some amount of control over assigning someone else's work. A lot of developers find themselves in that position pretty often, and when they do it's easy to accidentally find yourself micromanaging—in a way that you would never put up with if it were done to you.
After I made that post, I went back to the first book that Jennifer Greene and I wrote, Applied Software Project Management, because when we wrote it, we called it out as a particularly nasty trap that software projects can fall into. Here's what we wrote:
When a manager is overly involved in each task to the point that she personally takes over the work of each person on her team, she is micromanaging. From her point of view, there are a lot of benefits to micromanaging her team:If this describes you, then you're almost certainly making your team miserable through micromanagent. That's why we also laid out a few basic ideas for ways that you can avoid micromanagement:
Her micromanagement has a devastating impact on the people who work for her. They feel that they have no responsibility whatsoever for what they do. They are not trusted. If they produce poor work, she will fix it, usually without explaining what they did wrong and often without even telling them. They feel like they do not have any impact, positive or negative, on the final product. And they're right.
- It endears her to the people at or above her level, because it seems like she always knows everything there is to know about what's going on with her team.
- She knows that no mistakes will ever make it out of her team.
- She does not have to trust the people who work for her to do a good job. Instead, she can review everything they produce to ensure that each work product meets her standards--and she will redo anything that does not meet those standards.
- It makes her feel very important, because nothing gets done without her.
- It allows her to feel superior to everyone who works for her.
- She gets to steal her team's thunder, taking credit for all of their accomplishments while blaming them for any failures.
- Don't expect to review everything. You need to trust your team to do the job. If you don't, maybe you hired the wrong people. More likely, though, you need an attitude adjustment.
- Don't expect to be "hands-on". You have a team to do the work because there's more work than one person can do. You hired people with specific expertise, and if you hired them well then they're better at their jobs than you are. Do your job, let them do theirs.
- Use transparency rather than status reporting. If you need to know how the project is going, set up a system that makes it easy to track. We're living in a world of great agile software practices like task boards and burndown charts. Even a simple issue tracking system can give you great information about the project. The less you have to bug the team for status, the less they feel like Big Brother is watching them. (Although sometimes the team will also go too far in this direction, and do obsessive project tracking.)
- Don't be afraid to let your team make mistakes. Let people learn from their mistakes, and give them an environment where they don't have to be perfect all the time. Because nobody is.
Once you know the signs, it's not hard to spot them and stop yourself from making another developer's life miserable.