A wave of tech layoffs has fallen disproportionately on middle management. Engineers are agent managers now. Designers and PMs are shipping directly. The Scrum and Agile coordination apparatus is getting stripped for parts. The word everywhere is “builder,” and if you are not one, it is game over.

I think the structural trend is real, the conclusion people are drawing from it is wrong, and flattening the org chart the way companies are doing it now is going to backfire.

The Two Jobs in One Title

Middle management was always two jobs bundled together.

The first is coordination: status aggregation, ticket routing, cross-team alignment, progress reporting. The second is development: one-on-ones, mentorship, career growth, teaching people how to communicate and work as part of a team rather than shipping something disconnected from whatever everyone else is working on.

Coordination is the part that died. AI gives leadership direct visibility into outputs, engineers self-organize around epics, and status updates generate themselves out of ticket state. Most of the coordination work was a workaround for a system of record that did not record anything useful, and the workaround is no longer needed. The development function did not go away with it; it detached from the title.

Where Business Context Comes From

Engineers work on epics because their agents handle the stories. Product works on initiatives because engineers handle the epics. That is a useful shift, but it requires engineers to carry far more business context than they used to need: the product, the customer, the strategy. Someone has to develop that in them. That was a middle-manager function.

The new “builder” identity obscures the same issue. Individual contributors now manage their agents, so management craft becomes baseline IC curriculum: delegation, setting expectations, defining done, giving feedback on work they did not do themselves, deciding when to inspect and when to trust. The layer getting cut is the layer that taught all of that.

The Math of the New Span

The structural argument does hold in one important way. If middle management was roughly two-thirds coordination and one-third development, and AI collapses the coordination portion, the remaining development work can be handled by a director at a wider span of control.

Old model: one director managing three middle managers, each managing three engineers. Thirteen people, three layers.

New model: one director managing nine engineers directly. Ten people, two layers.

Nine direct reports doing 30-minute weekly one-on-ones is four and a half hours a week. That is real work, but it is feasible for a director who is no longer spending the rest of the week aggregating status, writing update decks, and sitting in alignment meetings. Maybe 10:1 is the new ratio. Not because development got easier, but because coordination got cheaper.

The Size Threshold

This does not apply the same way everywhere. For a team of ten or fewer, I do not think a dedicated middle manager makes sense in this environment. If the manager is good enough to develop juniors, they are probably good enough to do the work themselves, and in a small team that is the higher-leverage use of budget.

But at a hundred people, flat does not work. You cannot have a hundred engineers and nobody getting developed. The coordination function can be automated, but the development function scales with headcount. Someone has to carry it.

The question is where the crossover lives. AI might push it higher because coordination is cheaper, or lower because juniors need to level up faster. I do not think anyone knows yet.

The Commons Problem

When every company adopts the “just hire seniors” strategy, nobody is developing juniors, and the senior pipeline dries up in three to five years. Someone has to run the farm system.

Historically, middle managers at big companies did that. If they are gone, who does? Distribute mentorship without a structure and you get a commons problem. Everyone is responsible for development, so nobody is accountable for it. The engineers who are naturally good at mentoring do it anyway and get no credit. The ones who are not, do not, and nobody notices until the junior washes out.

A project-lead rotation can help: engineers take turns as project leads, while a manager stays technically current by reviewing their execution. But it only works in organizations that deliberately build it.

The Function Needs a Replacement

Middle managers as a role are done. The coordination work that justified their existence has been automated. But the development function they carried persists. It is being absorbed by directors at wider spans, by senior engineers who happen to be good at it, or by fractional leaders who carry it across organizations that eliminated it internally.

The organizations that win from here are not the ones that simply cut the layer. They are the ones that build explicit mechanisms for the development function: director retraining, mentorship rotations, named project leads, and structured career paths that do not depend on a manager who no longer exists.

The role dies. The function does not. The question is whether you build a replacement or just hope it happens.