Its seems that the challenge is not so much micromanagement, but more like an engineering tradeoff. How does one keep projects moving forward quickly without forcing a drop in quality. Decisions of this nature are very difficult to make without seeing the larger picture. When I’m knee deep coding something, its important to have a second opinion.
An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only. --Bjarne Stroustrup
This is a very complicated topic. It really depends on the team of people you have. Some people need to be micro-managed to ensure things get done, others don’t. If you fall in the former camp there is hope, however. You can slowly convert your team over into a self-managing team. The Dale Carnegie leadership course is all about learning how to do this. I highly recommend the course, but if someone won’t pay for you to attend it then read How To Make Friends and Influence People.
The existence of horrible managers is inevitable in most huge corporations, but I think the key is that they only have power if they have subordinates who listen to them and act on their micro decisions. Try to find a non-zombie manager and a couple non-idiot team members and band together to create a sandbox project or environment to let the horrible manager spin their wheels on.
Basically cut off someone’s head, throw it to the other side of the room, and have all the zombie’s go chase it while the useful people get their work done.
@Jeff and Dan:
I agree, hopeless - but I also think it’s pretty sadly typical of our profession. As a custom development shop, we’ve seen these attitudes in the majority of our client’s IT/dev departments. These people don’t follow blogs or news or spike new technologies and just don’t care. Government IT is the worst, since they have even less motivation due to budget and HR practices.
Ha ha those South Asian dumbasses. Thank God for Dan the great for getting some work out of them!!
I agree with Darcy. Jeff appears to be living in an ideal world. But in the real world 50% of the developers are completely incompetant. And even if you attempt to constantly hire the infamous top 10% there will still need to be some major hand holding.
The famous Unskilled and Unaware of it paper comes to mind. So many programmers want to be free to make their own decisions. They certainly think that they are capable of it. Some are. Most aren’t. And even the ones that are often need to be reminded about the business side of the equation.
I’ve worked for both of the extremes and both were disasters. As usual, there optimal point is somewhere in between the two extremes (but not necessarily in the middle).
Put another way, good managers know which employees are capable of making decisions and which ones aren’t. And they also recognize which decisions require additional management and which ones don’t. Not every decision is life or death. Good managers let employees make their own mistakes when those mistakes don’t jeopardize anyone else.
I agree with Sarel, that it depends on who is in your team. Some people are better at self-management than others. Some very smart people can be incredibly lazy and unmotivated, or have a lot of technical knowledge but not be particularly good at judging task priorities.
Some of the best managers I’ve had have been the whip cracking type. Their style sometimes caused friction but the end result was a product out the door on time, on budget and in general of a quality the whole team was proud of. Of course, they were usually somewhat charismatic and honest…tough but fair would be the way I’d describe them.
On the flip side, some of the worst managers I’ve had were those who didn’t make decisions for the team. They would manage with the philosophy of empowerment, but it usually ended up with a team that constant fought over ‘vision’. The lack of status updates, and a lack of a singular vision for the product meant that progress was a game of tug of war within the team. The idea was fairness but it just ended up causing the team to become politicized with no ‘authority’ to appeal to. The best example of this are meetings where things just go round in circles and you want someone with authority to just say ‘guys, we’re doing it this way…let’s move on’.
The point I’m making is that not all micromanagement is bad, and in my experience well implemented micromanagment / hand holding ended up with a better result than the hands off approach.
I couldn’t agree more, just wait until someone sends you this link http://msdn.microsoft.com/en-us/library/ms229042.aspx given this is very good practice, it’s quite amazing how in detail it can get to guidelines, most of the time, it’s a balance of time, budget, and getting the project shipped that makes me wonder why someone should spend time reading a guideline, I guess as a reference it’s good.
I read a great book on business The Dilbert Principle. Basically, there are two theories on how someone gets into management:
-
Peter Principle: Successful people are promoted. This has the logical conclusion that people are continually promoted until they reach one level above their maximum capability and are no longer successful, and that’s where they stay. Result - in the end an organisation filled with incompetent managers.
-
Dilbert Principle: Given a two professionals, one who is good at their job and one who isn’t, who would you promote? The guy who isn’t good at his job might be a good manager. The guy who is currently good at their job might be a bad manager. Game theory dictates we should promote the currently incompenent person. What have you got to loose? Therefore we continue to promote incompetent people until we have nothing but excellent professionals and incompetent managers.
he he he.
Interesting topic and comments. You can almost tell who are the developers and who are the managers, just by the responses.
As a long-time manager of a large development organization, I feel micro management is all about control and trust. If you are micro-managing, you probably feel you have to control everything your staff does because you don’t really trust them to do it right and on time, or even to do it at all.
I would venture to guess many micro-managers typically have small staffs and don’t have much of a development process in place.
Try managing an organization of 20 or more developers. You’ll stop micro-managing and become enamored of the virtues of delegation in a hurry.
ALSO - they should just make all managers move furniture around and install window shades, I hear that’s how Fog Creek is run.
Haha, found your blog on Viralogy.com. At first I thought you were referring to zombie accounts of facebook and Twitter. The fact that skimming made me think its microblogging zombies didn’t help 
This post is really interesting because I have seen so many cases where micromanaging is not the right solution. If you micromanage everyone, you see every single one of their flaws, but if you empower them and let them do what they want, you get to see their CAPACITIES. A person can never be 100% to what you want, but can probably be close to 100% of what he/she wants, so its a much better way to see them be their best self!
Happy New Year!
- Yes. No.
- Most? No, but some tasks, yes.
- No. No.
- Definitely not.
- Depends on the employee.
Funny thing. No one has tried to eat my brain…
READ A BOOK
ESPECIALLY FRED BROOKS BOOK
JEFF STOP BLOGGING
The fail is strong with this post.
@Dan, add my condolences to the pile. I’d start looking for a shotgun and an escape hatch.
Incidentally, has anyone read Company by Max Barry? Sometimes I feel like I’m inside…
While i agree that jeff seems to work in circumstances which are kind of better than the usual corporate fuckup, i do not agree to the posted statements that micromanagement is neccessary if you have unskilled workers.
Basically, if you micromanage them, you are doing their work. That little productivity which is gained by the parts they can do on their own is instantly lost by the communications overhead. Therefore, in the best case, micromanagement just hides the fact that you are doing all the work alone.
Nice post, Jeff.
It is sad we are not living in a perfect world though. When a manager has to resort to micromanaging, there is something wrong (either the manager, team, constraints)…
@Robert Rossney
What you are describing is NOT micromanagement. All those points, Jeff mentioned, apply only to a certain extent. While it would be very unwise to try to tell rock-star developers exactly what to do, it is quite different in the situation when the team consists of junior programmers, and the project is actually their first assignment.
From what you are describing it seems to me that you have been alternately assuming the scrum master’s and product owner’s role, if we are going to stick with the Scrum terminology:-) What else is it than removing impediments and helping the team to progress smoothly?
On the other hand here are couple of points that could be definitely considered micro-management practices:
- Forcing the staff to fill in the hours worked on a very detailed level into some system (the more systems, the better)
- Dictating the scope of work needed to implement some feature
- Overriding (and lowering) the team’s estimates while insisting on same or better quality and features
There is a delicate issue though. What to do with the already existing zombies:-)??
I don’t need to deceive you
’Cause I feel no pain
Maybe I should just let you
Come on and eat my brain
Yeah yeah yeah
It’s a simple fact that the best managers don’t micromanage, they delegate the tasks to people they know can do the job without their interference. When you surround yourself with competent people, you don’t need to micromanage.