Engineering Beyond Agile: No More Middle-Management? The Manager Becomes Five
The Engineering Manager was never one job — it was five accountabilities. Remove the role without naming where each one lands, and you orphan the work.
Recently, two tech CEOs made the same architectural decision and called it ✨efficiency✨.
Jack Dorsey, on Block: “There is no need for a permanent middle management layer.” Cut: roughly forty per cent of engineering managers.
Brian Armstrong, on Coinbase: “Rebuilding as an intelligence, with humans around the edge aligning it.” Cut: roughly fourteen per cent of management roles.
Meta is doing it more subtle. Pivoting from “we need fewer managers” to “we need more asynchronous, agent-driven management.” Singh, a former Meta principal, described what happens next on the record in the Guardian last week: “people lose touch with all the benefits you get from face time.”
These are not efficiency decisions, but architectural decisions about where governance lives — made publicly, in earnings calls and tweet-storms, without anyone naming what they actually are.
That is a ghost decision in its purest form.
What got removed
The story going around “AI is making managers obsolete” collapses a real question into a slogan. The real question is not whether you need fewer managers. It is: what was the manager actually doing?
Because if you cannot name what the role was doing, you cannot tell where its accountabilities have gone. They don’t disappear when the box on the org chart disappears. They redistribute. Silently. Into the next nearest container.
The Engineering Manager role was never one job. It was a composite of five accountabilities:
1. Architectural direction. The judgement call about which constraints the team will accept and which it will push back on. What we build, in what order, with what trade-offs made explicit. This is not “decide everything.” It is “make sure decisions are decisions, not drift.”
2. Context routing. Knowing what the team needs to know — about strategy, about adjacent teams, about customer pain — and getting it to them at the right time. The manager is the team’s API to the rest of the organisation. Strip the role, and either the team loses context, or some engineer becomes a part-time messenger.
3. Mentorship. The 1:1 that catches the engineer six weeks before they burn out. The pair-debugging session where a senior shows a junior how to read a stack trace under pressure. The reading list. The career conversation. None of this lives in JIRA.
4. Scrutiny. The “kick the tires” function. The “are we sure?” before a deploy. The sceptic who reads the design doc properly. The person who asks the awkward question in the architecture review. In a world where agents generate plausible code at speed, scrutiny is not a nice-to-have. It is the throttle on hallucination.
5. Judgement. The accumulated pattern-matching about this team, this codebase, this customer base, this organisation that lets the manager say “this looks fine, but it’s wrong” — and be right. Judgement is what compresses into the word “experience.” You cannot hire it. You cannot prompt it. You build it, in people, by exposing them to it over time.
These aren’t five hats one person wears. The role holds them as five distinct accountabilities. Remove the role without saying where each one lives now, and you orphan five functions.
Where the orphans land
Watch where each one lands, because this is where the cost actually shows up.
Block reportedly ran one engineering manager with 175 direct reports during the recent restructure. That story was reported as a curiosity. It’s a diagnostic. With 175 reports, nobody is doing scrutiny. Nobody is doing mentorship. Architectural direction collapses to whatever the loudest staff engineer pushes through. Context routing depends entirely on who happens to be in the right Slack channel at the right hour. Judgement gets replaced by velocity metrics.
The work didn’t disappear. Five accountabilities moved silently into five places:
Architectural direction moves to whichever senior engineer has the social capital to assert it. Often a male staff engineer with a strong opinion. Sometimes nobody. Either way, the org has informalised what used to be a named accountability — and put it beyond review.
Context routing moves into a Slack channel nobody is monitoring on purpose. Information travels by accident.
Mentorship moves to “ad hoc.” Which means: the engineers who would have grown into seniors over the next three years drift, then leave, then join Anthropic.
Scrutiny moves to the AI tools themselves. “We have automated code review.” You do. You have automated plausibility checking. Scrutiny is something else. Scrutiny notices that the code is plausible but wrong for this team’s reasons. No tool does that.
Judgement moves to the CEO’s tweet-storm.
This is the actual cost of the flattening. It does not show up in the next earnings call. It shows up six quarters later — when a senior leaves because they were quietly carrying three of the five accountabilities and got tired, or when a launch ships a feature that is technically correct and strategically wrong, or when a junior who would have been a great staff engineer in 2029 has instead drifted out of the industry.
The decision-speed gap
There is a related pattern I’ve written about elsewhere in this series, two months before the Guardian piece ran: Engineering Beyond Agile, Ep. 7 — Human Judgement.
The argument, in one line: AI makes execution cheap. It does not make decisions cheaper. In many cases, it makes decisions more expensive — because the speed of execution outruns the speed of judgement, and you can ship a bad call into production before anyone realised it was a call at all.
When you remove the managers, you are not removing a layer of slowness. You are removing the only layer that had time to think between the work landing and the work shipping.
That is the decision-speed gap. And it is the gap that swallows quality.
What technology leaders can do this week
Name the orphans in your own org.
Sit with a whiteboard. List the five accountabilities. For each one, write a name.
Architectural direction — whose call?
Context routing — who owns the path from strategy to team?
Mentorship — who is doing the 1:1 with the engineer who is about to leave?
Scrutiny — who is allowed to say “we’re not shipping this”?
Judgement — who carries the pattern memory for this codebase?
If you can name five distinct people, your org has not orphaned the role. If three of the names are the same person, that person is your single point of failure and they will leave within a year. If two of the rows say “AI” or “automation” or “the platform,” look harder. “AI” and “automation” aren’t accountabilities. They’re tools.
Stop calling the EM role overhead.
It was never overhead. It was infrastructure. The fact that we have not, as an industry, made it legible — that we cannot easily say what the role does on a Tuesday at 2pm — is a failure of vocabulary, not a failure of value. Until we have better language for the five accountabilities, every flattening pitch will sound like efficiency, and every cost will land in the wrong column.
This is also why “AI replaces managers” is the wrong sentence. AI replaces some of what managers were doing — calendar arithmetic, status compilation, performance-review prose. It does not replace any of the five accountabilities. It is plausible at one of them — scrutiny, narrowly defined as code-review-as-pattern-matching. It is structurally incapable of the other four. Mentorship requires being a fellow human in the same trade. Judgement requires a memory tied to a body. Architectural direction requires a stake in the outcome. Context routing requires reading the room.
The Block / Coinbase / Meta architecture only works if the five accountabilities are explicitly relocated, and someone is accountable for the relocation. As far as I can tell from the public statements, nobody is.
Why I’m writing about this now
There is a book in the works. Ghost Decisions. It’s about exactly this pattern — the architectural decisions that get made silently, by aggregation, in the gap between strategy and execution.
The flattening of management is the largest, most public ghost decision currently in flight in our industry. It deserves a full diagnosis, not a slogan. The structure I’ve sketched here is one chapter. The book is the implementation. Out soon. I’ll point at it again when it lands.
In the meantime: name your five.
More goodness in the book
This piece is part of the thinking behind my book, Ghost Decisions: How to Lead When AI Moves Faster Than You: ghostdecisions.com
e