The Pace Fracture
When AI splits the team faster than any reorg ever could
Deep Dive #2 in “The Centrifuge” Series — Team Level
The message came on a Friday afternoon, in a one-on-one that was supposed to be a formality. A senior developer, one of the best on the team, calm voice, no drama: “I need to move on. I can’t keep pretending I understand what the others are shipping.”
She had fifteen years of experience. She’d built half the platform. She wasn’t struggling with the technology. She was struggling with the pace of people around her who’d stopped explaining what they were doing, because explaining had become slower than doing.
That was the first fracture. The second came two weeks later, when one of the fast movers quit. His reason, nearly the inverse: “I’m tired of pulling people along. I want to work with a team that can keep up.”
Same team. Same sprint. Two resignations. Opposite reasons.
Every team lead running an AI-assisted engineering group has seen some version of this. The surface symptom varies — attrition, silence in standups, pull requests that nobody reviews because nobody understands them fast enough — but the underlying structure’s the same. AI acceleration doesn’t lift the team evenly. It creates a gradient. The gradient starts small, a matter of hours saved per week, and compounds until two people sitting three desks apart are operating in different centuries of productivity. One ships a feature in an afternoon that the other would need a week to build. Both know it. Neither says it out loud.
The word most organisations reach for is “skill gap.” The remedy they reach for is training. Send everyone to a prompt engineering workshop. Buy licenses. Share tips in Slack. Training isn’t wrong. It’s insufficient. What’s fracturing the team isn’t a knowledge deficit. It’s a pace differential that training can’t close, because the fast movers are also still accelerating. By the time the workshop graduates apply what they learned, the target has moved.
Watch a fractured team in a planning meeting. The fast movers are impatient. They have already sketched the solution in their heads, possibly already prototyped it during the discussion. The slower members are still trying to understand the problem statement, which was written in fifteen minutes by someone using AI and covers ground that would have taken a day to draft six months ago. The planning meeting is supposed to create shared understanding. Instead it creates shared pretence. People nod. People agree to timelines they know they cannot meet. The fast movers leave thinking alignment was reached. The others leave knowing it was not, and knowing that saying so will mark them as the problem.
This isn’t a training problem. It’s a pace architecture problem. Pace architecture is a term borrowed from building design, where Stewart Brand observed that different layers of a building change at different speeds: the site is permanent, the structure lasts decades, the services change every fifteen years, the space plan every three, the stuff inside daily. A building works because these layers are decoupled. Each moves at its own rate without forcing the others to match. Teams need the same principle. Not everyone moving at the same speed, but a structure that allows different speeds to coexist without tearing the fabric.
The instinct of most organisations is to solve the fracture by closing the gap. Get the slow people faster. The instinct’s wrong, not because speed is bad, but because the gap’s a symptom of a missing interface between speeds. Consider what actually breaks. It’s not that the fast mover writes better code. It’s that the fast mover writes code that skips three steps the team used to share: the design discussion, the architecture sketch on a whiteboard, the verbal walkthrough during review. AI compressed those steps into the prompt history, which lives in the fast mover’s terminal and nowhere else.
Knowledge transfer used to happen as a side effect of slow work. The discussion was the transfer. The whiteboard was the transfer. The review was the transfer. Speed removed the friction, and with it the mechanism by which the rest of the team stayed informed. Restoring that mechanism is the actual task. Not slowing down. Not speeding up. Building the bridge that pace destroyed.
What works, in practice:
Separate throughput from synchronisation. Let fast movers move fast, but install explicit synchronisation points that are not optional and not about permission. A weekly thirty-minute session where the person who shipped explains not what they built but how they thought about it. The session isn’t a status update. It’s a thinking transfer. The team doesn’t need to match the speed. It needs to match the mental model.
Make the AI work visible. The prompt history, the iteration log, the dead ends — all of it is currently invisible to the team. A fast mover who ships a feature in an afternoon has an afternoon of context that nobody else possesses. Require a lightweight decision log: what was tried, what was rejected, what assumptions were made. This costs the fast mover ten minutes and saves the team days of reverse-engineering.
Create pace lanes, not pace targets. Not everyone needs to use AI at the same intensity. That’s fine. Some team members will be most valuable as reviewers, architects, domain experts — roles where deep understanding matters more than throughput. A team that forces everyone into the fast lane loses the people whose strength is depth. A team that creates explicit roles at different speeds keeps both.
Redesign code review for the new asymmetry. The old model — everyone reviews everything — breaks when one person produces in a day what three people used to produce in a week. Reviews pile up, quality drops, resentment builds. Instead, pair fast movers with specific reviewers. Give reviewers time that is protected from their own delivery targets. Treat review as a first-class activity, not a tax on shipping.
Staff the team for the gradient, not the average. When hiring or restructuring, stop optimising for uniform capability. A team needs people who can sprint and people who can sustain. People who generate and people who integrate. The fracture happens when the organisation pretends these are the same role and measures them on the same axis.
There’s a harder question underneath all of this, one that most organisations aren’t ready to ask: do we still need teams at all?
The traditional team exists to solve a coordination problem. No single person could hold enough context, write enough code, test enough scenarios, or review enough decisions alone. The team was the minimum viable unit for shipping something complex. But AI is systematically removing the reasons teams needed to be large. One person with the right tools now holds context that used to require three. The design discussion, the architecture sketch, the implementation, the test suite — a single developer with an AI pair can carry all of it without handing off to anyone.
This doesn’t mean collaboration is dead. It means the unit of collaboration is shrinking. A team of eight with a two-speed fracture might work better as two pods of two, each fully autonomous, connecting at well-defined integration points rather than in daily standups where half the room is pretending to follow along. The coordination cost of a large team — the meetings, the reviews, the alignment rituals — was always a tax. When everyone moved at the same speed, the tax was bearable. When the pace fracture opens up, the tax becomes the thing that breaks people.
Smaller isn’t just more efficient. It’s more honest. A pod of two doesn’t need pace lanes because there’s no crowd to sort into lanes. It doesn’t need thinking transfer sessions because both people are already in the same conversation. The overhead that the previous section proposed — decision logs, synchronisation points, protected review time — is medicine for a disease that smaller units simply don’t catch.
The risk, of course, is isolation. Autonomous pods can drift. They can duplicate work, diverge on architecture, or optimise locally in ways that hurt the whole. The answer isn’t to bolt the old team structure back on. It’s to replace team coordination with system coordination: shared interfaces, automated integration checks, lightweight architecture reviews that happen asynchronously. The glue moves from people to infrastructure.
Not every organisation is ready for this. Some domains genuinely need large-group collaboration — security-critical systems, regulatory environments, anything where a single person’s blind spot can cause real harm. But for the majority of product engineering teams, the honest conversation isn’t “how do we keep the team together under AI acceleration.” It’s “how small can the team get before we lose something we actually need.”
The hardest part of the pace fracture is that nobody caused it. No one made a bad decision. The fast movers did exactly what the organisation asked: adopt the tools, increase output, ship faster. The slower members did what experience taught them: be thorough, be careful, understand before acting. Both behaviours were rational. Both were rewarded, until suddenly they were not rewarded equally, and the team split along a line that did not exist six months earlier. The team lead sits in the middle, watching the gap widen, knowing that a training budget won’t close it and that telling the fast movers to slow down will drive them away. The honest answer is that the team’s structure was designed for a world where everyone worked at roughly the same speed, and that world’s gone.
The new structure needs pace lanes, thinking bridges, and the organisational honesty to say: we are no longer one speed, and pretending otherwise is the fastest way to lose people on both ends. The centrifuge doesn’t care about intention. It separates by weight. The only teams that stay whole are the ones that build the structure to hold together under spin.
Next in the series: Deep Dive #3, Resistance Is Not the Problem, on what happens when the organisation mistakes self-preservation for obstruction.
This essay is part of The Centrifuge, a hub for exploring the human cost of AI acceleration at the individual, team, and organisational level.