Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As I got the feedback of developers about scrum methodology in this question, on whether it turns active developers into passive developers or not, I encountered the word micromanagement.

However, Wikipedia doesn't explain this term in the context of specific and tangible examples, and this, can result in different interpretations of micromanagement. Can anyone point to some well-known micromanagerial issues in the world of development (of course, with reference)? What practices could be regarded as micromanagerial? How can we get sure that we're not implementing micromanagement in our working environment?

share|improve this question
add comment

8 Answers

Micromanagement is one of things that is tough to quantify. I don't know that you could make a list of "incidents" and get 100% agreement that this or that is or is not micromanagement. If micromanagement was this easy to spot and track with quantifiable data then it could be avoided entirely.

Here are my red flags of micromanagement, for myself, and for people above me. This is certainly not a comprehensive list.

  1. You don't trust developers to make decisions on their own.
  2. You are the authority, and all decisions run through you.
  3. You hash over the tiniest of details and force developers to defend these details.
  4. You get involved with programming decisions on an implementation level.
  5. You approach decisions from the standpoint of "I must be convinced otherwise".
  6. You grill a developer over why something took three hours instead of two and ask "what they were doing during that time."
  7. You start requiring your team to provide detailed timesheets of their day to prove that they've been working.

Again, this is not a full list - these are observations that you make of an organizational structure over time and cause you to go, "uh oh". Its easy to judge someone else by this list; it is far harder to judge yourself.

share|improve this answer
    
6 and 7 are the ones that are really bad. A good well thought out decision is easy to defend. And when you are the one who is responsible for the end product then having decisions run through you is not necessarily a bad thing. When you start making arbitray decisions and refuse to consider other options that is micromanagement –  Chad Aug 18 '11 at 17:11
1  
@Chad: Arbitrary decisions are not necessarily micromanagement (still terrible though) - arbitrary decisions at a very detailed level would be micromanagement. –  Jarrod Nettles Aug 18 '11 at 17:19
1  
Well said. Trust is the key, I think. Managers who micromanage do so because they have not learned to fully trust. –  Matt Ryan Aug 18 '11 at 17:39
1  
@Matt - There are also developers who have become managers who would rather be developing. They seem to get more involved in decisions than at lowlevel than business type managers. But the worst are the business types that think they know how to program because they had a VB class in college. –  Chad Aug 18 '11 at 17:47
add comment

When a non-technical lead or manager tells you what library/API or even what function to use. When they start getting involved in very detailed architecture/design decisions ("I think while loops are faster so use those"). When they stand over your shoulder and say "is it working yet?". When they start reviewing everyone's source code and making suggestions to change every thing, even the spacing around comments ("I think it looks better with 1 space after the -- instead of 2 so could you go and change them all?"). These are micromanagement.

share|improve this answer
    
So, seems that micromanagement is really horrible. –  Saeed Neamati Aug 18 '11 at 14:30
    
@Saeed: In my experience, it usually is. But sometimes only slightly horrible. Most these examples are not from my own personal experience (thankfully!). –  FrustratedWithFormsDesigner Aug 18 '11 at 14:37
add comment

I feel like my reference point should be Dilbert. :)

I'd suspect Urban Dictionary is a decent source, too, but the micromanaging company web filters here won't let me see it. Ironic, no?

Here's my working definition based on personal experience:

Micromanagement is, to an extent, in the eye of the beholder. While there may be a lower bar that is established by a team, corporate culture, national culture or career domain at large, in general Micromanagement is providing task direction in such small, overly specific, focused statements that the person receiving the micromanagement is unable to contribute meaningfully to the work at hand or take any pride in having accomplished anything.

What I find intersting, personally, is that micromanagement can largely be a matter of personal experience. For example, here's some cases:

  • Explaining to the new intern exactly how we perform a build (and more importantly why) is not micromanagement the first time. Explaining to the new intern how to perform a build every time IS micromanagement.

  • Explaining some particular crucial success or failure details of a feature development assignment to a mid-level engineer who doesn't have a history of good judgement or good colllaboration practices is not micromanagement. Explaining these same details to a star engineer who always does a great job of checking in and working out sellable details with sales engineering IS micromanagement.

  • Dividing up and prioritizing features for development and parceling them out to engineers is NOT micromanagement when you are the task manager for the team. It IS micromanagement when you are that task manager's manager.

A general good rule of thumb is, if you are essentially making all the decisions of the person one level down from you, you are probably micromanaging. Conversely, if you are coaxing, arguing or selling a contratry idea to the person one level below you, you are not micromanaging. But there is sometimes a profound gap between the manager things he is doing (aka, "convincing") and what the employee things is happening (aka, "dictating). Especially in a knowledge based career - we pay people for their good judgment and visionary work. When we take away any ability to make judgement calls or contribute to the vision, we are not only micromanaging, we are wasting the value of the employee.

share|improve this answer
    
Great Dilbert examples ! –  Xavier T. Aug 18 '11 at 15:52
add comment

Fictitious (hopefully) example :

Every week your manager reviews how many lines of code you have commited to central source repository.

share|improve this answer
    
i am sorry to inform you that there are non-fictitious examples of this behaviour. –  keppla Sep 13 '11 at 13:35
add comment

Example I've run into has been roughly:

  • Worrying about the exact number of hours somebody is at their desk typing, instead of looking at results.
  • Asking a developer why they are periodically away from their desk/on phone/etc. when said developer does good work.
  • Not trusting anyone to put in an honest day's work unless you can verify they are in the office and only take exactly 60 minutes for lunch, exactly 15 minutes for breaks, etc.
  • Forcing rigid company practices (e.g. rigid hours, requiring explanation if somebody is 10 minutes late or leaves 10 minutes early) because you don't trust people.

I very rarely see micromanagement at the actual nature of software development itself; it's usually at the general employment level. That said, specific examples directly relating to software would be:

  • Non-technical manager having the final say on technical decisions and not consulting developers first.
  • Rigid code standards (also a sign of bad code in and of itself) mandated "from on high" for no reason.
  • Requiring specific API/technology when there are better alternatives
share|improve this answer
add comment

Symptoms:

  • Can't delegate tasks
  • One person is doing all the design, and the rest are getting task assignments on the "implement this function" level
  • All code reviews are performed by a single person on a team
  • Project speed never changes as the size of the team goes up/down (all must flow through the micromanager)

In a nutshell, if you don't have autonomy in how you solve a problem, then you're being micromanaged. George Patton has a nice quote on that about telling people what to do and not how to do it.

Good: Add feature X. Fix bug Y. Bad: Anything more specific than the previous sentence. (of course that goes to say within the norms of the product)

share|improve this answer
add comment

Micro Management is in the SMALL. "Managing" things that are very small details that should be delegated to other people to decide.

The ultimate example of micromanagement would be your manager sitting at your desk with you telling you which keys to press and which fingers to press them with.

Development managers should be managing things that the developers can't make decisions on in the LARGE, doing things and making decisions that EMPOWER their employees to be more efficient and more effective. Like getting them the best tools to do their jobs (software and hardware), ensuring they are in a quiet work areas, have time to think before they do, aren't distracted by people asking them to do things unrelated to their current task all day long, etc.

Managers should be what the military refers to as force multipliers. If your manager isn't making the team more effective than without them, you need a new manager.

share|improve this answer
add comment

The fact that Scrum requires every damn workday to start with a meeting is, IMHO, micromanagement. Good developers don't need daily meetings to get their work done.

I find these meetings to be a huge PITA because I prefer to work at night. I've never done well at shops that required them. I've always done just fine at shops that just had a single weekly team meeting.

The fact that Scrum is increasingly popular these days is a major reason that I am self-employed and work out of my home office whenever possible.

The last W-2 job I had, my manager was this real freak who got to work every morning at six. He had the bright idea that we should have daily scrum meetings at eight. That's earlier than any shop I've ever worked at has required; I had an awful time with it.

share|improve this answer
1  
You don't understand what the Daily SCRUM is about, it is about fostering communication among the TEAM, it is NOT a daily status meeting for the manager. It is also called a Daily not Morning SCRUM for a reason. It is so you know what your team mates are doing, they know what you are doing and you can collaborate with them to make sure everyone knows what the plan is. If you don't play well with others, that is a personal problem, not a problem with Daily SCRUM meetings done correctly. –  Jarrod Roberson Aug 22 '11 at 12:50
1  
Jarrod, I play just fine with others. –  Michael Crawford Aug 22 '11 at 13:59
    
I've worked at several shops that started every morning with a meeting. One company did that years before the Scrum methodology was developed. As far as I can tell, the morning was a management technique used to get their coders to all show up to work every morning by a particular time. I never observed them to have any kind of positive effect on communication among the team. There are lots of other ways to achieve that. –  Michael Crawford Aug 22 '11 at 14:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.