I read Gregor Ojstersek’s piece the other day. “Would I Still Go The Engineering Manager Route in 2026?”. And it hit me in a strange way. Not because of the answer but because of the question. The fact that someone who’s been doing this for years is publicly asking whether he’d do it again says something.
I’ve been in this role for almost three years. And I’d be lying if I said I hadn’t asked myself the same thing.
But here’s the thing. I’ve done this loop before.
Before I was an EM, I was an IC. Before I was an IC, I ran my own web agency for eight years. I was the CEO. I did sales, code, hiring, client management, architecture, marketing. Full ownership, full autonomy. And then I deliberately walked away from that, went back to building as an individual contributor, and worked my way through Lead and Principal before choosing management again.
I chose this role knowing what I was giving up. I’d already tasted the other side. Twice, actually.
That context shapes how I see what’s happening to the EM role right now.
The job changed
When I moved into management, the 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.
Somewhere along the way, the expectations started stacking. I’ve seen it in my career, I’ve seen it in job postings, I’ve heard it from every EM I talk to. Be technical enough to review architecture. Be strategic enough to present to leadership. Be empathetic enough to handle burnout and conflict. Own delivery metrics. Own hiring pipelines. Own the roadmap conversation with product. And increasingly: pick up some coding too.
I don’t think anyone designed it this way. It just accumulated. 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.
I’ve seen this movie before
When I was running my agency, mobile was going to change everything. We had to rethink our entire business. Some agencies died. We adapted.
When I came back to IC, cloud and microservices were going to change how teams work. Some companies over-rotated, split everything into tiny services, and spent years untangling the mess. The ones who kept their heads did fine.
Now it’s AI.
I’ve watched three cycles where a technology was supposed to make a role obsolete or fundamentally different. And 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 you had 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 you’ve got a situation where the best engineers don’t need management to advance. 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. I don’t blame them.
The player-coach myth
I keep hearing “player-coach” as if it’s aspirational. Like we should all want to be the EM who also ships features.
I’ve been a player-coach. It means you do both jobs badly. You context-switch between a PR review and a difficult conversation about someone’s performance. You write code in the gaps between meetings, which means you write code in 25-minute windows, which means you write bad code. Or you stay up late to get the focused time, which means you burn out faster.
The industry uses “player-coach” like it’s 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.
I’m not saying it can’t work. In early-stage startups, in small teams, when the scope is tight, sure. But in a 40-person org with multiple squads? If your EM is regularly shipping features, something is wrong with your staffing, not right with your EM.
The hard problems don’t change
Here’s what I keep coming back to, across all the cycles I’ve lived through. 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 when I was running my company 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.
That’s why I’m not worried about the role dying. I’ve watched enough cycles to know it won’t. But 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.
It’s one title, but it’s not one job
I think a lot of the confusion comes from a naming problem. We all call ourselves “Engineering Manager” but we’re doing wildly different jobs depending on the company, the stage, and the org.
I’ve talked to EMs who spend 80% of their time on architecture and code review. I’ve talked to EMs who haven’t opened an IDE in two years and spend their days on coaching, hiring, and cross-team alignment. I’ve talked to EMs who 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 I hear from EMs isn’t really about the role. It’s about the mismatch. You took the job expecting to be a people leader and you ended up being a delivery lead. Or you wanted to stay close to the technical decisions and instead you’re spending your weeks in stakeholder meetings. The role didn’t let you down. The expectations were just never made explicit.
If you’re an EM and something feels off, before you question whether you want to be a manager at all, try a simpler question first: which version of this job is your company actually asking you to do? And is that the version you want?
Sometimes the answer is “I’m doing the 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.
If you’re 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
Something I’ve noticed talking to other EMs. A lot of us still 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. You write code, you see it work, you feel something. It’s immediate.
Management has its own rewards. Watching someone you coached nail a presentation. Seeing a team you built 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. You have to learn to find satisfaction in that pace, and some weeks it’s easier than others.
So would I do it again?
Yes. Without hesitation. I already did it twice.
I walked away from running my own company. I went back to being an IC. I had the full picture, the autonomy, the ownership, and I chose to come back to building first and then to management. Not because I had to. Because I’d seen enough of both sides to know which problems I actually wanted to spend my days on.
I love this job. The role is broader and harder than when I started. The industry hasn’t settled on what it wants EMs to be. But that ambiguity is part of what makes it interesting. You get to shape it.
If you’re an IC thinking about management: go in with your 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 if you’re already an EM: 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.