Is Lean-Agile micromanagement? Mike Cohn says “yes” but Mike’s use of the term excludes the “excessive” aspect of the conventional definition. An attention to detail is a good thing, making for better management, and Lean-Agile has the tools to make the detail transparent. Excessive attention to detail leads to the Fallacy of Control and horror – I don’t see this in Lean-Agile teams.
Micromanagement is excessive
Here are a couple of definitions of micromanagement:
Manage especially with excessive control or attention on details
Merriam-Webster’s Online Dictionary
Manage or control with excessive attention to minor details
There are a lot of common words in there: “manage”, “control”, “detail” and “excessive”. For me the word that stands out is “excessive”.
There are some common symptoms of Micromanagement. A micromanager:
- Monitors and assesses every step of a business process.
- Focuses excessively on procedural trivia.
- Requires constant and detailed performance feedback.
- Demonstrates “reportomania”, i.e. frequently asks for unnecessary and overly detailed reports.
- Avoids delegation of decisions and becomes irritated when a subordinate makes decisions without consulting them, even if the decisions are totally within the subordinate’s level of authority.
- Delegates to enable the micromanager to take credit for positive results but, for negative results, shift the blame to their subordinates.
I have worked for people like that. It isn’t fun. This behaviour is a result of the Internal Control Fallacy. Micromanagers believe they can control everything. Of course this isn’t true and these individuals get frustrated that so many things are out of their control; they react by trying to impose even more control.
It is the “excessive” interest in the detail that leads to a focus on procedural trivia, “reportomania”, lack of delegation, and blame shifting. Otherwise it is just management with an attention to detail.
Micromanagement is about detail
Micromanagement is only “good” if we change the definition.
Everyone is against micro managing but macro managing means you’re working at the big picture but don’t know the details
Henry Mintzberg cited by @ManagersDiary (19 Aug 2013)
Put another way, if macromanagement is management knowing only the big picture then micromanagement is management knowing the detail. And that is a good thing.
In a similar way Artem Marchenko distinguishes between high level micromanagement and and low level. He sees both levels of Micromanagement in Scrum:
Micromanagement in Scrum indeed happens if by micromanagement you mean staying in direct control over relevant things at both high and low level of abstraction. The trick is that direct control at different levels is strictly separated, employed by different people and serves the different purposes. Team is micromanaging its daily actions on the daily level and management micromanages the release content on the iteration level.
Mike Cohn, one of the Scrum luminaries, famously said Agile is all about micromanaging. Mike argues that three agile practices lend themselves to micromanagement: the daily scrum, continuous integration and pair programming. The big difference for Mike, however, is that it is the team doing the micromanagement rather than a manager.
The common theme here is an interest in the detail. For example, the practices Mike Cohn highlighted provide considerable transparency into what is happening, thus enabling better monitoring and control, but still leaves the decision on how the work happens to be the people concerned.
None of these examples includes the “excessive” aspect of the conventional, and evil, definition. It is only when the interest in detail tips over into “excessive” interest that we get problems.
References
Cohn, M. (2009, 13 September). Ssssh Agile is all about Micromanaging. Mountain Goat Software.
Marchenko, A. (2008, 11 February). Micromanagement in Scrum. Day to day control. Agile Software Development.