Pacing everything else to it

The second step of Improve sounds backwards. Having got more out of the bottleneck, you now hold everything else back to its pace. It's the step most AI rollouts skip, and it's the one that stops AI making things worse.

Faster upstream just makes the pile bigger

You saw the pattern in module 1: when engineering teams adopted AI heavily, Faros AI found they merged 98% more pull requests while time spent in review rose 91%. Every step before review sped up. Review didn't, so the extra work queued there.

Google's DORA research programme found the same shape across the whole delivery process. In its 2024 report, more AI adoption went with better documentation, better code and faster code reviews. Delivery itself got slightly slower and noticeably less stable.

DORA's reading was that a better development process doesn't automatically mean better delivery, not without the basics, such as small batches and robust testing. It's the same mechanism, whatever your work is. When the steps before the bottleneck speed up and nothing paces them, more work arrives than it can take, and the extra has to wait somewhere.

The pile is where workslop collects

Researchers at BetterUp Labs and Stanford's Social Media Lab named the result in the Harvard Business Review in September 2025: workslop, AI-made work that looks finished but lacks the substance to move the task on, so the real work lands on whoever receives it.

Think about where that lands. Upstream teams are measured on how much they produce, so they produce more, faster, with AI. The bottleneck is where all of it arrives. Every piece that isn't really finished costs the bottleneck an hour it doesn't have. This is why the first principle has two halves: fix the bottleneck, and don't flood it.

The arithmetic of waiting

There's a simple rule behind all of this. How long new work waits equals how much work is waiting, divided by how fast it's being finished. The operations researcher John Little proved it in 1961, and it holds for any queue that's reasonably steady: a hospital ward, a help desk, a contracts in-tray.

If the bottleneck finishes 20 items a week and 60 are waiting, a new item waits three weeks. With 10 waiting, it waits half a week. The bottleneck delivers 20 a week either way. The pile doesn't make it faster. It only makes everything slower to come out.

Release work at the pace the bottleneck can take

So the fix is to stop the pile forming. Put a cap on how much work can be started and waiting at the bottleneck at once, and release new work only as room appears. Manufacturers call this a pull system: the bottleneck pulls work in, rather than having it pushed at it.

Work that isn't released isn't lost. It waits unstarted, where it costs nobody any time and can still be reprioritised or dropped. And if more is arriving than the bottleneck can take, the cap makes that visible as a decision for the bottleneck lead, rather than a pile nobody chose.

Try it below. Start with the uncapped line, then give upstream AI and watch what happens to the wait.

What upstream does instead

A cap means the teams before the bottleneck will have spare time. That's the point, and it's also the risk: left alone, spare time turns into more output for a pile that's been capped. Say in advance where it goes.

• Checking that work is complete before it's released, which is lesson 3's second move.
• Taking on the tasks the redesign moved off the bottleneck.
• Improving their own work in their protected hours.
• Going wherever the aim page says freed time goes.

The fourth principle applies here too. Time a person saves counts as spare capacity, not value, until it goes where the aim says. And never measure upstream teams on how much they produce, or how much AI they use. Either measure rewards exactly the flood you're trying to stop.