Agile Micromanagement: TL;DR
Agile micromanagement is a result of the middle management’s resistance to change. Despite better knowledge, changing an organization into a learning one, that embraces experimentation and failure is not in the best interest of everybody. Self-organizing, empowered teams often conflict with the middle management’s drive to execute on personals agendas.
Agile and Its Proximity to Micromanagement
On the one side, we are getting increasingly better at understanding what management styles are actually creating value in the era of the knowledge economy. Service leadership, and self-organization as in holacracy, for example.
And we do have an idea, backed by one of the most robust findings in social science, what drives the individual knowledge worker. According to Daniel Pink, lasting motivation in the 21. century is fueled intrinsically by autonomy, mastery, and purpose.
On the other side, one of the most promising approaches—agile in its various flavors–has meanwhile gained sort of a tainted reputation. It has become regularly associated less with empowerment and self-organization, but micromanagement.
The idea that agile is bordering on micromanagement is not a new one. Mike Cohn himself suggests that it’s the team, that is micromanaging themselves for their own benefit. But he seems to be the only one to utilize the phrase “agile micromanagement” in such a meaning.
Mostly, when talking about agile micromanagement, practitioners refer to the dark side, to cargo cult agile:
- Developers often feel pressured to increase efficiency, deliver more output with the same headcount and be totally transparent at the same time. (Read more on this aspect in “Why Engineers Despise Agile”.)
- And product managers feel reduced to providing secretarial assistance to product design committees, churning out user stories on behalf of stakeholders.
Question is, whether this fate is inevitable for organizations of any size, maturity and origin—be it tech or legacy.
Agile Leadership vs. Management
A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves. (Lao Tzu)
Lao Tzu was an ancient Chinese philosopher and writer.
In his book “Drive: The Surprising Truth About What Motivates Us”, Daniel Pink defines three key ingredients for individual motivation:
- Autonomy: the desire to direct our own lives, aka not to be told what to do and how to do it
- Mastery: the urge to get better at something that matters
- Purpose: the yearning to do what we do in the service of something larger than ourselves.
What’s remarkable is that none of the ingredients has anything to do with money, a corner office, a parking place close to the lift or the size of a desk. In other words: typical insignia of a successful corporate career have little or no impact on the motivation of knowledge workers. (Speaking of which, you may now understand why engineers and product people just hate working on features “sold” by the sales department without asking them in an effort to meet sales objectives for bonuses.)
Fostering true motivation, therefore, requires leadership, not management: don’t tell talented people how to do their jobs, but empower them to achieve their objectives on their own.
Leadership in this George S. Patton style—“Don’t tell people how to do things, tell them what to do and let them surprise you with their results.”—is not a new thing. It has been part of the knowledge of military organizations for a long time. (Read, for example, “The Art of Action: How Leaders Close the Gaps between Plans, Actions, and Results” by Stephen Burgery, who describes in his book the “agile leadership” principles of the nineteenth-century Prussian army to deal with the unpredictable environment of the battlefield.)
This is also increasingly understood at the CxO level of organizations. Service leadership and agile innovation are either understood as a necessity to stay in business, thus preserving rank & privileges. Or they are regarded as worthwhile experiments, that need to be undertaken anyway to preserve an innovative image. In both ways, they are supporting personal agendas.
And it is certainly a truism for those operating in the trenches.
The interesting question here is: have the top and bottom of an organization thus already outflanked the middle management on the quest for the next innovative or disruptive product or technology?
Has everyone, except the middle management, understood that the organization needs to change into a self-organizing and learning organization—embracing experimentation and failure—to survive in the era of an ever increasing pace of innovation?
A middle management that is still entrenched in its functional silos, aiming at local optimizations and seeking fulfillment in budgets, Powerpoints and micromanaging their underlings?
Agile and the Middle Management
Michael McCalla wrote in his post Conservatives, Liberals, and Agilists:
Having thought about it at length, I have concluded that people within an organization that is undergoing an Agile adoption typically fall into one of three groups: Agilists, liberals, and conservatives. As in “real life,” these groups often clash.
Conservatives are the folks who protect their turf and are loyal to a traditional culture. Conservatives are set in their ways and not interested in change. They will most likely resist Agile. Typically, people in roles such as project managers, quality assurance, and architecture are those who fall within this group. The words empowerment, self-organization, and flexibility tend to make them cringe.
To my experience, the “conservatives” are most likely to be found in the middle management. And they have plenty of (personal) reasons to resist change. Try walking in their shoes for a while:
- The middle management usually lives to please their superiors. Mostly in the hope to be promoted themselves, once their superiors will climb the next step on the career ladder.
- Thus, change is generally not serving their personal agendas.
- And this is particularly true for agile change, given the risk of failure. “Agile” is a perceived as a loss of control, threatening their career goals.
- Ask yourself: would you entrust a bunch of hoodie-wearing nerds to deliver on your career objects in time and on budget?
- Self-organization, e.g. think Zappos and holacracy, is therefore actually a horror scenario for any career-minded middle manager: Being made obsolete by those reporting to her. (Reading tip: Here’s what happened to Zappos’ HR boss when the company got rid of managers and her job became obsolete.)
- Therefore, middle managers have an incentive to treat today’s knowledge workers like the farmers’ sons from Iowa in 1905, who back then were working on an assembly line for the first time. (Also known as “agile Taylorism”.)
- Which is the reason that we still have to cope with silo structures within companies. With “us vs. them” thinking, resulting in local optimization efforts instead of teaming up for corporate-wide, cross-functional collaboration.
- Moving from people management to service leadership—“it’s my job to make you successful, what do you need?”—is hence frightening them. It would require a totally different mindset by comparison: EQ, empathy, honesty, and trust.
- Service leadership requires the ability to embrace failure as an integral part of the innovation and learning progress. Think of Thomas Edison: “I have not failed. I’ve just found 10,000 ways that won’t work.”
- Service leadership also requires to let go and resist the temptation to tell people how to do their job. (And enjoy the instant gratification it delivers.)
- It also collides with the western ideal of innovation based on the Steve Jobs model: a single creative individual is pushing through disruptive technology. However, a new study out of Harvard and the London School of Economics shows that the heroic inventor Is a myth; great ideas are team efforts.
- Agile innovation also interferes with the typical “we know what we need to build for our customers” attitude of the middle management. A “good manager” knows what to do and how to solve a problem. She is not “weak” by admitting that she has to guess herself. That she has to observe, to ask, and to include the customer in the product discovery, improvement, and delivery process.
Conclusion
From the conservative middle manager’s point of view, there are many reasons why sticking to a command and control management style looks personally beneficial. Hence, there is a temptation to adapt any agile transition to the requirements of her very own local optimum, resulting in agile micromanagement. Which ultimately contradicts the purpose of empowering self-organizing team at an organizational level.
In my understanding, knowledge workers, therefore, don’t despise agile per se. They just despise what managers turn the idea of self-organizing teams into in everyday operations. Because they’re not leaders. Because they put their own personal agendas above the organization’s future success. Because they fail to contribute to evolving an organization’s culture to embrace experiments and failure by providing autonomy, mastery, and purpose to their people.
Software is eating the world. Every company with a bright future is nowadays also a software company. All are depending a great deal on the input from their knowledge workers in an ever increasing competition. Think Google, Facebook, Uber, Tesla, and Amazon. The majority of them is leadership-driven. Even Microsoft seems to be no longer stuck in the past, pursuing a management concept that worked well in the heydays of General Motors and Taylorism.
Today’s management-driven organizations, that fail to recognize this development, will make themselves obsolete over time. They will fail to compete with these leadership-driven organizations at product-level. And they will suffer a really unhealthy disadvantage in the war for talent.
So, the question remains: how do we—the knowledge workers—free yourselves from old-school management practices? From managers that are stuck in their socialization by command & control practices?
Is quitting a management-driven and joining a leadership-driven organization the only solution? (As the saying goes: there is no project interesting enough that you just couldn’t walk away from it.) Or can those managers be taught new tricks, can they change their mindset and become leaders instead?
I am curious to learn more about your ideas—please share those in the comments…