The Weak EM Will Become An NPC

The Weak EM Will Become An NPC

June 09, 2026

Guy Coleman

Read Time: ~14 minutes

AI is quietly turning some engineering managers into NPCs: useful, always available, and out of the plot the moment a real decision is needed. AI doesn't make EMs less necessary, it makes weak technical judgment more expensive. The surviving EM is an engineer who manages the socio-technical system, contributes for leverage, and owns the technical strategy no IC or agent can.

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)

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:

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

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

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:

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:

Bad EM technical contributions include:

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:

The Uncomfortable Test

Ask yourself these questions:

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.