2026-10-25
October 25, 2026
The manager role is not disappearing. It is splitting, and the half that survives is the one closest to judging whether the work is actually good.
For a decade, technical leadership rested on an unspoken assumption: producing the work was the hard part. Managers existed to staff it, sequence it, unblock it and report on it. Every ritual we run, from planning to status to the weekly sync, is a mechanism for converting scarce production capacity into predictable delivery.
AI changes the price of production, and it does so unevenly. Code, drafts, plans and summaries are now cheap to generate. What did not get cheaper is deciding whether any of it is right, safe, coherent with the rest of the system, and worth shipping. The constraint moved from making to checking, and most leadership structures were not built around checking.
This is the thread running through the best recent writing on the manager's role. If you lead engineers, programs or both, the useful question for the next three years is not "will my job exist?" It is "which version of my job am I being offered, and is it the one near the verification bottleneck?"
Start with what the data says, and with how much of it is soft. LeadDev's Engineering Leadership Report 2026, a survey of 600 engineering leaders, reports that 37% are doing more hands-on technical work than before, that about one in three managers is considering leaving management for an individual contributor role, and that 45% are working more hours than a year ago. Only the free preview of the report is public, so treat those as directional. They still describe a population being pulled in two directions at once.
Lukasz Olczyk, writing in April 2026, gives that pull a shape: the role is splitting into a hands-on version and an orchestration version, and the squeezed part is the manager of a single team sitting between the team lead and the director. His claim that much management work was structural overhead from the 2015 to 2022 growth years, kept alive because nobody removed it, is plausible, and also his most unfalsifiable. Note that he cites statistics without sources in the piece, so lean on his structure, not his numbers. He names three roles he expects to last: technical lead-managers, platform and developer-experience leaders, and senior delivery leaders at director level and above. If you are a Staff TPM, that last category is your category. It is also a warning. "Delivery" survives only when it means owning outcomes across boundaries, not collecting updates.
Now the counterweight. John Farrier, in a March 2026 essay on span of control, argues that managers are a complexity constraint, not a cost lever. Citing Gallup, he notes the average number of direct reports per manager rose from 10.9 in 2024 to 12.1 in 2025, and he argues that AI increases code volume without increasing a manager's capacity for coaching, feedback, prioritization and trust. His line is worth keeping on a wall: protect the human bottlenecks more aggressively. Add the communication-link arithmetic he cites from PMI, n(n-1)/2, and the point is hard to dodge. Six people have 15 links, eight have 28. Coordination cost is nonlinear, and no model reads the room for you.
Put those together and a picture emerges. Production capacity is inflating. Human attention is not. The organizations that win will be the ones that deliberately spend their scarce attention on four things: verifying outcomes, setting the decision rights that let agents and people act without waiting, developing the people who will do the verifying, and holding the cross-team coherence that no single team can see.
Marty Cagan's framing from the product side rhymes with this. In his two-years-in review of AI product management, he argues the PM role becomes more essential and more difficult, and he warns that speed in building does not guarantee better outcomes. The same logic applies to us. A TPM who used to earn trust by producing the cleanest status report now competes with a summarizer. A TPM who earns trust by saying "this plan will fail at the vendor handoff, here is the evidence, and here is the decision we need by Friday" is doing something the summarizer cannot, because it requires judgment about consequences.
What does this mean for how you spend the next quarter? Three shifts, in order of cost. First, audit your calendar for production-shaped work you still do by hand: assembling decks, chasing updates, restating decisions. Automate or delete it, because it is the work most exposed. Second, identify your verification points: the places where a wrong call is expensive, such as launch gates, migration cutovers and data-quality checks. Make sure a named human, with time and standing, owns each one, and that your agents' output flows through them rather than around them. Third, stay close enough to the work to judge it. Both Olczyk and the LeadDev numbers suggest the middle gets hollowed out first, and the middle is where leaders lose contact with the system they are supposed to evaluate.
None of this requires a reorg or a new title. It requires deciding, explicitly, where your judgment is the product.
Try this week. List the five decisions on your program where a wrong call would cost the most. Next to each, write the name of the one human who verifies the input before it is acted on, and the date they last looked at the underlying evidence rather than a summary. Any blank or stale cell is your first fix.
What it is. A prospective-hindsight exercise from psychologist Gary Klein: the team assumes the plan has already failed, then works backward to explain why. It legitimizes doubt that people otherwise suppress once a plan has momentum.
When to use it. Just before committing to an irreversible or expensive plan: a migration cutover, an AI rollout, an org change, a launch date. Most useful after the plan is drafted and before it is announced.
How to run it:
When NOT to use it. When the decision is cheap and reversible, or when the group will treat the exercise as theater because the decision is already made.
Example: for an agent-assisted release pipeline, the independent-writing step is where the quiet SRE says "nobody owns the rollback review."
Engineering Manager Span of Control in the Age of AI — John Farrier's case that wider spans optimize the wrong bottleneck; useful ammunition when someone proposes 12-plus direct reports because "the team is faster now."
The State of Engineering Management in 2026 — Lukasz Olczyk on the hands-on versus orchestration split of the role; read the structure, verify the statistics, which he does not source.
The Engineering Leadership Report 2026 — LeadDev's survey of 600 leaders: more hands-on work, longer hours, and a third of managers weighing a return to IC. Only the preview is free.
"Protect the human bottlenecks more aggressively."
— John Farrier, "Engineering Manager Span of Control in the Age of AI" (March 2026)
Don't miss what's next. Subscribe to Critical Path: