Capacity to Improve
The team saved time with AI, and some of it was promised to fixing the work itself. Three months later, the same problems come back every month, and someone still fixes them by hand.
Definition
Capacity to improve is freed time spent changing the work so the same result takes less effort, or the work fails less often.
A workaround is not an improvement. It gets today's work done and leaves the cause in place for tomorrow. An improvement has happened when the change is in daily use and the problem comes back less often.
Improvement makes capacity by removing work that would otherwise recur. Better quality frees capacity too, by cutting rework.
The recognition pattern
- Improvement time is on the calendar, and it keeps getting borrowed for the backlog.
- The same problems are fixed by hand every week, by the same people.
- The first bad month ends the improvement work, and nobody restarts it.
Why freed time does not reach improvement
Daily work takes the time back
A nurse runs short of linen, finds some on another unit and gets on with the shift. The shortage will be back tomorrow. Researchers watching hospital nurses saw them use a workaround for 93% of the problems they met, rather than fix the cause. Those workarounds took about 8% of a shift (Tucker and Edmondson, 2003).
When work falls behind, working harder pays off today, but improving pays off later. So people work harder, and the freed time goes to workarounds.
A fixed allocation does not protect the time by itself. Atlassian gave its developers "20% time" for their own projects. After a year, its records showed about 1.1% of developers' time spent on those projects. The company put the true share at two or three times that. Frequent releases, it said, made the time hard to schedule (Atlassian, 2009).
The dip comes first
At BP's Lima refinery, an improvement program raised maintenance costs by 30% in its first six months. The program's results were later valued at about $43 million a year, against a cost of about $320,000 a year (Repenning and Sterman, 2001).
Improving usually costs something before it returns anything, because it draws on the same people and hours as today's work. That cost is the dip, and this quarter's numbers show it. The return comes later, often after the program has been judged on the dip.
Turn every gain into a cut, and the gains stall
Art Schneiderman, head of quality at Analog Devices, said that after the company's first layoffs, its quality program stalled. In his words, people "didn't want to improve so much that their job would be eliminated" (Sterman, Repenning and Kofman, working paper, 1994).
If each gain becomes a cut, the people who would make the next gain have a reason not to. Where Freed Capacity Goes tells the story of the layoffs.
What it costs
When freed time never reaches improvement, the recurring problems eat into the AI's saving every month. The improvement that would have freed more time never happens, so the organization keeps paying for the problem and for the AI.
The lasting cost is people's willingness to improve. Once they learn that improving is risky or pointless, as Analog's staff did, they stop offering improvements. That willingness is slow to rebuild.
Boundaries and distinctions
Improvement is not more output. More output repeats the work, problems and all. Improvement changes it.
Improving a step is not redesigning the workflow. Fixing the feed in the example below improves one step. Enough such changes can add up to reconfiguration, the same result through substantially changed work. Redesigning a whole workflow around AI is a larger question, beyond this series.
Reinvesting freed time first does not mean never cutting jobs or budgets. In the programs that kept improving, leaders "explicitly" allocated "the resources freed up by productivity gains to further improvement" (Repenning and Sterman, 2001). Protecting jobs alone is not enough, as Where Freed Capacity Goes explains. A later page will cover when a cut pays off.
The evidence is older than AI. No measured case yet shows how much AI-freed time goes to improvement and how much is absorbed by daily work and other demands. The closest evidence is a 2026 vendor survey by Atlassian, the company behind the "20% time" records. Asked what work they had to take on with the time that AI saved, about half of product professionals named supervising AI. And 77% had set no time aside to address technical debt. Each figure is a self-reported share of respondents, not a share of the saved time. DORA's 2025 research describes AI as an amplifier of an organization's strengths and dysfunctions alike. Together with the older cases, that description gives good reason to expect the same dynamics with AI-freed time, but not proof.
Example
In a constructed example, a five-person finance team uses AI to reconcile accounts, and its month-end close now takes two days instead of four. So the AI saves the team about ten person-days a month. Every month, the same mismatches arrive from one upstream billing feed, and two people fix them by hand. Fixing the feed would take two people one day a week for six weeks. That is about twelve person-days, a little more than one month's saving. The team agreed to put some of the saved time into fixing it. By the third month, the saved days had gone to new reporting requests, and the feed was still unfixed.
Nobody chose the reporting requests over the feed. To fix the feed, protect one day a week for each of the two people for six weeks. Say who cannot borrow those days. Expect a dip: while the feed is being fixed, the new reporting requests wait. Once the feed is fixed, the hours that went to fixing mismatches by hand are free. Decide now that they go to the next recurring problem.
Applied test
- Find the recurring problem that takes your team the most person-hours of manual correction each month. Count the manual corrections and their person-hours now.
- Choose the change that will make the problem recur less. Name one owner, the hours a week to be protected for it, and who can and cannot borrow those hours.
- Say how long a dip you will accept, and which other work will wait during it. Make sure whoever will judge the dip sees both counts from step 1.
- Judge the change against both counts from step 1. The change has worked when it is in daily use and the problem comes back less often.
- Decide now where the time freed by the change will go next.
If you cannot protect those hours yourself, take this list to whoever can.
Sources and lineage
Capacity to Improve is part of Applied Enterprise AI, a body of work developed by Curtis Hibbs and Joshua Barnes. The reinvestment loop, where each improvement pays for the next, comes from Applied End-to-End Flow. Repenning and Sterman named the capability trap (daily work taking back the time for improvement) and worse before better (the cost that comes before the return). The page also draws on:
- Repenning and Sterman, Nobody Ever Gets Credit for Fixing Problems that Never Happened, California Management Review 43(4) (2001).
- Sterman, Repenning and Kofman, Unanticipated Side Effects of Successful Quality Programs, MIT working paper 3667-94 (1994), the source of the Schneiderman quotation; published in Management Science 43(4) (1997).
- Tucker and Edmondson, Why Hospitals Don't Learn from Failures, California Management Review 45(2) (2003).
- Atlassian, Atlassian's 20% Time: A Year in Review (2009).
- Atlassian, The State of Product 2027, a survey of 1,000 product professionals by Wakefield Research (August 2026).
- DORA, State of AI-assisted Software Development 2025.