The Weak EM Will Become An NPC

AI will not kill engineering managers. It will turn the weak ones into NPCs, the non-player characters in a video game who stand at their marker, repeat a scripted line, and never change the plot.

Plenty of EMs are already halfway there.

An NPC is useful. It greets you at standup, hands out the same quest every Monday, delivers its scripted line at planning, and is always exactly where you left it. It also decides nothing, the story happens around it. Swap “player” for “engineer” and that is a weak EM in the AI era: people-shaped, always available, permanently out of the plot.

A low-technical-context EM can look useful in a slow organisation because the job fills with coordination residue: dashboards, status rituals, ticket archaeology, calendar Tetris, summaries, follow-ups, and asking for ETAs in three different Slack channels. Some of that work matters.

But AI is coming for the residue.

It can summarise meetings. It can track actions. It can draft status updates. It can produce project plans. It can answer basic process questions. It can nag people. It can create dashboards. It can generate the weekly update that says we are tracking green.

In other words: an agent now runs your dialogue tree better than you do. More uptime, fewer 1:1s, no PTO.

None of that is here to help you scale. It is here to expose that you drifted too far from the work. That is why the NPC line stings: the NPC is useful right up until someone needs a decision, and it has no say in where the story goes. Plenty of managers have accidentally trained their organisations to treat them exactly that way: a fixture you walk up to for a status update, not someone who changes the plot.

Here is the uncomfortable bit: AI makes code cheaper, which makes weak technical judgment more expensive. The EM who survives is the one who can do what an NPC cannot: apply grounded technical judgment inside a messy human system, and use that judgment to place long-term bets the rest of the system is not equipped to place.

So here is the question every engineering manager should be asking themselves:

When the code starts writing itself faster, do you still understand the engineering?

The AI era will be very kind to technical EMs. It will be much less kind to status jockeys.

Here’s the takeaway (if you read nothing else here)

• EMs are engineers first.
• EMs should stay deeply technical.
• EMs should contribute technically.
• EMs should NOT own large initiatives through technical delivery.
• The contribution is leverage, not ticket throughput: work that multiplies what the team can do, not work you personally ship.
• EMs set technical strategy: the long-term bets that compound into competitive advantage.
• AI raises the premium on judgment, architecture, review, context, and system design.
• The EM survival path is simple but uncomfortable: get closer to the code without becoming the team’s bottleneck.

Engineer first. Manager always. Critical-path IC almost never.

What The Market Is Starting To Say

The global sentiment is getting louder, and it is not subtle.

Airbnb says AI wrote 60% of its new code in Q1 2026. Meta is flattening management layers and experimenting with smaller AI-enabled teams. Tech CEOs are talking openly about “pure managers” struggling to survive. Consultants are writing about managers being reinvented, not deleted. Engineering leadership forums are full of the same argument wearing different hats: what is an EM for when AI can produce more output? There are three camps forming.

Camp one: delete the manager layer.

This is the spicy executive version. AI makes teams faster, communication flatter, and coordination cheaper. Therefore, fewer managers. More builders. More player-coaches. More one-person teams. Less ceremony.

Camp two: managers matter more than ever.

McKinsey and Deloitte both make versions of this argument. AI can remove some administrative work, but managers remain critical for coaching, adoption, judgment, risk, strategy translation, and redesigning work.

But if we leave the argument there, it becomes too soft. “Managers matter” is comforting. Comfort is not a strategy.

Camp three: the EM gets more technical, not less.

This is where I land.

AI removes the padding around weak management. It makes vague coordination roles easier to question. It makes output easier to generate and harder to trust. It makes technical judgment more valuable because the review surface area explodes.

The surviving EM is not a mini-PM, a scrum therapist, or a ticket concierge.

The surviving EM is an engineer who manages the socio-technical system.

The Counterargument Is Real

There is a strong competing view that EMs should not be expected to code. It is not a bad argument. In fact, it is mostly right.

The player-coach model can be a trap. Management work needs attention. Engineering work needs focus. If a manager owns implementation on the critical path, one of two things usually happens: the management work suffers, or the team waits on the manager. Neither is great.

There is also a power dynamic to consider. When a manager is too embedded in implementation, their technical opinion can start to carry disproportionate weight. After all, who wants to tell the person who may influence their career progression that they’re wrong?

Engineers may defer. Ownership can drift upward. Over time, the team can become less capable of making hard technical decisions unless the manager is in the room.

I’m not saying your team operates this way. Your team is full of high-agency, high-accountability engineers who hold the line and speak up when something is clearly wrong. My team is the same, and I wouldn’t want it any other way.

But as a general pattern, the point still holds: teams often defer up the perceived power chain.

So yes, EMs should not be expected to own large technical initiatives through delivery. They should not be the person everyone is waiting on to merge the feature. They should not take the most interesting work from the team to prove they still have it. They should not be the heroic coder-manager who saves the sprint while quietly starving the team of coaching, context, and ownership.

But that is not the same thing as becoming non-technical.

This is where the discourse gets sloppy. People hear “EMs should not own production delivery” and translate it into “EMs do not need to stay close to code.”

Wrong.

The Nugget

Here is the actual shape of the role:

EMs are engineers first, managers second, and critical-path ICs almost never.

That sounds contradictory until you separate contribution from delivery ownership.

A technical EM should contribute. They just should not contribute in the same way as a senior engineer on the team.

Here is the difference. An engineer’s value scales with what they personally ship. An EM’s value scales with what they make the whole team able to ship. That is leverage: work where one hour of your time changes ten hours of everyone else’s. A design review that kills a bad plan before it gets built. An architectural call that saves months of rework. Unblocking an engineer who has been stuck for two days. Setting a clear enough quality bar that the team stops guessing what “done” means. None of it shows up as a ticket with your name on it, and all of it moves the team more than another ticket would.

The EM contribution should be leverage work:

• Reviewing designs before they harden into bad plans.
• Reading enough code to understand reality.
• Spotting architectural drift.
• Pairing on production incidents.
• Building internal tools that remove team friction.
• Improving docs, templates, guardrails, and paved paths.
• Testing AI tools on real workflows, not toy demos.
• Helping define what safe agent delegation looks like.
• Coaching engineers through tradeoffs without stealing the decision.
• Making the business case for technical work in language outside engineering.
• Setting technical strategy: marrying the code, the business, and the team into technology bets that create sustained competitive advantage.

That is technical contribution.

It is not ticket cosplay. It is not “give the manager three story points so they feel alive.” It is not using coding as a comfort blanket because people leadership got hard.

A good EM stays close enough to the code to keep their judgment sharp and far enough from the critical path to let the team own delivery.

That is the balance. That is also the part AI makes harder to fake.

Strategy Is The Highest-Leverage Work

That last bullet is the one ICs cannot do for you, and it is the easiest to skip. Most contribution is visible. Strategy is invisible until it pays off, or fails to.

Setting technical strategy: marrying the code, the business, and the team into technology bets that create sustained competitive advantage.

An EM sits at the intersection of three systems: the technical system (how the code actually works), the business system (where the company is going), and the organisational system (who is doing what, and what they are capable of). Senior engineers see one and a half of these. Senior PMs see a different one and a half. The EM is the only person in the room expected to see all three at the same time.

That vantage is the whole reason the role exists. It is what makes an EM more than a senior engineer with direct reports. Marrying those three views into technology bets that pay off over years, not sprints, is the work that creates durable competitive advantage. No IC is positioned to do it, and no agent is either.

Technical strategy is what comes out of that vantage:

• Where to invest in platform versus product velocity over the next two years.
• Which refactors to do before a business pivot makes them ten times more expensive.
• Which AI workflows to bet the team on this year, and which to wait out.
• Which architectural decisions are buying you optionality, and which are quietly closing doors.
• How to translate a technical liability into a business risk the rest of the company can act on.

That last one is where many EMs lose the room.

“The code is hard to work with” is a complaint. “This design means every new product capability needs bespoke engineering analysis before the business can make a decision” is a constraint.

The first gets nodded at. The second gets funded.

You cannot do this work without deep technical context. You also cannot do it without a working model of the business. AI is making the first cheaper to fake and the second more important to actually have.

The Data Points At The Same Thing

Google’s 2025 DORA research found AI adoption among software development professionals at 90%, with more than 80% reporting productivity gains. That is the good news.

The more useful finding is the trust paradox. Only a minority reported high trust in AI, while a meaningful share reported little or no trust. DORA also found AI works like a mirror and multiplier: cohesive organisations get stronger; fragmented ones expose their cracks faster.

Stack Overflow’s 2025 Developer Survey tells a similar story. AI usage keeps rising, but trust is at an all-time low. A majority of developers use or plan to use AI tools, while many do not trust the accuracy of AI output.

That is the environment EMs are walking into.

More code. More speed. More review burden. More hidden risk. More need for judgment.

If your engineering management muscle is mostly status reporting, this is bad news.

If your engineering management muscle is technical judgment, this is your moment.

AI Does Not Make Technical Leadership Optional

A lot of AI optimism treats code generation like the whole game. It is not. Software engineering was never just typing code into a box. It was understanding a problem, shaping a solution, navigating constraints, integrating with existing systems, managing risk, operating the result, learning from production, and helping humans make better decisions under uncertainty.

AI is very good at making plausible artefacts. It is much worse at owning consequences. That gap is where engineering leadership lives.

A non-technical EM in a high-AI environment is forced to manage the ceremony around the work:

• Are the tickets moving?
• Are we using the tools?
• Did velocity go up?
• How many PRs shipped?
• Can we show AI adoption on a dashboard?

Those questions may be useful at the edges. The leadership questions are harder:

• Are we generating more value or just more code?
• Is AI reducing toil or creating hidden review debt?
• Are junior engineers learning judgment or just prompt choreography?
• Are our tests strong enough for faster change?
• Are agents following patterns the team can maintain?
• Is the system getting easier or harder to reason about?
• Are we moving faster toward a better architecture or faster into the ditch?

You cannot answer those questions from a dashboard alone. You have to understand the work.

The Practical Survival Path

This should make EMs uncomfortable, but not helpless. There is a path.

1. Read Code Again

Not every line. Not every PR. Not as a gatekeeper. Pick meaningful code paths and read them deeply.

Start with:

• The deploy path.
• The rollback path.
• The highest-risk customer journey.
• The most fragile service boundary.
• The code changed by AI-generated PRs.
• The area engineers complain about in private.

Your goal is not to become the owner. Your goal is to reconnect your judgment to reality.

2. Contribute Off The Critical Path

Do technical work that increases leverage without making the team wait on you.

Good EM technical contributions include:

• Fixing small paper-cuts.
• Improving internal tooling.
• Writing or improving runbooks.
• Creating AI usage guidelines.
• Building a prototype to clarify ambiguity.
• Adding observability around a painful workflow.
• Cleaning up docs that every new engineer trips over.
• Pairing with an engineer during an incident.

Bad EM technical contributions include:

• Owning the biggest feature.
• Becoming the release bottleneck.
• Grabbing the interesting architecture work.
• Rewriting code to your taste without creating team ownership.
• Using implementation work to avoid difficult people conversations.

Do the first list. Avoid the second.

3. Learn The AI Workflow Yourself

Do not manage AI adoption from the sidelines.

Use the tools. Use them on real work. Learn where they help, where they lie, where they create review load, and where they make junior engineers faster but shallower.

A serious AI-era EM should know:

• How engineers prompt agents.
• How generated code is reviewed.
• What context agents need.
• Which parts of the codebase are unsafe for agent autonomy.
• Where tests catch AI mistakes and where they perform security theatre.
• Whether AI is improving flow or just inflating output.

If your opinions about AI coding tools come entirely from LinkedIn or some influencer selling his tmux wrapper, start over.

The Uncomfortable Test

Ask yourself these questions:

• Could I explain a high risk code path without asking a senior engineer to do it for me?
• Could I review an AI-generated PR and spot architectural trouble, not just syntax trouble?
• Could I pair during an incident and add useful technical context?
• Could I challenge a design doc without making the team feel overruled?
• Could I contribute something technical this month without becoming a delivery bottleneck?

If the answer is mostly no, you do not need shame, you need a plan. But also, maybe a little urgency.

Cheer up!

AI will kill the illusion that engineering managers can drift away from engineering and still be trusted to lead it. The best EMs in the AI era will be engineers first, but not solo heroes. They will be technical enough to understand the system, disciplined enough not to steal ownership, and close enough to the work to know when AI is creating leverage versus mess.

So stay technical. Use the tools. Read the code. Know the system. Coach the humans. Manage the agents. Contribute where it compounds. Stay off the critical path unless the building is on fire.

And for the love of all that is holy, do not become the person whose only contribution to the AI era is a dashboard showing that the team is generating more pull requests and using all the tokens. That is counting sparks and calling it fire.

If you are an EM, pick one thing this week that reconnects your judgment to the work. Read a real code path. Review an AI-generated PR. Pair on an incident. Improve a runbook. Build an internal tool. Then ask yourself: did I make the engineering system better, or did I just manage the ceremony around it?

---

About Guy Coleman

Senior Engineering Manager at Tilt, leading Platform & Infrastructure across reliability, security, developer experience, and cost efficiency. I build teams that ship boringly stable systems, reduce on-call pain, and scale regulated fintech platforms on Azure.