Middle Management in Flux
I sometimes talk to middle managers who started their Agile journey some years ago and are unhappy with the results: “In the beginning it all felt so easy and natural. Everyone was motivated and joined in. But somehow we lost the track when we grew and we seem to have fallen back to our old habits.”
If you start changing an organization toward an Agile mindset, there’s no real end. Agile is about creating an organization of continuous learning and the transformation is done when there is nothing new to learn, which will probably be never.
This puts an enormous challenge on middle management. In most organizations, lower management is responsible for actual delivery, upper management is responsible for keeping the organization prepared for the future, and middle management is responsible for stabilizing the organization.
Now continuous learning means that the organization is continuously in flux while the traditional tools of middle management are designed to prevent flux. This doesn’t mean that we don’t need middle managers anymore. Whoever is making that claim probably hasn’t understood its role. However, tools and mindset need to change dramatically.
The traditional tools of middle management are operational and organizational structures, role definitions, and centralized processes. There are huge investments in these structures and they’re usually defined as though there would be one best solution and the structures would never change. In learning organizations, these structures usually change faster than they take for design.
Consider shared services as an example. Generally, in larger organizations you find services that are best shared between several teams, value streams, or services. Security or user experience are good candidates. However, whether one of your security experts would better be working in the security team or in this large customer interface value stream is not clear — and may even change over time. And whether you really need a dedicated security team at all, or whether a community of service would be the better choice, is something you can find out only through experimentation. And again, this may change over time.
Agile provides you with the tools you need to run such experiments and to provide transparency about where experiments are needed. The most important tools are the feedback meetings defined in all Agile approaches, such as retrospectives, inspect and adapt meetings, or the seven Kanban cadences. This is where the need for experiments is detected, the experiments are defined, and their results are evaluated. In contrast to traditional organizations, this is usually done by all the people affected and not just by a small round of managers or method specialists.
Agile also defines a set of tools to create transparency about where action is needed. Kanban’s blocker clustering is probably one of the most advanced tools, but impediment backlogs as used by some organizations doing Scrum can also provide valuable insights, given that they are consistently used in larger retrospectives.
All this doesn’t happen on its own. The role of middle management in Agile organizations is to make sure the learning loop remains effective on all levels. It’s not only that the teams do retrospectives, but also that an overall structure of transparency and adaptive actions is maintained.
In situations like the one I initially described, we often learn that everyone was so focused on processes and structures that the growing team lost its ability to inspect and adapt — the feedback structures have not grown with the number of people.
The new role of middle management in Agile organizations is to ensure that the organization keeps on learning and adapting. This is not easy, and you need to grow toward a catalytic leader to fulfil this responsibility. But it’s far more rewarding than enforcing defined but dysfunctional central processes.