Acceleration multiplies coordination, then hides it

A team drops its coordinator role so the AI-accelerated squads can run without anyone in the way. For about two months, it works. Then the product starts contradicting itself. Two features solve the same problem in different ways. The thing engineering shipped isn’t quite the thing the spec described. Nothing failed loudly. The pieces just stopped agreeing with each other.

If you build product, you’ve probably watched some version of this and filed it under growing pains. The sharper account comes from Amy Mitchell, a product writer whose analysis of the AI-era PM job has stayed unusually concrete. Her claim is about the work of connecting a decision made in design to the ones waiting in engineering, go-to-market, and customer research. That work doesn’t shrink as AI speeds delivery up. It grows. And it grows fastest right where teams believe they’ve automated it away.

The mechanism is simple. AI lets each function produce more, and faster. Mitchell’s example: a design team can now generate five times the specs in a fifth of the time. Every one of those specs still has to line up with what engineering can build, what marketing is about to promise, and what research says users need. More decisions leave each function per unit of time, so more decisions need connecting to the others, not fewer. And no AI tool does the connecting. There’s no layer that reads a design spec and reconciles it with the go-to-market plan. That work is still human, and there’s now more of it.

That sets up the trap the acceleration story walks teams into. You can speed up every single decision and still lose the product, because faster decisions don’t connect themselves, and the work that would connect them just went invisible enough to cut.

That invisibility is the dangerous part. Connecting work used to be something you could see. It looked like a standing sync, an alignment doc, a person whose calendar was full of other people’s meetings. Visible work is work you can staff, defend, and measure. Under acceleration it migrates into forms you can’t see: a quick message to unblock one decision, a cleanup someone does after the fact when two teams’ work collides. The work didn’t leave. It stopped showing up anywhere you’d think to look for it.

And invisible work is the easiest kind to cut. When a team decides to drop its coordinator so the fast squads can run unobstructed, it’s removing something it can no longer see doing anything. Mitchell reports that teams which eliminate this ownership to move faster see customer-visible fragmentation within two to three months: conflicting features, inconsistent behavior across the product, specs that drift from what actually shipped. The organizations reporting the worst fragmentation and burnout are the ones that removed the ownership.

The reframe underneath all this: speeding a decision up and connecting it to the others are two different jobs, and the first can go perfectly while the second collapses. A team can get very good at closing decisions: declaring the question, cutting a tight scope so it doesn’t reopen later. Every decision lands crisp and on time. And the product still fragments, because closing one decision cleanly says nothing about whether it agrees with the fifty others closing in parallel. You optimized the throughput of each decision and never staffed the thing that makes them agree. Clean decisions, incoherent product.

The opposing case is strong, and worth stating at full strength. A lot of coordination genuinely was overhead. The endless syncs. The alignment decks nobody read. Cutting those does make teams faster, and AI does remove a real slice of that busywork. For a while, a team that drops its coordinator really does move quicker, which is exactly why the move tempts people and why the bill is easy to miss. What the team cut wasn’t the need for coordination. It cut the visibility of it, while the load underneath went up. The two months of speed are real. So is what shows up in month three.

None of this settles the one question sitting underneath it, and how that question resolves decides how much any of this matters. Does the connecting work scale in a straight line with speed? If it does, this is a staffing problem. Go faster, hire proportionally more people to keep the pieces aligned, budget for it, move on. Or is there a point where the volume of decisions needing connection outruns what any group of people can hold at once, so that past a certain velocity the product fragments no matter how many coordinators you add? If that’s the case, the invisible layer teams keep cutting isn’t merely undervalued. It’s the real speed limit on how fast an organization can safely go, and the teams proudest of their velocity are the ones most likely to find out where it sits. That limit is measurable, and it’s worth finding before the roadmap assumes it away.