A team starts shipping AI-assisted work at a genuinely different pace — reviews that took days now take hours, releases that took weeks now take days. The team downstream, the one that has to sign off before anything reaches production, hasn’t changed at all. Its review process was fine last quarter. Now a queue that used to clear itself is backing up, and both sides have a story: the fast team thinks the slow team has become the bottleneck; the slow team feels pressured to rubber-stamp work it hasn’t had time to actually check.
This isn’t a skills gap. It’s a pace gap
Neither team did anything wrong. The downstream team isn’t undertrained — its process worked fine until very recently. The upstream team isn’t reckless — it adopted a capability that happened to work. What changed is narrower and newer than either story: two teams that used to move at roughly the same speed no longer do, and nothing about how they coordinate was built for that difference. This is not the general problem of work crossing functional boundaries, which is old and well understood. It’s a specific, new kind of mismatch: the same two teams, the same dependency, a pace gap that didn’t exist a year ago.
Neither team owns the gap between them
The gap doesn’t show up on either team’s backlog, because it isn’t inside either team’s work — it lives in the space between their two plans. The fast team’s roadmap says “ship this.” The slow team’s roadmap says “review what arrives.” Neither roadmap has a line item for “figure out what to do about the fact that these two paces no longer match.” It isn’t anyone’s job by default, so by default nobody does it — until the queue is visibly backed up and each side has already decided who’s to blame.
Whose job is it to slow down?
Eventually someone has to choose, and both defaults are bad. The fast team can throttle its own pace to match the review team’s capacity, which gives back most of what AI adoption was supposed to gain. Or the review team can compress its process to keep up, which means trusting AI-assisted output faster than it has actually earned that trust. Neither choice is obviously right, and — this is the actual problem — neither team has the standing to make that call for the other one. It’s a decision that sits between two roadmaps, made by someone who isn’t formally in charge of either.
What it looks like when someone closes it
The organizations that handle this well don’t solve it with a policy. Someone — from either team, or a shared function that touches both — notices the mismatch early, sits with both sides long enough to understand what each one actually needs, and negotiates something temporary: a staged trust ramp, a narrower review threshold for lower-risk changes, a checkpoint that lets the slow team build confidence without stopping the fast team cold. Nobody assigned them this. They stepped into a gap that had no formal owner because they were the one who noticed it mattered, in the same spirit as Who Owns the Judgment When the AI Expert Steps Back? — someone has to hold accountability that isn’t written down anywhere yet.
This sits alongside, but is not the same as, When the Org Chart Blocks the Flow: that article is about naming who formally owns a new AI-created dependency. This one is about the informal, unassigned work of noticing a pace mismatch and acting on it before anyone gets around to naming an owner at all.
Where this connects to a wider transformation question
Noticing a pace gap and closing it before it hardens into a standing blocker is itself a capability an enterprise can build deliberately, the same way capability building around real work treats any other Human + AI working pattern. The Flow Cracker Playbook frames the same underlying move: understand what has actually changed between two teams before assuming either one is simply slow.
Uneven AI adoption isn’t a problem that resolves itself once every team eventually catches up. It needs someone willing to notice the gap while it’s still small, and to treat closing it as their job even though no chart says it is.