What Happens To Middle Management
The hardest unanswered question in most transformations. Why self-organisation is heard as redundancy, which management jobs become more valuable rather than less, and how to sequence the change so managers become allies.
Every transformation deck has a slide about empowered, self-organising teams. Almost none has a slide about what the forty people currently managing those teams will do on the Monday after. The omission is not accidental — it is the hardest question in the programme, and it is easier to leave it implied than to answer it. But the people in the room do the arithmetic immediately, and they reach a conclusion that the deck never stated and the programme never intended.
They conclude that the plan is to remove them. And because they are, collectively, the layer that controls headcount, budget approval, promotion, prioritisation in practice and the informal flow of information through the organisation, a transformation that fails to answer this question does not get a loud refusal. It gets slow, polite, comprehensive non-cooperation, distributed across dozens of small decisions that each look reasonable in isolation.
This is usually described afterwards as the frozen middle, which is a diagnosis that blames the layer for behaving rationally in response to an unanswered question. The layer is not frozen. It is waiting to be told what its job is, and in the absence of an answer it is defending the job it has. Any change programme that treats this as an attitude problem rather than a design problem will fight the wrong battle for two years and lose.
The question deserves a real answer, and there is one. It is not "nothing changes" and it is not "you are all coaches now". It is a genuine change in the unit of work, from managing work to managing the system that does the work, and it is a harder job than the one being replaced.
Why self-organisation lands as redundancy
Consider what a typical delivery manager actually does with their week. They allocate people to work. They track progress and report it upward. They chase things that are stuck. They resolve priority conflicts between their team and other teams. They make estimates credible enough to survive a steering group. They are, functionally, the routing and reporting layer of the delivery system.
Now read the standard description of an agile team. It pulls its own work. It self-organises around how to do it. It surfaces its own impediments. It forecasts from its own data. It talks directly to its stakeholders and its customers.
Every activity on the first list has been assigned to the team on the second. The manager has not been given a new job; they have been told their existing one is now performed by someone else. When they hear the word empowerment, they are not being cynical or change-resistant. They are reading the design correctly.
Managing work versus managing the system
The distinction that resolves this is between two activities that are easily confused because both are called management.
Managing work means deciding who does what, tracking whether it is happening, and intervening when it is not. It operates on individual items and individual people. It scales linearly with the volume of work, which is why organisations that manage this way acquire more managers as they grow.
Managing the system means changing the conditions under which work happens so that less intervention is required. It operates on structures: team boundaries, skill distribution, the queues between teams, the funding mechanism, the approval chain, the information flow. It does not scale with volume, because a structural fix applies to all future work.
| Managing work | Managing the system | |
|---|---|---|
| Unit of attention | Tasks and individuals | Structures and flows |
| Typical activity | Allocating, chasing, reporting | Designing, removing, funding, developing |
| Cadence of action | Daily | Weekly to quarterly |
| Effect of success | This item lands | All future items move faster |
| Scales with | Volume of work | Nothing — fixed cost, compounding return |
| What it looks like when absent | Chaos, visibly | Slow degradation, invisibly |
The second column is where the durable management job lives. The reason it is unfamiliar is that most managers have never had time for it, because the first column consumed the week. This is the genuine offer: the transformation is taking away the work that consumed your calendar and leaving you the work that was always more valuable and that you never got to.
That offer is only credible if it is true. If teams take on self-organisation and managers are still required to produce weekly status reports, chase individual tickets and approve every piece of work, you have added a job rather than exchanged one, and the resulting behaviour will be exactly what you would predict.
The jobs that become more valuable
Five areas of genuine management work survive and grow. None of them can be performed by a self-organising team, because each of them operates on a scope larger than the team or a timescale longer than the team's attention.
Capability building. Someone is accountable for whether this organisation has the skills it will need in eighteen months: identifying the gaps, deciding where to hire versus grow, running the communities of practice that spread expertise across team boundaries, and protecting the time learning requires when delivery pressure says otherwise. Teams cannot do this for themselves — they are correctly focused on the current quarter, and any one team's skill needs are too narrow a sample to plan against.
Team design. The single highest-leverage management activity and the most chronically neglected. Which teams exist, what each one is bounded around, how many dependencies the boundaries create, when to split a team that has grown too large, when to merge two that cannot deliver anything alone. Team Topologies gives a usable vocabulary for this — stream-aligned, platform, enabling, complicated-subsystem — and the underlying point is older: Conway's Law means your team structure is quietly determining your architecture and your delivery speed, whether or not anyone is deliberately designing it. A team cannot redesign itself out of a bad boundary. Someone above it must.
Removing organisational impediments. The things that slow every team and that no team can fix: the procurement process, the environment provisioning queue, the security review that takes a fortnight, the architecture forum with a two-week cadence, the shared service with no self-serve path. These require standing, budget and the ability to negotiate with peers in other functions. That is precisely the manager's positional advantage and it is the clearest place to demonstrate value early.
Performance, career and the difficult conversations. Self-organising teams do not manage anyone's career, cannot set compensation, and are notably bad at addressing sustained underperformance in a colleague. These remain management work, and they are harder in an empowered environment than in a hierarchical one, because the manager no longer directly observes the work and must assess contribution through outcomes and peer evidence rather than supervision.
Funding and boundary-setting. Deciding what the organisation invests in, what each team is pointed at, what constraints they operate inside, and what good would look like. Autonomy is not the absence of direction — it is clear direction with local discretion about method. Setting a clear enough boundary that a team can act freely inside it is a management skill, and it is more demanding than assigning tasks, because a badly framed boundary produces confident work in the wrong direction. The shift from project to product funding, covered in from project funding to product funding, is largely a middle-management change dressed as a finance change.
The jobs that genuinely disappear
Honesty here buys more trust than reassurance does, because managers can see the list themselves.
Task allocation goes. Status aggregation goes — if the system is visible, compiling a report about it is waste, and a manager whose value rests on being the only person who knows the true state of delivery holds an artificial monopoly on information. Being the routing point for cross-team requests goes, since the correct fix is to reduce the dependency rather than employ someone to negotiate it. Estimation defence goes. Approving work the team is capable of judging goes.
That is a substantial fraction of a traditional delivery manager's calendar, and for a minority of people it is close to all of it. Pretending otherwise is a mistake, because the population knows who they are.
The span of control changes too. Managing the system rather than the work means each manager can cover more teams, because structural work does not scale with volume. Organisations that make this transition well usually end up with fewer management positions and a broader, more senior version of each. Those that avoid saying so end up with the same number of managers, each doing a diminished version of the old job, which is the outcome nobody wanted and everybody predicted.
Sequencing the change
The manager layer is not an obstacle to route around. It is the layer that will implement the change, or not. Sequence accordingly.
Define the destination role before you announce the team change. Write the new management job description first — the five areas above, adapted to your context — and socialise it with the managers themselves before the teams hear anything about self-organisation. This costs weeks and saves quarters.
Let managers design the team structure. Team design is the most valuable thing on the new list and it is work they are genuinely better placed to do than anyone else, since they hold the organisational knowledge about skills, history and politics that an external programme does not. Handing them this early converts the layer from subject of the change to author of it, which is the single most effective intervention available.
Give them a real impediment backlog and real money. Nothing establishes the new job faster than a manager removing an obstacle that has irritated teams for years. Fund it, make the removal visible, and attribute it. This is how the new role acquires status, and status is what determines whether people move toward a role or defend the old one.
Change what you ask them for. Managers will do what their own manager inspects. If the weekly conversation with their director is still about task status and individual utilisation, the new job description is decoration. Replace those questions with ones about system health: what is the cycle time trend across your teams, which dependency are you eliminating this quarter, what capability gap are you closing, which team boundary is wrong. The leadership layer above middle management has to change its own behaviour first, and its unwillingness to do so is the most common reason this fails.
Retrain and resource it. The new job requires skills the old one did not: flow metrics and how to read them, team design principles, facilitation, coaching, negotiation across functions, financial framing. Assuming managers will acquire these by attending the same two-day course as their teams is not a plan.
Be straight about the numbers. If the end state has fewer management positions, say so at the start, with a timeline and a process. Managers are adults operating in a labour market. What destroys cooperation is not bad news; it is the suspicion of bad news being concealed, which converts every ambiguity into evidence of a hidden plan.
Treat the resistance you do encounter as information rather than obstruction. A manager who fights a team boundary change often knows something about the domain that the transformation team does not, and the objection is frequently technically correct even when the motivation is mixed. Resistance is information applies with particular force at this layer, because these are the people with the longest memory of what has been tried before.
What to do on Monday
Write the new management job description — one page, five headings, specific to your organisation — and take it to your managers before you take it to anyone else. Ask them what is missing and what is unrealistic. Their answers will be more useful than the document, and the act of asking changes the conversation from something being done to them into something being designed with them.
Then pick one manager and one impediment that has annoyed teams for at least a year. Give that manager the authority and the budget to remove it inside a month, and make sure the organisation knows where the fix came from. One visible demonstration of the new job doing something the old job never could is worth more than an entire communications programme about empowerment.