The State of Engineering Management in 2026

A few months ago, I wrote about Agile growing up. The middle layer of facilitation roles (Scrum Masters, coaches) got squeezed, and I argued the squeeze was mostly fair. The work hadn’t kept up with what teams actually needed. The market noticed.

Now it’s engineering management’s turn, and the story is less tidy. The role isn’t being absorbed back into the work the way Scrum Master responsibilities were. It’s being split in two, with a real chance that one half disappears and the other half becomes something most people who took the manager path didn’t sign up for.

I want to write this one without the armour. The previous piece reads, on a re-read, like a guy auditioning for a board seat and, unbelievably, reeks of McKinsey deck. That guy is fine, but he’s not who I am right now, and the polish actually obscures what’s worth saying. So here it is plainly: engineering management in 2026 is in worse shape than Agile was in 2025, and the people in those roles are not, on balance, being told the truth about what’s happening to them.

What the numbers really say

The headlines are hard to miss. Oracle cut around 30,000 people in the spring, with middle management explicitly named as a target. Amazon is roughly 30,000 down across two waves, with the official line being “reducing layers, increasing ownership, removing bureaucracy”, which is standard corporate language for “we have too many managers.” Meta is taking out around 8,000 engineers in 2026, with large swaths of middle management included. ASML, of all companies, said it would cut 1,700 mostly management roles in IT and tech and convert those positions to engineering.That last one is worth pausing on. A semiconductor giant is publicly telling the market that managers are the cost and engineers are the value, and that the trade is one-for-one.

Tech sector unemployment hit 5.8% in early 2026, the highest since the dot-com bust. The median time to re-employment increased from 3.2 months in 2024 to 4.7 months now. For senior and executive roles, 6 to 9 months is typical. The Q1 2026 cuts were the highest first-quarter total since 2023.

The mechanics are also visible in the surviving org charts. Microsoft has been pushing toward a 10:1 engineer-to-manager ratio, roughly doubling the span of control from a few years ago. The phrase you see in restructuring memos is “flattening”, a euphemism, but a precise one. Layers of director, senior manager, and team lead are being collapsed into fewer, broader roles, and the people running those broader roles are expected to stay closer to the work.

This is not a recession story, though. Meta’s revenue is up 22% year over year. Oracle is fine. The cuts are funding GPU clusters and AI infrastructure, not paying down debt. The industry is deliberately going flatter and spending the saved payroll on machines.

The role is splitting

If you’d asked me five years ago what an engineering manager did, the answer would have been some mix of: shielding the team, growing people, running the operational rhythm, owning delivery, occasionally weighing in on architecture. Hands-off coding was a sign of seniority, not a problem.

That picture is gone, and what’s replacing it depends on which side of a fork you land on.

On one side, the role is moving back toward the keyboard. The DX/Jellyfish data from Q1 2026 shows that engineering managers who use AI daily are now shipping roughly 4x as much code as they did a year ago, up from 2x in Q4 2025. One might think managers have more time, but that’s not it. It’s just that the cost of getting back into a codebase has collapsed. You can land in unfamiliar code, ask an agent to walk you through it, ship a non-trivial change, and be back in a 1:1 within two hours. Managers who used to apologise for being out of the code are now expected to be in it.

On the other side, the role is moving toward the orchestration of agents and humans together. Every developer is starting to look a bit like a manager: describing intent, reviewing output, catching slop, making tradeoff calls, and managers above them are managing “managers-of-AI”, with all the new failure modes it inevitably brings. Code volume is going up faster than review capacity. Quality is more volatile, not less. Junior engineers can produce more code than their seniors can sanity-check.

Both versions of the job exist now, often in the same company, sometimes in the same person on different days. What’s not really left is the version where the manager is mostly a coordinator and a people grower. That role is the one being cut, and it’s what most “engineering manager” job titles described until recently.

Why is this happening

The standard story is “AI made managers redundant.” That’s partly true and mostly a cover.

The cover part: status reports, sprint tracking, basic resource allocation, and a fair chunk of cross-team coordination are now things AI does adequately. Not brilliantly. Adequately. And it turns out to be just enough, because most of that work was already done badly by humans who didn’t enjoy doing it.

The actual story is older than AI. A lot of engineering management work in the 2015–2022 period was paperwork generated by the org’s structure, not by engineering. Layers existed because companies were growing, and someone needed to absorb the headcount. When growth stopped, the layers stayed, and now there’s a tool that makes it cheap to argue they shouldn’t. AI gave executives a respectable reason to do something they’d quietly wanted to do for two years.

The people getting laid off in the middle layer are, in many cases, not bad managers. They’re managers whose roles were designed for a company that no longer exists. The ones surviving are those who can credibly contribute to the technical work or operate at a level high enough that the work involves real strategic judgment. The middle, where most of the role lived, is the part being squeezed.

It is genuinely uncomfortable to write because it’s uncomfortable to be in. If you spent five or ten years building yourself into a manager identity, with calendars full of 1:1s and your sense of competence wrapped up in your team’s morale numbers, being told that what you do is “connective tissue” being optimised away is genuinely brutal. The career path you were sold is being deprecated in real time, and most companies won’t have a graceful conversation with you about it.

What survives

Three kinds of engineering management roles look durable to me, and I’d put my money on these if I were betting on a five-year horizon.

The first is the technical lead-manager, sometimes called TLM. Small team, six to ten engineers, manager codes regularly, owns the technical direction as well as the people. It was always the strongest version of the role; AI simply makes it easier to sustain because the manager doesn’t fall behind on the codebase as fast. Companies like Google have run this model for years, and it’s becoming more common everywhere else.

The second is the platform or developer-experience leader. Someone who owns the systems engineers’ work inside: CI/CD, observability, dev environments, internal tooling, increasingly the AI tooling itself. This work scales, the metrics are real, and the leadership skill is engineering-shaped rather than HR-shaped. These roles are growing while traditional EM roles shrink.

The third is senior delivery leadership at the director-and-up level, where the work is portfolio decisions, organisational design, funding negotiations, and producing reliability across many teams. This kind survives because the alternative is for the CTO to do it personally, and that doesn’t scale past a certain size (even though most CTOs tend to keep the steering wheel as long as possible and much, much longer than needed). But the level above which this work is real has been drifting upward. Roles that used to be “senior manager” are now “director” with twice the scope. Roles that were “director” are now “VP.”

What’s getting hollowed out is the bit between team lead and director, the manager-of-one-team role that wasn’t deeply technical and wasn’t yet running portfolios. That’s where the spreadsheet damage is concentrated.

What this means for people in or near these roles

If you’re a senior engineer thinking about whether to take the management path, the only reliable answer in 2026 is “it depends on which version of the path.” The TLM version is still good. The pure people-manager version is a worse bet than it was three years ago. If your company is offering you the second one, ask hard questions about what the role will look like in two years and who has done it well there recently.

If you’re already an engineering manager, the most useful thing is probably to be clear-eyed about whether your current role is one of the durable kinds. Are you close to the work, or have you drifted away from it? Do your numbers reflect actual delivery or activity? Could you, today, sit down with an agent and ship something useful in your team’s codebase? If the honest answer is “no, and I haven’t tried,” that’s worth knowing about yourself before someone else has to tell you.

If you’re a senior leader making these calls, the temptation is to use AI as cover for cuts that were already coming. Some of those cuts are genuinely overdue. But the people you’re letting go often built the implicit knowledge of how things actually work in your org, and the AI can’t reproduce that yet. Be careful what you’re trading for what.

What I think is true

Most of the writing on this topic in 2026 is one of two things: breathless optimism from people selling yet another AI tooling, or grief disguised as analysis from people whose roles are at risk. Both are understandable, and neither is of much use.

What I think is true is more boring. Engineering management as a job category got overbuilt in the 2015-2022 era, as Agile coaching did before it. AI is not the cause of the correction, but it’s the trigger and the cover. The roles that survive will be either more technical or more strategic than the average EM role of the last decade. The middle is disappearing, and the people in the middle are mostly being asked to figure it out on their own time.

That’s not a tragedy, and it’s not a triumph. It’s just the shape of the thing now. The Agile piece I wrote ended on the line that the discipline was graduating into adulthood. I’d say something different about engineering management: it’s being asked, not gently, to remember what it was for in the first place.

The good news, if you want to call it that, is that the version of the role that’s left is closer to actual engineering than the one that’s leaving. A lot of people who took this path because they wanted to stay close to building things, and ended up further from it than they’d hoped, are about to get pulled back toward the work. Whether that feels like a relief or a demotion mostly depends on what story you’ve been telling yourself about what you do.

Worth thinking about either way.