You can’t lead From hehind anymore. For twenty years the path to Engineering leadership had a well-worn groove: write code for a few years, get “promoted out of” writing code, spend the rest of your career managing budgets, headcount, and status reports. The further up you went the less technical you were expected to be, and nobody blinked. That era is over. Not ending. Over.
I already wrote about the glorified babysitter problem — the managers whose whole job was routing Jira tickets and running standups, and why AI eats that job first. This post is the bigger, scarier version of that argument: it’s not just the ticket-routers. The entire org chart is compressing, and the compression is landing hardest on the layer that was often where technical skills had atrophies the most.
The Data Says the Org Chart Is Actually Flattening
I went looking for whether this was just vibes or something real. It’s real.
Gartner predicts that by the end of 2026, 20% of organizations will use AI to flatten their structures and eliminate more than half of current middle management positions (Forbes). At the big tech companies, engineering managers now supervise ~12 engineers on average, a 14% jump since 2019. Early-stage startups have flattened even faster — ~15 engineers per manager, up 34% (youmake.dev).
And here’s the part that surprised me: it’s not stopping at middle management. RDEL’s research found that upper management was significantly impacted in 23% of reorganizations in 2026, up from 18% in 2025 and 13% in 2024. The flattening is moving up the chart, not just chewing through the middle.
A Harvard Business School study on Copilot adoption found coding activity rose 12% while project management activity fell 25% (LeadDev). Read that again. The coordination work — the thing a huge chunk of engineering management was — is evaporating because the coordination is happening inside the tools now.
The rungs holding up are the ones closest to the top and the bottom. The ones in between are the ones snapping.
Middle Management Was Already a Trap, AI Just Made It Obvious
Will Larson wrote a piece a while back called “Middle management roles were also a trap” that I think about a lot. His argument, boiled down: middle management actively trains you out of the skills that make a great executive. Go too deep on domain expertise as a line manager and you get called a micromanager. Focus on execution instead of “stakeholder alignment” and you get passed over. The system selects against the people who’d make the best senior leaders, because it rewards the wrong behaviors on the way up.
Larson’s closer, almost in passing: AI-driven flattening might paradoxically fix this, by eliminating the roles that were stalling good future leaders anyway.
I think he’s right, and I think he’s underselling how big a deal that is. We spent two decades building a career ladder that punished technical depth in favor of budget ownership and headcount growth. That ladder is being taken apart in real time, and the replacement ladder rewards exactly what the old one discouraged: judgment, architecture, taste, the ability to actually read the diff.
The Role Is Splitting, Not Just Shrinking
LeadDev’s piece on the EM role splitting in two lays out where this actually goes, and it maps to what I’m seeing. Two paths are emerging:
- Tech Lead Manager — small team (3-4 engineers), stays hands-on, reviews architecture and AI-generated code with real technical judgment. Lower ceiling on org size, but the job is real and durable.
- Multi-team EM — scope balloons to 50-to-1 ratios, purely people management, performance reviews, cross-team traffic control. Almost entirely non-technical.
Here’s my prediction, and it’s the thesis of this whole post: path two is a dead end. Not immediately — there will always be some need for pure people leadership at scale — but every year there’s less room at the top of it, and the people doing it will have less and less standing in the room when technical decisions get made. You cannot evaluate whether your team should build vs. buy, whether the AI-generated PR is actually sound, whether the architecture will hold up at 10x load, if you haven’t been in the system. You’ll be the last to know when something’s wrong, and the last one anyone trusts to say so.
I’ve said before that senior engineers and leaders coding again is a feature, not a regression to some player-coach trap. This is why it matters more than a nice personal hobby: the leaders who kept their hands in the system are the only ones who’ll be able to do path one. Everyone else is stuck defending a shrinking territory with a skill set that’s actively losing relevance.
Budget and Headcount Were Never the Job — They Were the Excuse
Go back and read my old “Engineering Leadership 321” post from 2018. Not one word in there about budgets, headcount planning, or org charts. It’s entirely about trust, learning environments, and giving Engineers a reason to believe in their leader. That’s what good leadership was made of even back then — the budget stuff was administrative overhead that got glued onto the job because someone had to own it, and “the manager” was the default answer.
AI doesn’t automate leadership. It automates the administrative overhead that got mistaken for leadership. If your value as an Engineering leader was “I control the roadmap doc and the headcount req,” you were always standing on a foundation that could be automated out from under you. It just took this long for the tooling to catch up.
So Where Does This Leave the CTO?
If this is happening at the EM layer, it has to be happening at the top of the house too. So I went and read what’s being written about the CTO role specifically, and I found the industry talking out of both sides of its mouth at once.
One camp says the CTO is becoming less technical — a “business enabler,” an “enterprise strategist” who translates AI capability into business outcomes, someone whose job is explaining what AI can and can’t do to the rest of the C-suite rather than personally evaluating the outputs (Computing.co.uk, CTO Academy). Under this framing, technical credibility is table stakes but no longer the differentiator — the real value is in “converting AI results into clear stories that drive understanding and alignment” between engineering and the business (CTO Magazine).
The other camp says almost the opposite: that a CTO who isn’t hands-on enough to actually evaluate what the AI agents are producing is flying blind. Anthropic’s own 2026 Agentic Coding Trends Report found that developers now delegate roughly 60% of their work to AI, but can only fully hand off — no human review needed — somewhere between 0% and 20% of tasks. Someone at the top has to understand the other 40-100% well enough to know when the agent got it wrong (ai-infra-link). Agentic AI is described as an amplifier of existing engineering discipline, not a replacement for it — which means the CTO’s job includes setting the guardrails for when AI can be trusted and where it can’t, and you cannot set a guardrail you don’t understand technically.
Both are true, and I don’t think that’s a contradiction — it’s the same split I described above for engineering managers, just one level higher. The CTO absolutely has to translate technology into business strategy; that part of the job was always real and isn’t going anywhere. But “strategist” was never supposed to mean “no longer technical.” It meant “technical enough to be trusted with the strategy.” A CTO who can’t personally judge whether an AI-generated architecture decision is sound is in exactly the same spot as the multi-team EM with a 50-to-1 ratio: dependent on someone else’s judgment for the thing they’re nominally accountable for. The org chart being flatter just means there are fewer layers left to hide that gap behind.
The CTOs who’ll do well here are the ones who read this whole post and thought “yeah, obviously” — the ones who never really stopped being Engineers even after the title changed - the ones for whom “CTO” was always shorthand for “the most technical person willing to also own the business outcome,” not “the person who used to be technical before the job ate that part of them.”
The middle isn't just thinning. It's being squeezed out.
Dream Teams Don’t Need Traffic Cops
I wrote about Netflix’s “Dream Team” culture a couple years back — the idea that great teams are made of colleagues who are extraordinary individually and even better together. Go back and read the Netflix Culture doc again with fresh eyes: it explicitly says process and hierarchy exist to serve talent, not the other way around. A team of genuinely excellent Engineers, armed with agentic tooling that removes most of the coordination tax, doesn’t need someone standing between them and the work translating requirements into tickets. They need someone who can see three moves ahead technically, make a hard call under uncertainty, and take the risk off their plate when it matters.
That’s judgment. You can’t fake judgment by scheduling a really good standup. Or having a really good budget planned.
What This Doesn’t Mean
I want to be careful here, because it’s easy to read this as “management is dead” and that’s not what I’m saying. People leadership — real mentorship, career development, conflict resolution, the stuff that makes someone want to stay on your team for the next decade — that’s not going anywhere. I still believe trust is the single most important thing an Engineering leader builds. AI doesn’t do 1:1s. It doesn’t tell someone their work isn’t good enough with enough care that they hear it instead of shutting down emotionally. It can’t explain to someone why the demo they gave to the CEO was too technical and you lost the audience. Or resolve an architecture dispute between two Engineers. It can’t deliver that spot bonus for the amazing work you did last month fixing a critical problem. AI can’t build a Dream Team culture.
What’s ending is the version of the job where you could do all of that without being technical. In larger companies, saying “I’m not really a coder anymore, I’m a people person” was a viable career sentence. It isn’t anymore. The people-leadership skills are necessary but they were never sufficient, and now the tooling has stripped away the administrative padding that used to hide the gap. Those roles are simply going to vanish - and the people who held them are going to need to reskill.
Conclusion
The org chart is flattening from the middle out — middle management first, now creeping into upper management too. The managers who survive this are the ones who never stopped being Engineers: people who can read the diff, question the architecture, and tell good engineering from bad engineering because they’ve actually built things recently, not because someone briefed them on it in a slide deck.
You cannot lead from behind anymore. Not when the people you’re leading have tools that let them move at a speed no status meeting can keep up with. If you’re a leader who hasn’t opened an editor — or a terminal, since that’s where I spend at least 50% of my “coding” time now — in years, now’s the time to get uncomfortable again. Go build something. Get the rust off. It’s the only ladder that’s actually still standing.
What’s your read on this? Are you seeing the flattening where you work, or is your org bucking the trend? Drop me a note on LinkedIn. I want to hear how this looks from where you’re sitting.