What Changes for Engineering Managers

Engineering management practices assume things that stop being true when a meaningful share of implementation is delegated: that output correlates with effort, that capacity is roughly headcount times velocity, that people learn by doing the work, and that reviewing is a small tax on producing.

Each of those breaks differently.

Estimation stops working the way it did

Implementation time compresses unevenly — dramatically for familiar patterns, barely for novel work in unusual systems. Which means the variance in estimates goes up even as the mean comes down, and the historical velocity data doesn't transfer.

What to do: estimate elapsed time to production rather than implementation effort, and track where time actually sits. The implementation row is now small and the specification and review rows are large; planning against the old ratios produces schedules that miss for reasons nobody can name.

Capacity is bounded by review, not by headcount

Generation is parallel; review is serial and human. Adding capacity to produce without adding capacity to review adds queue, not throughput.

What to do: measure review capacity explicitly and cap work-in-flight to it. ⚠️ Watch time-to-approve — if it's falling while diff size holds, you don't have more review capacity, you have less scrutiny, and that shows up later as post-merge defects.

The learning path breaks

People developed judgment by implementing, debugging, and living with consequences. That's the delegated activity, so the mechanism that produced your future seniors is thinner.

What to do: make some hands-on work deliberate rather than incidental. Assign it for the capability, not the output, and say that's why — otherwise it reads as busywork. Pair on comprehension, not just delivery. Treat "can debug without the tools" as a capability worth maintaining, because it's what review quality rests on.

Performance evaluation needs different evidence

Output volume was always a rough proxy and it's now actively misleading. Someone producing three times the PRs may be producing three times the review burden.

What to do: evaluate on decisions and outcomes. What did they choose, why, how did it turn out. What problems didn't happen. What they caught in review that others would have missed. ✅ This requires people to have a record of their decisions, which is worth asking for explicitly rather than expecting.

The work distribution shifts and the job satisfaction shifts with it

More time specifying and reviewing, less building. For some people that's a promotion; for others it's the removal of the part they liked.

What to do: notice it and talk about it. Some engineers will be less happy in the new distribution and that's not a performance problem. Some will thrive. Assuming everyone is fine because throughput looks good misses a retention risk that shows up two quarters later.

💡 The new thing to manage

Whether anyone still understands the systems. Code volume grows faster than comprehension when generation is cheap. A codebase nobody has read is a codebase nobody can debug, and the cost arrives during an incident.

Practical version: for anything load-bearing, make sure at least one person has genuinely read it and can explain it. That's a resourcing decision, and it competes with delivery, and it's worth defending.

✅ The metrics that hold up

• Elapsed time from decision to production, with the phase breakdown.
• Review latency and time-to-approve, watched together.
• Post-merge defect rate, as the check on review quality.
• Work-in-flight versus review capacity.
• How many people can explain each critical system.

The takeaway

Estimation variance rises, capacity is bounded by review rather than headcount, the learning path that produced seniors thins, and output volume stops being evidence of contribution. Cap work-in-flight to review capacity, assign hands-on work deliberately for capability, evaluate on decisions and outcomes rather than throughput, and track whether anyone still understands the systems — because that last one is invisible until the night it matters.