: You need to do a lot of high-priority, politically sensitive tasks soon.
: 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
: Management believes that workers are low in competence and/or low in motivation.
: 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.
: 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.
: But it's an emergency!!
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
Also Known As
: [other names]
Examples in the Literature
Examples in Practice
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 CowOrker
s. 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 B
uckDidntStopHere, 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 de
motivate your staff.
I'm reminded of the two strong manager rules:
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.
- The manager is always right.
- Whenever the manager is wrong, see rule #1.
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."
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.
One reason for MicroManagement
(especially when done by a manager who usually doesn
t 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.
See also DoorMat