I’ve had the “luck” recently in having been in an environment where serious micromanagement was occurring. From this experience, I find that micromanagement not only demoralizes the entire development team, but it also puts the project at risk of failure. In this particular circumstance, the project is barely hopping along with the micromanager dragging it every inch of the way. It seems to be a very unproductive way to get to feature complete. Let me recap my experience.

I was contacted out of the blue by a former boss of mine to introduce me to a young, ambitious entrepreneur . This entrepreneur, whom I will call Bob, wanted to capitalize on the social networking trend and he had a great idea. His idea has been recognized by TechCrunch for its great potential. Everything seemed like it would work well and I agreed to work with him. At first, Bob seemed very on top of things. As a matter of fact, too much on top of things.

After the third day of working with Bob, I was uncomfortable because it felt like I was being dictated to on what I should be doing. I should fix this bug, then after which I should fix that bug. Once a bug was marked as fixed, almost always that bug was reopened with a feedback. The feedback was usually in the form of telling me that the fix wasn’t quite right because Bob had imagined the fix to be this way or that. Nearly a week had gone by and suffocation settles in. I dreaded having any contact with Bob, whether it be email, phone, or IM. I decided to consult my loving and supportive wife.

After some serious talking, we decided that despite the opportunities, it was not worth my trouble. So I told Bob that I will find a replacement and I will step down from my position. It took a couple weeks’ worth of interviewing candidates and I was lucky to find a replacement. But it was not meant to last. A few weeks later, I was once again contacted by Bob to help him look for another person. Apparently, my replacement had quit as well. I investigated further, and thus born this blog post.

Peopleware explored this idea greatly under chapter 20, Teamicide. This chapter listed ways in which you can kill your team and its effectiveness. The first of which fits into my scenario, Defensive Management. This section noted what I felt, that is only Bob’s “own judgment was competent; anyone else’s was suspect.” He fitted this profile to the T. He had a hard time allowing people to make their own mistakes or do what they think is necessary. He had to be “on top” of everyone’s work at any given time. So much so that he began to want direct report from everyone everyday of the things they had accomplished and the amount of time it took.

I don’t want to bash the micromanagement strategy. It may work in other scenarios and circumstances that I am not familiar with, but I can say that it will not work in software development. For a piece of software to be successful, you need to have smart, competent developers that can get things done. Once you have acquired your talents, let them know of the objective and let them loose (with periodic checkups). If you cannot trust your developers, then you have not found the right people.

Good developers will want to show that they are smart and that they can get things done the right way. If they are stuck, they will ask you to clarify the problem. Software building needs very specific requirements, if those requirements are not met or are fuzzy, you as the manager, will have an opportunity to make it clear. It is never a good idea to butt yourself into a developer’s work and interrupt their flow.

Peopleware noted that letting your software developers do whatever they want is a scary feeling. You will feel out of control, you will feel helpless. The good thing is, your developers will get more done, I can attest to that. Keep in mind this only applies to good software developers, otherwise, your mileage may vary. As you may know, The Mythical Man-Month pointed out that a “good” software developer is about five to ten times more productive than an average one. Peopleware confirmed this notion through observation of many “Coding War Games”. So, find good developers and let them do their job.

Once you have yourself a good team, it all boils down to trust. Do you trust your team? Do you have confidence in your team’s ability to deliver? Have they proven that they can deliver in the past? If the answer to all of these questions is a resounding yes, then you really have nothing to worry about. Go take care of other things for your business. You can have a great piece of software, but if you can’t sell it, then what is it really worth?

micromanagement · micromanagement death · software team · successful software · successful software team