Gregor Ojstersek published a piece recently: “Would I Still Go The Engineering Manager Route in 2026?”. The fact that someone who’s been doing this for years is publicly asking whether he’d do it again says something about where the role is heading.
The deal changed
The original EM deal was roughly this: you stop writing code full-time, you spend your days on people, process, and delivery. You run 1:1s. You shield the team from organizational noise. You hire, you coach, you make sure things ship. In return, you get a seat at the table and the satisfaction of watching people grow.
That deal still technically exists. But the fine print keeps growing.
Browse any EM job listing from 2026 and count the responsibilities. Technical leadership, people management, delivery ownership, hiring, strategy, stakeholder alignment. Each one makes sense on its own. But the list keeps getting longer and nothing ever falls off.
Nobody designed it this way. It just accumulated. One reasonable expectation at a time.
This has happened before
Every few years, a technology is supposed to make a role obsolete or fundamentally different. Mobile was going to kill web agencies. Cloud was going to eliminate ops. Microservices were going to change how teams work.
Now it’s AI.
The pattern is always the same: the technology matters, it does change things, but it doesn’t change the things people think it will.
Mobile didn’t kill web agencies. It made them busier. Cloud didn’t eliminate ops. It renamed them. And AI won’t replace engineering managers. But it is changing the math around the role in ways that are worth paying attention to.
What AI actually changes
AI doesn’t build trust across a team over months. AI doesn’t read the room in a planning meeting and realize the real problem isn’t the estimate, it’s that people don’t believe in the project. AI doesn’t tell a PM that the deadline is unrealistic and hold the line.
But AI does make small teams more productive. And when small teams are more productive, companies start asking why they need so many managers. The ratio shifts. Where there used to be one EM for five or six engineers, now it’s eight. Ten. Twelve. The scope grew but the support didn’t.
That’s the actual pressure. Not “AI replaces managers.” Just “we need fewer of them, and the ones we keep do more.”
Combine that with the IC career track getting better, real Staff and Principal roles with real compensation, and the best engineers don’t need management to advance anymore. The people who want to be EMs used to be the best engineers who also cared about people. Now some of them are choosing Staff instead. Hard to blame them.
The player-coach myth
“Player-coach” gets thrown around as if it’s aspirational. Like every EM should want to also ship features.
In practice, player-coaching means doing both jobs badly. Context-switching between a PR review and a difficult conversation about someone’s performance. Writing code in 25-minute windows between meetings, which means writing bad code. Or staying up late to get the focused time, which means burning out faster.
The industry uses “player-coach” like a compliment. It’s usually a budget decision disguised as a philosophy. Someone needed to cut a headcount and decided the EM could absorb the work.
It can work in early-stage startups, in small teams, when the scope is tight. But in a 40-person org with multiple squads? If the EM is regularly shipping features, something is wrong with the staffing, not right with the EM.
The hard problems don’t change
The technology changes. The hard problems don’t.
Getting people aligned on what matters. Making decisions with incomplete information. Knowing when to push and when to protect the team. Helping someone grow when they don’t see their own potential yet. Having the conversation everyone’s avoiding.
Those problems looked the same in 2015. They look the same now. AI didn’t create them and AI won’t solve them. They’re human problems, and the EM role exists because someone needs to own them.
The role won’t die. It will mutate. It always does. And the EMs who get left behind won’t be the ones who ignored AI. They’ll be the ones who forgot that the human stuff is the actual job.
One title, different jobs
A lot of the confusion around the EM role comes from a naming problem. Everyone has the same title but is doing wildly different jobs depending on the company, the stage, and the org.
Some EMs spend 80% of their time on architecture and code review. Some haven’t opened an IDE in two years and spend their days on coaching, hiring, and cross-team alignment. Some are basically program managers with a different title, owning delivery timelines and stakeholder updates. All of them have the same title on LinkedIn.
This matters because most of the frustration EMs feel isn’t really about the role. It’s about the mismatch. Taking the job expecting to be a people leader and ending up as a delivery lead. Wanting to stay close to the technical decisions and instead spending weeks in stakeholder meetings. The role didn’t let anyone down. The expectations were just never made explicit.
If the job feels off, before questioning whether management is the right path at all, there’s a simpler question: which version of this job is the company actually asking for? And is that the version you want?
Sometimes the answer is “wrong version of EM at the wrong company.” That’s a very different problem than “I don’t want to be an EM anymore,” and it has a very different solution.
For anyone hiring an EM or about to become one: have that conversation early. Don’t just talk about the team size and the tech stack. Talk about what the job actually looks like on a Tuesday. Where does this EM spend most of their time? What does success look like in six months? The clearer that picture is, the fewer EMs will burn out wondering why the job doesn’t feel like what they signed up for.
The feedback loop problem
A lot of EMs build things on the side. Side projects, open source, weekend hacks. And when you ask why, the answer is almost never “to stay technical.” It’s because the feedback loop is different. Writing code, seeing it work, feeling something. It’s immediate.
Management has its own rewards. Watching someone you coached nail a presentation. Seeing a team ship something complex without drama. Those moments are real. But they’re slow. They happen over months. The feedback loop in management is measured in quarters, not commits. Learning to find satisfaction in that pace is part of the job, and some weeks it’s easier than others.
Is it still worth it?
Yes. The role is broader and harder than it used to be. The industry hasn’t settled on what it wants EMs to be. But that ambiguity is part of what makes it interesting. There’s room to shape it.
For ICs thinking about management: go in with eyes open. The role is worth doing. It’s also messier and more ambiguous than it looks from the outside. Talk to EMs. Ask them what their actual week looks like, not their LinkedIn version of it.
And for EMs already in it: the role is changing fast. It always has been. The technology driving the change is new but the pattern isn’t. The EMs who’ll thrive are the ones who can sit with the ambiguity and shape the role instead of waiting for someone to define it for them. That’s always been the interesting part of this job anyway.