What Happens to the PM When the Team Ships Twice as Fast

When AI started writing real chunks of our code, my first honest thought was that I would finally get some room to breathe.

For years the constraint on most software projects has been the same: there is more to build than there are hours to build it in. Everything else in the job bends around that scarcity. So when the team's output roughly doubled, features that used to take a week landing in two or three days, the natural assumption was that the pressure would ease. More gets done, everyone is less stretched, the PM finally gets to look up from the backlog.

That is not what happened. The work got faster. The job got heavier. And it took me a while to understand why, because on paper it made no sense.

Here is the part nobody mentions about doubling a team's throughput: the pieces of delivery that do not run on typing do not speed up with it.

Scoping still takes as long, because it is thinking, not typing. Reviewing takes longer, actually, because there is twice as much to check and each piece earns a little less of your trust at a glance. Aligning three stakeholders still takes as many conversations, and conversations do not have a fast mode. Deciding what to do when two features collide still takes the same careful hour it always did.

So the bottleneck does not vanish. It moves, to the one place in the system that was never going to get faster: the person holding the whole thing in their head. When the team ships twice as fast, more decisions reach me each week, more threads need keeping in sync, and there is more room for two parts of the project to quietly drift out of agreement before anyone notices. The work sped up. The coordination it demands sped up with it. The person doing the coordinating did not.

And there is a subtler cost. When the team is fast, they need answers faster to stay fast. A question that used to wait for the afternoon now blocks someone in ten minutes. So not only are there more decisions, they are more urgent, and urgency is the enemy of the exact kind of careful judgment the decisions actually need. Speed on one side of the desk becomes pressure on the other.

The numbers stop helping, too, which was the part that caught me off guard.

Velocity used to be a rough proxy for progress. More shipped, more done, roughly in the right direction. It was never precise, but it was directionally honest. Now a team can ship a great deal and be moving in a slightly wrong direction faster than before. Output went up. The certainty that it was the right output did not, and the two used to travel together.

I watched this happen on a build where the pace felt fantastic. The burn-down looked like the best week we had had. Three days in, I realised two of the fast-moving pieces had each made a reasonable assumption about how they would connect, and the assumptions did not match. Neither developer was wrong. Both were productive. At the old pace, someone would have hit the seam by the end of the week and we would have talked. At the new pace, both sides were most of the way built before the mismatch showed, and the fix cost more than the speed had saved. The velocity chart was green the whole time.

That is the trap. Speed makes a wrong direction more expensive, not less, because you get further down it before anyone looks up.

What I've had to change is where my attention goes. Less of it on making the work happen, the work happens fine now, sometimes too easily, and more on the things that quietly became the real constraint.

Protecting review instead of treating it as a formality. Being far more deliberate about what gets started, because when the building is nearly free, the cost of starting the wrong thing shows up later and lands on me. Catching drift early, before double speed turns a small misunderstanding into a large rework. Spending real time on the seams between workstreams, because that is where fast, independent progress quietly goes wrong.

I also had to get comfortable saying not yet to work that was ready to move, which feels wrong when the team clearly has room for it. But capacity to start is not the same as wisdom in starting, and a fast team aimed at the wrong thing just builds more of it before the problem surfaces. Holding things at the start of the pipeline turned out to matter far more than any speed I could add later.

None of that is glamorous, and none of it shows up as a shipped feature. But it is where the job went.

So the honest answer to what happens to the PM when the team ships twice as fast is: you become the slow part. Not in a bad way, in the way the careful, human, can't-be-rushed parts of delivery are now the thing everyone else is waiting on. The pressure didn't lift. It moved onto the exact parts of the job that were always hardest to do well and easiest to skip.

If your team got dramatically faster this year, be honest: did it actually give you breathing room, or did it just move the bottleneck onto you?