What the EM does when shipping gets cheap
AI makes code cheap. The engineering manager's job is no longer to ship more of it, but to make sure the right thing gets built and the team grows up doing it.
AI changed the math. Code is cheap now, and the real bottleneck moved somewhere else.
For years, the engineering manager's job was largely about throughput: how many people do you need, how do you keep them unblocked, how do you ship the roadmap. That job still exists, but it is no longer the hard part. When a team can produce several times the output on the same headcount, the question shifts. It is no longer "can we build it." It is "should we build it, and is it any good."
So where does a manager actually spend their attention now? For me it lands in three places, plus a change to the role itself.
The first is the bar. When code is cheap, debt accumulates fast, because a team that gets a velocity boost without a discipline boost just ships more of everything, faster, with less time to think about what it is leaving behind. The job becomes guarding the high bar. Tests have to be real. Design review has to be honest. CI has to actually block bad code instead of waving it through. You are not managing lines of code anymore, you are managing intent and system integrity. That sounds abstract right up until the on-call rotation gets noisy at 2am and you are the one paying for the shortcuts.
The second is team shape. Bigger teams used to be a sign of impact. They are starting to look like a sign of waste. The companies I have seen handle this well are running small, purpose-built pods aimed at high-leverage outcomes. A pod knows what it owns, what it is trying to move, and when it is done. Less coordination cost, less ambiguity, and the value attribution gets a lot clearer. You ship to a number you can defend, instead of a backlog you can drown in.
The third is what you measure. AI velocity makes output metrics close to meaningless. PR count goes up, lines of code go up, tickets close faster, and none of it tells you whether the company actually got better. The manager has to keep the team anchored to the outcomes that matter, the usage, retention, revenue, latency, whatever the team is actually paid to move. Celebrating a high merge count is just the newest way to mistake motion for progress.
Then there is the role itself. The span of control widens when shipping gets cheap. The managers I respect are running larger groups now, sometimes flatter, sometimes with a clearer tech lead layer underneath them. The shape that works for me is closer to a mini-director than a traditional manager. You spend less time on weekly task tracking and more on connecting dots across the org. You coach your tech leads to own the day-to-day technical execution, and you clear the blockers that sit at a level the team cannot reach on their own.
The fear with a wider span is that career growth suffers. For me it has been the opposite. Real growth happens in execution, not on a 1:1 calendar. High-trust autonomy is the strongest coaching environment I know of. When you put a senior engineer in front of a real problem with no one to escalate around, they grow up fast. The manager's job is to make sure the runway is clear, the problem is real, and the engineer is set up to win. Most of the coaching happens before they ever start.
The role keeps changing, but the principles underneath it do not. Build the right thing, build it well, and grow the people doing it. The methods around all three look nothing like they did two years ago, and they will look different again two years from now. The work is learning to tell which is which.