What happens when AI makes the wrong work faster?
AI may accelerate individual activities without improving end-to-end delivery, potentially increasing pressure on downstream constraints.
The pitch for most AI tooling is that it makes a particular activity faster. Code is written faster. Documents are drafted faster. Tickets are triaged faster.
That is often true, and it is worth asking what happens to the rest of the system when it is.
Consider a delivery process in which implementing a change takes a week, waiting for review takes a week, and waiting for a release window takes two more. Halving implementation time saves half a week out of four. That is a real gain, but it is not the fourfold improvement the demo implied, and it tends to come with a side effect: the reviewers now receive twice as much to review, and their queue grows.
This is the basic shape of the question. Any system has constraints, places where work accumulates because capacity is lower than demand. Speeding up an activity that is not the constraint does not increase the throughput of the whole. It increases the pile in front of the constraint. If the constraint is a review step, an approval board, a platform team or a shared environment, then faster implementation can make the end-to-end experience worse, not better, because more work is now waiting and the people at the constraint are under more pressure.
None of this is an argument against AI. It is an argument for thinking about the wider system before deciding where to apply it. The organisations that benefit most from acceleration will be the ones whose structure lets accelerated work actually reach users.
Coordination and cognitive load
Two things deserve particular attention. The first is coordination. If a change requires several teams to agree before it can ship, the agreement is the constraint, and no amount of faster drafting will move it. Reducing the number of teams that need to be involved, or making their interactions more routine, does.
The second is cognitive load. Generating more output does not reduce the amount a team has to understand, maintain and be responsible for. It can increase it. A team already stretched across too many systems does not become less stretched because the code arrives faster. The limiting factor becomes the team’s ability to understand what it now owns.
So the useful question is not whether AI makes something faster. It almost certainly does. The useful question is what the system does with that speed, and whether the structure around the work is ready to turn it into value.
Is the work being accelerated the work your users most need done — and how would you know?
Speeding up delivery of the wrong thing is still a cost. The question of what to build is upstream of the question of how fast to build it.
Rich Allen
Rich Allen is a UK-based sociotechnical architecture consultant. He helps organisations improve the flow of value through people, teams, technology and organisational structure. He is the author of User Needs Mapping: Aligning Teams Around What Matters, a long-standing Team Topologies Valued Practitioner and the creator of the Fast Flow Toolkit.
He works with engineering and product leaders to make the flow of work visible and to change team boundaries on evidence. Flow Awareness Sessions are a low-commitment place to start.
Have a question worth exploring together?
Sometimes an outside perspective helps make a difficult organisational problem clearer. If one of these questions resonates, I’d be happy to explore it with you.