How does AI change the PM-to-engineer ratio?

THE SHORT ANSWER

The PM-to-engineer ratio was never about engineers, it was about how much build output one PM could feed with decisions and direction. The old anchor was about one PM per seven engineers. When AI raises each engineer's output two to three times, the same team generates far more work per PM, so either each PM covers more surface area or the team needs fewer engineers for the same roadmap. Both reduce PMs per unit of output. The 2025 and 2026 PM layoffs are mostly this ratio correction, not a skills purge.

For a decade, the planning anchor was simple. One PM for every seven engineers, give or take. Platform teams ran leaner, zero-to-one teams ran richer, but 1-to-7 was the number that built org charts. Almost nobody asked what the number was actually measuring. We talked about it as if it described engineers. It did not. It described how much build output a single human could feed with decisions, direction, and discovery. The engineers were just the proxy for the output. Then AI changed the output without changing the proxy, and the whole formula quietly broke.

The ratio was always about output

A PM is not staffed to manage seven people. A PM is staffed to supply enough decided, discovered, prioritized direction to keep a certain amount of building productive. When each engineer ships two or three times as much, the build capacity behind that PM jumps without a single new hire. Same seven engineers, far more output, far more decisions required to aim it. Something has to give, and there are only two directions. Either each PM covers more surface area, pushing the ratio toward 1-to-15 or 1-to-20. Or the team needs fewer engineers to ship the same roadmap, which shrinks the team and the PM count with it. Both are happening now, and both reduce PMs per unit of output.

Why this looks like a skills purge and is not

If you believe the layoffs are a skills story, you go collect AI certifications. If you understand it is a ratio correction, you conclude something more useful: the question is not whether you have new skills, it is whether your particular job sat on the part of the ratio that compresses. When one PM suddenly covers the span that used to take three, the only way it works is to automate away the coordination, documentation, status relay, and meeting overhead. What is left, the part that does not compress, is deciding what is worth building and why. Same talented people in many cases. Wrong side of the math.

The leadership trap I am watching in real time

If you run a product org, the correction creates a trap most leaders walk into: keeping roadmap ambition flat while pocketing the engineering productivity gain as a headcount cut. It looks responsible. It is quietly a strategy failure, because you just used a once-a-decade capacity increase to do the same amount of work with less. The better move is to expand ambition to consume the new output. If you cut to match a flat roadmap, the competitor who expanded theirs is about to out-build you with the headcount you just trimmed.

Stop planning in bodies. Plan in output and decisions. Ask the real question this week: how much build capacity can one PM actually direct now that the relay and documentation work is automatable? It is a lot more than seven engineers' worth. Staff to that honestly, then decide explicitly whether you are banking the gain as a cut or reinvesting it as ambition. Not deciding is deciding to bank it.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read