3 Tales of Micromangement

by Curt 23. January 2010 08:27

Software projects tend to be susceptible to micromanagement.  Even if your project has healthy requirements definition, there are still so many hidden details that need to be worked out.  

 

I’m sure that you’ve experienced micromanagement in the past and it caused you a bit of grief.  However, you may not realize that other team members sometimes condition themselves and their managers into needing low level direction.

 

You may also be thinking that all micromanagement is evil.  Mostly it is, but it can sometimes be used as a tool when team members are having trouble executing.

 

Below are three stories of micromanagement to help you see these different forms.  I hope they allow you to identify when to use it and how it happens, so you can take appropriate action.

 

Jack the Robot

 

Jack, the developer, has transformed into a robot.  He has lost the ability to execute the simplest tasks without instruction.  When you, the project manager, are unavailable he wanders around aimlessly repeating “Need Input… Need input…”.  Regrettably, you may be to blame for his metamorphosis.

When you first began working with Jack, before he became the robot, you sensed something about him.  The ambiguity of project details, which was the norm for you, was frustrating for Jack.  You shrugged it off though, thinking it was just a developer striving for exactness.

Time goes on, you continue to provide direction, and the project goes into overdrive ( like all projects do).  Suddenly, the time you previously spent with Jack is almost non-existent.  Jack goes idle for long periods waiting for direction.  He doesn’t take the initiative to get answers himself.

Moral of the story: If you’ve got a robot team member, don’t immediately conceed “They can’t think for themselves.”.  Developers’ jobs are very exacting and you need to educate them about where to find information or other people that may have the answers.

Additionally, consider that your methodology may be lacking.  The tools (specifications, user stories, use cases, etc.) may not have enough detail to write software.  Perhaps you don’t even have any such tools.

 

The Developer of Developers

 

John’s prior code slinging was the stuff other developers told their grandchildren about.  It was probably this exceptional work that led to the promotion of project manager.

Despite being a project manager, John spent most of his time looking over developers’ shoulders and scrutinizing code check-ins.  All the developers understood paired programming, but John’s approach was very different.

John’s style was more ‘hit and run’ micromanagement than paired programming.  He would swoop in, spend 10 minutes with a developer, and point out everything that was wrong.  He would return a day later and still be unhappy with the developer’s work.

Alienating his staff, however, became the least of his problems.  Bad things began to happen because he procrastinated communicating with stakeholders, ignored non-technical roadblocks, and disregarded tracking the project.

Moral of the story: John’s fundamental difficulty was that he didn’t recognize that he wasn’t a developer anymore.  This happens allot to developers, who become managers, because they have trouble letting go of their current strength.

Management is more about communication than any other skill.  John needs to trust his team and focus on removing obstacles and ensuring that the project is progressing properly by communicating with other stakeholders.  Not just his immediate team.

 

The Time Bandit

 

Jamie is a time bandit.  She has this unique power to absorb time and produce…  …well  …almost nothing.  Regrettably, her time consuming powers are not confined to herself and she begins to drain time from other members of the community.

The leader is gravely aware of the destruction Jamie is causing.  He knows that that traditional weapons, like performance improvement plans, would have little effec t on abating her powers.  He does, however, have an idea...

Even though the leader is very busy, he decides to spend time in Jamie’s dwelling.  The leader’s visits are infrequent at first, but gradually increase.  During his visits he helps Jamie control her powers, by mentoring her and not actually doing her work.

Moral of the story: Micromanagement typically is viewed negatively, but it can be effective if used sparingly.  If you have a time bandit, then try to do some observing or limited pair programming to isolate the problems.  Some things to look for are a reluctance to ask questions, spending too much time on a problem, or not having adequate direction.

Tags:

Management

About Me

I'm a software project manager in the Boston area. More...


    Contact Me
    Knols I've written
   My Linkedin profile