The Thrashing Middle

Why middle managers are not blocking change — they are absorbing a design failure

Blog 5 in the Requisite Pace series

The standard diagnosis of middle management is wrong.

For years, the story has been that the middle is frozen: bureaucratic, risk-averse, slow, defensive, resistant to change. That story has justified wave after wave of delayering. Whole consulting practices have grown around the promise of removing the blockage.

But in the organisations I see, middle managers are rarely frozen.

They are thrashing.

Strategic cycles, governance cycles, delivery cycles, operational demand, customer pressure and compliance rhythms all converge on the same layer. The work of making those clocks mesh is happening, but informally — in the gaps between meetings, through escalation paths, side conversations, personal judgement and late-night sense-making.

The middle is not always blocking the system. Very often, it is where the system’s missing pace architecture has become visible.

That distinction matters.

If the middle were genuinely frozen, the obvious answer would be to remove it, replace it, automate it, or flatten it. But if the middle is thrashing, removal may make things worse. The work does not disappear. It migrates. It moves upwards to leaders already overloaded with strategic work. It moves downwards to teams without the authority to resolve cross-boundary tensions. It moves sideways into informal networks, workarounds and individual heroics.

You have not flattened the organisation.

You have concentrated the friction.

This post is about why that happens — and what it reveals about the real purpose of hierarchy.

The forgotten question

I introduced the thrashing middle briefly in Blog 3, where I argued that operating models need explicit mechanisms for coordinating domains that run at different tempos. I described eight: buffers, rhythms, triggers, guardrails, contracts, exception channels, boundary dissolution, and translation roles.

Only one of those relies primarily on a person: the translation role.

Yet in many organisations, the translation role has become the default mechanism for everything. Instead of designing the interface between strategy and delivery, governance and execution, regulation and innovation, or operations and transformation, organisations route the unresolved tension through people in the middle.

Then they call those people slow.

This is why the thrashing middle is such an important clue. It points to a question most operating-model work assumes it has already answered:

What is hierarchy actually for?

Not what is hierarchy officially for. Not what the organisation chart says. Not how many layers are affordable. But what work is the hierarchy actually doing in the system?

The answer, I think, is more interesting than the usual debate about control versus empowerment.

Hierarchy is pace architecture. It exists, at least in part, to manage the interaction between domains of the organisation that operate, legitimately, at different speeds.

A different level of analysis

The most serious defence of hierarchy came from Elliott Jaques, later translated into practice by Brian Dive through Decision Making Accountability. Their argument was that hierarchy exists because work at different levels carries different time horizons of judgement. Senior work looks further out; operational work sits closer to the present. The task of organisation design is to match individual capability to the time-span of the role.

That insight matters. Jaques was right that time is the right organising variable. A board, an executive team, a business-unit leader, a programme director and a frontline supervisor are not doing larger or smaller versions of the same work. They are making judgements across different time horizons.

But that is an individual-level explanation. It accounts for hierarchy in terms of the cognitive capacity of people to work with longer or shorter time spans.

Requisite Pace shifts the unit of analysis. The question is not which individual belongs at which level of work. It is how the system coordinates domains whose natural clocks differ. What matters is not the person at each level, but the set of clocks those levels are trying to hold together.

This view is not idiosyncratic. It echoes a long-standing idea in systems theory. In the study of complex systems — and in biology and ecology — hierarchy is understood to arise not chiefly from authority or control, but from differences in rate: parts of a system that change at different speeds. Herbert Simon made the point for complex systems decades ago, and hierarchy theory in the natural sciences has reinforced it since. The slower-changing levels exist to provide a stable context within which the faster-changing levels can operate effectively. Remove that context and the fast parts lose the structure that lets them move. Hierarchy, on this reading, is what allows different rates to coexist — which is precisely the work we keep asking the middle to do by hand.

That shift changes the diagnosis. And it changes the intervention.

What hierarchy actually does

Seen through a pace lens, hierarchy performs three functions: filtering, translation and buffering.

These are functions, not mechanisms. They describe the work that has to happen where two tempos meet. The eight interface mechanisms from Blog 3 — buffers, rhythms, triggers, guardrails, contracts, exception channels, dissolution and translation roles — are the means by which that work gets done. When the work is left undesigned, it does not stop. It falls to whoever sits at the boundary.

1. Filtering

Not every signal needs to reach every level.

Without filtering, the top of the organisation is overwhelmed by operational noise and the bottom is destabilised by every shift in strategic uncertainty. A board does not need to know every customer complaint. A frontline team does not need to process every movement in the long-term strategy. A product squad does not need to debate every regulatory horizon scan. An executive committee does not need to arbitrate every local operational trade-off.

Hierarchy decides what gets through to whom, in what form, and at what frequency. That work is constant. Most of the time, it is invisible.

When filtering works well, senior leaders see the signals that matter before they become crises, and operational teams receive enough strategic context to act intelligently without being flooded by ambiguity. When it fails, the symptoms are familiar: the board is surprised too late; the executive team drowns in dashboards; frontline teams are whiplashed by half-interpreted messages from above; and middle managers spend their lives deciding which noise to protect others from. This is the frantic-centre archetype — a layer running hot not because its people lack discipline, but because the filtering it should perform has never been designed.

2. Translation

Strategic intent is usually expressed in the language of ambition, priorities, trade-offs and future positioning. Operational work is expressed in the language of capacity, sequencing, constraints, exceptions, customers, systems and people. These languages do not automatically meet.

Someone has to translate multi-year intent into quarterly priorities, quarterly priorities into monthly resource decisions, monthly choices into weekly work, and weekly learning back into strategic adjustment. This is not simple communication. It is interpretation across time horizons.

A good middle manager is often a translator between languages that have no shared vocabulary: the language of strategy and the language of delivery; the language of governance and the language of flow; the language of risk and the language of customer demand. When translation works well, intent remains coherent as it moves down the organisation, and reality remains intelligible as it moves up. When it fails, strategy becomes slogans, delivery becomes activity, governance becomes delay, and the middle becomes the place where everyone complains that “they don’t get it.”

3. Buffering

Fast-moving domains need insulation from slow-moving ones. A digital product team cannot stop every fortnight to wait for an architecture board that meets monthly. A customer recovery team cannot pause every exception until the next policy forum. A cyber incident team cannot wait for the annual budget cycle.

But slow-moving domains also need protection from fast-moving demands. Architecture cannot be rebuilt every time a product manager has a new idea. Risk appetite cannot be reinvented for each commercial opportunity. Regulatory assurance cannot be compressed endlessly without losing its purpose. Capability building cannot be run permanently at crisis speed.

Hierarchy provides shock absorption between these domains. It allows different speeds to coexist without one destabilising the other, protecting fast loops from inappropriate delay and slow loops from inappropriate acceleration. That is not bureaucracy. It is a necessary condition for coherence.

A simple example

Take a digital product team in a regulated business. Customer signals arrive daily. Product decisions are made fortnightly. Architecture is reviewed monthly, risk appetite quarterly, regulatory interpretation over years, budgets annually, and capability-building slower still.

Now follow a single signal. On Monday, a support pattern surfaces suggesting a new feature is pushing customers towards a workaround that may breach a conduct rule. Is that noise, a product fix, a risk escalation, or an architecture problem? Someone has to decide — fast enough to matter, but not so fast that the decision bypasses the slower clocks it touches.

Someone has to turn a quarterly risk-appetite statement into a constraint the squad can apply this sprint, and turn Monday’s incident into something the quarterly forum will actually act on. Someone has to keep the product team moving while the architecture board deliberates, and keep the architecture board from being stampeded by every sprint.

In many organisations, that work is not in the process map. It sits in the middle manager’s calendar. More than that, it sits on their shoulders: they are holding the coherence of the whole arrangement together and carrying the risk if it fails — informally, and usually without explicit mandate.

This is the hidden dependency. The organisation has not designed the pace interface, so a person absorbs it. Then, when that person looks overloaded, slow, cautious or difficult, the organisation diagnoses a people problem.

But the failure is in the design of the work.

This is not a defence of hierarchy

It is important to be precise here. This is not an argument that hierarchy is always good. It is not an argument that middle management should be protected. It is not an argument against flattening.

Some hierarchies have accumulated layers that add little pace value. Some layers exist mainly as status architecture or career architecture. Some organisations genuinely need fewer levels, clearer accountability and shorter paths between decision and action.

The point is different. Do not defend or remove a layer until you understand the pace work it is doing.

Hierarchy is often the place where missing mechanisms have accumulated. It is where the organisation has routed work that could, in principle, be done by better rhythms, clearer guardrails, stronger contracts, automated controls, risk-tiered pathways, explicit exception channels, or better-designed boundaries.

So the question is not: should we keep the middle? The question is: what work is the middle currently carrying, and where will that work go if the layer disappears?

If the answer is “we don’t know,” then delayering is not simplification. It is displacement.

When delayering removes the wrong thing

When organisations delayer without diagnosing the pace work, the results are predictable. The filtering, translation and buffering do not disappear with the layer. The formal level goes; the temporal problem stays. It reappears as overloaded executives, confused teams, shadow governance, informal escalation, side-of-desk coordination — and the quiet return of the very bureaucracy the restructure was meant to remove.

This is why some flattened organisations do not feel faster. They feel more chaotic. They have removed a visible layer while leaving the underlying pace architecture undesigned. On paper, the organisation is leaner. In practice, the friction has been pushed into fewer, less visible places — and the people now carrying it have less authority and less context than the layer that used to.

The deeper cost shows up later, and it connects to Lens 3 of Requisite Pace. In Blog 4, I argued that an organisation’s ability to reconfigure — to become something different when conditions shift — depends on protected degrees of freedom across resource, temporal, structural, governance and capability dimensions. Hierarchy sits in the structural dimension, and the undocumented pace work sits inside hierarchy.

So delayering without diagnosis can quietly destroy reconfiguration capacity. It looks like efficiency and feels like simplification. But if the removed layer was filtering signals, translating intent or buffering volatility, the organisation has not merely reduced overhead. It has removed part of its capacity to change shape — and because the work was never named, there is no obvious way to rebuild it when the next discontinuity arrives.

This is the optimisation lock-in archetype hiding inside an efficiency programme: the organisation makes itself leaner in the present by borrowing against its ability to adapt in the future.

A testable hypothesis

I want to be direct about the status of this argument. Hierarchy-as-pace-architecture is not a theorem. It is a structured hypothesis, built from patterns across IT, financial services, regulated industries, transformation programmes and large operational businesses. But it is testable.

The test would map the pace flows converging on a middle-management role. How many distinct cycle times does the role sit between — daily demand, weekly delivery, monthly governance, quarterly performance, annual planning, multi-year architecture? How many of those interfaces are held by structural mechanisms, and how many depend on the manager’s personal judgement? Has anyone designed how those cycles are meant to mesh, or are they simply colliding in the calendar?

Two predictions follow. First, the managers facing the most incoherent pace convergence — the most cycles, the weakest mechanisms, the least explicit authority — should show the highest levels of what organisations label resistance, overload or burnout. The strain should track the design failure, not the person. Second, organisations that have recently delayered should show intensified convergence at the remaining levels: the symptoms should not disappear, they should move.

That can be tested, mapped, and diagnosed before the next restructure. The reason it usually is not is that the dominant diagnosis gets in the way. If the middle is assumed to be frozen, the question becomes how to remove or bypass it. If the middle is thrashing, the better question is: what unresolved pace work is showing up there?

I am now working to test this directly, and I am looking for organisations willing to be part of that work — particularly those that have recently delayered, or are weighing it up. If you would value mapping the pace flows converging on your own middle, I would like to hear from you.

What leaders should do differently

If this diagnosis is right, three things change in how leadership teams approach operating-model design.

1. Stop trying to fix the middle by changing only the people

Of course capability matters. Some managers are better than others. Some should not be in the roles they hold.

But if the work the layer is carrying is larger than any individual can reasonably absorb, better selection, training, coaching, communication or engagement will not solve the underlying issue. The fix is in the design of the work.

If a role is expected to translate between seven incompatible cycles, filter every signal, buffer every tension, protect delivery from governance, protect governance from delivery, absorb strategic ambiguity, and maintain team morale, the problem is not resilience. It is load.

2. Treat interfaces as the unit of design

The question is not only “what is the structure?” The better question is: where do different clocks meet, and what mechanism helps them mesh?

At each high-friction boundary, ask:

• What is being filtered here?

• What is being translated?

• What is being buffered?

• What mechanism is doing that work today?

• Is that mechanism appropriate for the tempo difference it sits across?

• Is too much of the work being carried by a person rather than by design?

Sometimes the answer will still be a role. Translation roles are real and necessary. But they should not be the default answer to every unresolved interface. Some work needs a rhythm. Some needs a guardrail. Some needs an exception channel. Some needs a buffer. Some needs clearer decision rights. Some needs boundary dissolution. Some needs automation. Some needs a different cadence of governance.

The aim is not to remove human judgement. It is to stop using human judgement as compensation for poor architecture.

3. Treat delayering as a structural decision with reconfiguration consequences

Delayering is often framed as an efficiency move. It should be treated as a structural design choice that affects the organisation’s future adaptability. Before removing a layer, ask four questions.

What signals does this layer filter? If the layer disappears, will those signals reach the right place faster, or will they arrive as noise — or not arrive at all?

What intent does this layer translate? If the layer disappears, how will strategic intent become operational action, and how will operational learning become strategic adjustment?

What volatility does this layer buffer? If the layer disappears, which teams or functions will be newly exposed to pace demands they cannot absorb?

Where will the work go? If the answer is “to the remaining leaders,” “to empowered teams,” or “into the flow,” be specific. What capacity, authority, mechanisms and rhythms will make that true?

Sometimes, after asking those questions, the right answer will still be to flatten. But the decision will be made with visibility of the pace work being removed, and with a deliberate plan for where that work will go. That is very different from assuming that fewer layers automatically means less bureaucracy. Sometimes it means fewer places for friction to be handled intelligently.

Pace is a system property

The principle running through this series is simple. Pace is not primarily a property of individuals, or even of teams. It is a property of the system.

A fast team trapped between badly designed interfaces is not fast. A governance forum producing good decisions at the right cadence is not slow. And a middle manager who looks resistant while absorbing seven incompatible cycles is not necessarily the resistance. They may be the symptom.

Organisations misread this because they measure speed in isolation. They call one team agile and another bureaucratic, celebrate acceleration at the edge, and complain about governance drag without asking whether governance is slow for a reason, slow by neglect, or simply running at the wrong cadence for the work it governs.

Speed, taken alone, is a poor diagnostic. Timing is the better one. The question is not whether a function is fast or slow, but whether it runs at the pace its role in the system requires — and whether its interfaces with other paces have been designed.

That is why the thrashing middle matters. It is not a complaint about middle management. It is a clue. It shows where organisational clocks are colliding without architecture, where translation, filtering and buffering are being done informally, and where a transformation programme will find a hidden dependency — often only after it has removed it.

If your change programme keeps breaking against the middle, it is worth asking whether the middle is really the problem. It may be the place where the absence of interface design has become visible.

Speed isn’t the issue.

Timing is.