TL;DR: Why Agile Turns into Micromanagement
Agile turns into micromanagement as 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 everybody’s best interest. Self-organizing, empowered teams often conflict with the middle management’s drive to execute personal agendas, self-preservation being one of them.
You guessed right: it is time for a rant and short “checklist” to get the discussion going in your organization.
Update 2020-10-11: I added new content, updated the ‘State of Agile Checklist,’ and fixed some content debt.
🗞 Do you want to get this article in your inbox in the future? You can sign up here for our weekly ‘Food of Agile Thought newsletter’ and join 29k other subscribers.
I. Agile and Its Proximity to Micromanagement
On the one side, we are getting increasingly better at understanding what management styles create value in the era of the knowledge economy, uncertainty, and complexity. Servant leadership and self-organization, for example, have proven time and again to be starting points for moving toward serious value creation.
Also, we 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 21st century is fueled intrinsically by autonomy, mastery, and purpose.
On the other side, some of the most promising approaches—“agile” in its various flavors–have meanwhile gained sort of a tainted reputation. “Agile” 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 suggests that it’s the team, that is micromanaging themselves for their own benefit. However, 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 and predictable at the same time. (Read more on this aspect in “Why Engineers Despise Agile”.)
- Product managers feel reduced to providing secretarial assistance to product design committees, churning out user stories on behalf of stakeholders.
The Question is, whether this fate is inevitable for organizations of any size, maturity, and origin—be it tech or legacy.
II. Check Your Organization for Agile Micromanagement
You can download a free PDF for a quick poll to check the state of agile micromanagement within your organization. Thus, you can determine whether your organization makes progress in becoming a learning organization, dedicated to creating value for its customers, or not.
If you do so, I would appreciate your feedback on how this worked out for you and what kind of failure patterns you would add to complete the list in your eyes.
Cannot see the subscription form?
Please click here
Cannot see the subscription form?
Please click here
III. 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 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 by providing guidance and support.
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 C-level of organizations. Servant leadership and becoming a learning organization 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 stay ahead of the competition. In both ways, they are supporting personal agendas at the C-level as well as necessary innovative approaches to dealing with a VUCA world.
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, learning organization, a team-of-teams—embracing experimentation and failure—to survive in the era of an ever-increasing pace of innovation?
On the other side, does the middle management stay entrenched in its functional silos, aiming at local optimizations and seeking fulfillment in budgets, leaving traces in SharePoint, and micromanaging their underlings?
IV. 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 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 middle management. And they have plenty of (personal) reasons to resist change. Try walking in their shoes for a while to better understand agile micromanagement as a concept:
- 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, a change that is challenging this succession ladder is generally not serving their personal agendas.
- This is particularly true for agile transformations, given the risk of failure. “Agile” is 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 on time and a budget? (We talk about their ability to pay the mortgage and put the kids through college.)
- 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 worked at 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 organizations. 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 servant 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.
- Servant 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.”
- Servant leadership also requires letting 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 recent 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.
V. Agile Micromanagment: 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 adopt an 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, for example, Scrum. They just despise what managers turn the idea of self-organizing teams into everyday operations because they are servant leaders by name only. Because they put their 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 on a great deal on the motivation, creativity, and skills from their knowledge workers in an ever-increasing competition. Think about Google, Facebook, Uber, Tesla, Shopify, Stripe, AirBnB, and Amazon. The majority of them are leadership-driven. Even Microsoft is 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 the 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 ourselves 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 to escape agile micromanagement? (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…
✋ Do Not Miss Out: Join the 8,400-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now, all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Related Posts
📅 Scrum Training & Event Schedule
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.