How can be get sure that we're not implementing micromanagement in the field of software development?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Fictitious (hopefully) example :

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

Answer 5

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

Answer 6

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)

Answer 7

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.

Answer 8

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.