Micro Management

Type: Organizational

Problem: You need to do a lot of high-priority, politically sensitive tasks soon.

Context: Project development, product maintenance, or business operations where there is a high demand for "visible results" or there will bad consequences for those involved. This is an emergency.

Forces: Management believes that workers are low in competence and/or low in motivation.

Supposed Solution: Management "steps in" and directs the day-to-day and hour-to-hour activities of you and your coworkers in order to get things done, to deal with the (continuing) emergency.

Resulting Context: Today's emergency may subside; some workers are likely to feel less competent and less motivated. Over time, the competent/motivated workers will be motivated to VoteWithYourFeet and move on. The manager's belief in this pattern will be strengthened two ways: First, the manager will feel more competent having renewed and/or exercised some technical skills rather than managing. Second, the talent level of the remaining workers will be lowered, so more management help will be needed.

Design Rationale: But it's an emergency!!

Related AntiPatterns: The micro management approach has the double "advantages" of IllusionOfControl and being AnAcceptableWayOfFailing, whereas the empowerment approach requires you to overcome your fears and trust both your subordinates and your own abilities as a leader. -- FalkBruegmann

Applicable Positive Patterns:

AntiPatternCategory: ManagementAntiPattern

Also Known As: [other names]

Examples in the Literature:

Examples in Practice:

Discussion

The first time I ever saw the un-hyphenated spelling of co-workers, it was in Dilbert. (I assumed the author was mildly tickled at the possibility of reading the word CowOrkers. Anyway - the PointyHairedBoss experimented with micro-management for a while. -- DominicCronin

PHB: "Move your mouse to the left! Left! NOOO! YOU FOOL!"

How does this relate to the BuckStopsHere pattern? To quote: When someone says "the buck stops here" they mean that, even though an underling might screw up, they (the person in charge) will either fix it, or accept the consequences personally.

When a big problem is noticed, the MicroManagement response is to:

direct, step by step, the underling's activities to address the big problem, and
dole out (or magnify) the consequences on the underlings

So, given these two points, the BuckDidntStopHere, but was passed 'one level down'.

But, if you define the BuckStopsHere as something that

determines who has the final word
determines who has the final move
determines who has the position of power

Then, the buck stops with the micro manager.

No, because the most important aspect of the BuckStopsHere is ultimately taking responsibility for and dealing with the consequences of failure, which most micro-managers will dodge by blaming underlings. See also below.

As a manager, you might say, "The BuckStopsHere - I take responsibility for the actions of my subordinates because I micro-manage and control each of their actions." - Or you might say, "I take responsibility for the actions of my subordinates because I saw to it that they were motivated, empowered and qualified to carry out their jobs."

Additionally, it is one thing to say "I will take responsibility for failure" and a completely different thing to really do it (and, for example, resign if the project tanks).

So, the stronger meaning of BuckStopsHere is where the consequences fall (i.e the MicroManaged?), not where the power to exercise those consequences comes from? --DaveParker

It is not just where the consequences fall, but that the buck-stopper has actively directed the consequences to fall on them, in advance of knowing whether those consequences will be good or bad.

A Manager's View

First, realize "Micro-Management" is a subjective term; you are unlikely to get agreement on whether any particular instance qualifies as micro-management.

Second, realize that no-one is fully knowledgeable and experienced in everything. A manager can choose to only assign tasks that an individual is fully qualified to perform, or he can choose to also assign tasks that the individual may not be qualified to perform.

Third, realize that deadlines are real. Just because you did not choose to do something about a "crisis" does not mean the crisis went away on its own. Someone resolved the issue and in a majority of cases, it was probably your manager.

When a manager closely oversees your work, realize that it means that in the manager's view you are not fully qualified to complete the work by the deadline (i.e., it is challenging work). The manager's current view is what it is; you cannot change it, but you can determine what his view will be in the future. The manager may believe that he can assign you similar work in the future with less oversight. The manager may believe you gave your best effort but the task failed; the manager will likely assign similar work in the future. The manager may question whether his current estimation of you is too high and more closely oversee other work as well. The manager may decide you are far too difficult to work with and bury you in sideline tasks.

That depends on your manager being genuinely concerned about quality of work, and not about their own (possibly fragile egos). These people tend to give instructions regardless of their appropriateness ("my way or the highway").

True stories: (caution, rants ahead)

My boss is watching another developer clear breakpoints in VisualBasic by using the menus. The boss insisted that he stop doing this, and instead use a convoluted keypress (Ctrl-Alt-F9). I'm not even going into how utterly stupid that is (this is more like NanoManagement!), but it's not even a quick way of accomplishing the same task! One wonders if he realizes that you can configure IDE's to use a keypress, toolbar button, or a foot pedal, if one desired.
Same boss, reviewing some MicrosoftAccess code. Pulls me aside and chides me for using comments that are too speculative, and says that if clients see these comments, they'll think our company is incompetent. I'm talking about stuff like "Consider refactoring this out to X module..." type stuff. I understand the importance of keeping comments that aren't redundant, but concern over our clients looking at it? I've never heard of a client looking at code, let alone to this level. Oh, and by the way, this was code written well over three years ago. Apparently we're supposed to retroactively change our coding style?

I guess my point is, don't assume the MicroManagement is coming from some concern over quality of the project. People are human, and surely ego may be a factor.

I can attest to the effects of MicroManagement writ large - no matter what one does, you can't satisfy your boss's requirements if his goal isn't about quality or product appearance. It's so I dread coming into work to hear what nitpicky thing he's going to come up with this time.

Am I being defensive? Possibly, but I'm sure this scenario plays out in countless development houses. All it does is demotivate your staff.

-- DanNovak

I'm reminded of the two strong manager rules:

The manager is always right.
Whenever the manager is wrong, see rule #1.

That of course is the manager's view. I would instead suggest making fun of a manager that attempts to micromanage. For example once came a manager that didn't like my writing style. I had a 90 slides power point presentation that he chopped off to just 9 slides. Then he said: "Apply this style" and gave another power point presentation with the institutional colors. Ok, I said, do I need to do it now? Yes, he replied why walking away at 11 pm, I need to present that at 9 am. Ok I said and before he was gone I typed Ctrl-C, Ctrl-V and voila. Done.

Of course he realized I was not going to spend the whole night while he was at rest. Whenever you outsmart him, you doesn't need to tell him, he will realize he can't micromanage you, because you have energy to do interesting stuff anyway.

In my opinion, micro management is characterized by focusing on what the manager knows how to do, rather than on what needs to be done.

For example, a manager who knows what a software bug is may focus on reducing the number of existing bugs, rather than on ways of reducing the introduction of new bugs. He thinks, "When there are no more bugs, the product will be ready."

-- BobBockholt

Here�s a difficult scenario: The Boss says (usually repeatedly), �I�m not a micromanager. I don�t micromanage,� and �I hate sycophants (you agree don�t you?).� This kind of manager reigns fire on anyone who openly resists bullying, and accepts affirmation from the Kiss Ass Dummies carefully selected for their ability to reflect the manager�s image. Such a manager would rather break it (or you) than admit not knowing how to fix it (or you), �fix� meaning �make it work the way I think it should work even if that�s wrong.� When it is not possible to remove this kind of manager, using the antidotes and understandings represented in the descriptions here can allow colleagues and superiors to manage work-around solutions. The PointyHairedBoss rebooting his computer by turning it upside down and shaking it is an example of creating a microcosmos for the micromanager to rule. Gradual reeducation and careful interventions can sometimes salvage the skills, knowledge, and abilities of someone with management or leadership responsibilities. Building a coalition inside the organization (with interfaces to entities outside the organization) which can act as an insulating vessel to convey the manager toward the future is often the best-available choice.

--PIM

One reason for MicroManagement (especially when done by a manager who usually doesnt do it) is to be seen doing something about a (perceived or real) problem. The manager who sits back and watches (or directs work at a high-level, as is preferred) while the project slips is schedule is often perceived as not doing his job by more senior management--even if the reason for the slip is beyond the manager's control (or would take time to remedy). Often times, the proper response to such an occurrence are either politically unacceptable (accept the slip, assign more resources) or long-term solutions only (firing the incompetent developer not meeting his deadlines won't fix the problem until his replacement is hired). It is part of human nature (both among developers and managers alike) to DelayBadNews; micro-management is one way that a manager can DelayBadNews in the hopes that it will go away.

More than that, by giving the impression of actively doing something about the problem also provide the benefit of CoverYourAssets. Someone will always ask "What have you done about it?" during the eventual BlameStorming sessions. For some management types, trying hard is more important than getting useful results, by practicing MicroManagement when there are problems, the micro-manager is showing his boss he is doing "trying very hard" against the problem.

CategoryAntiPattern, CategoryManagement