If AI made one step faster and the whole workflow did not speed up, that step was probably not the one holding the work up. The extra output is now waiting further down the line, at a review, an approval, a test or a decision, and the work still finishes at the pace of that slower step: the AI productivity paradox, inside one workflow.<\/p>\n
So output per person can rise while what the team delivers stays flat. Before you pay for the next tool, or pay to speed up the same step again, follow one recent piece of work through every step and find where it waited longest. That is where the next budget goes.<\/p>\n
The principle is old and well established. The Theory of Constraints Institute<\/a> puts it bluntly: “Strengthening any link of a chain (apart from the weakest) is a waste of time and energy.” In a chain of steps, the weakest one sets the pace. Make any other step faster and the finished output does not change.<\/p>\n The faster step can also make things worse in one way: it sends more work to the slow step. Take a hypothetical sales team that now drafts quotes with AI. If every quote still needs the sales manager’s sign-off, and the manager clears approvals twice a week, faster drafting just builds a bigger pile on the manager’s desk. Quotes still go out on the same two days. The drafting tool works perfectly, and the customer waits as long as before.<\/p>\n This is why “the tool works” and “nothing got faster” can both be true<\/a>. The tool’s job was one step. Your turnaround time belongs to the whole chain.<\/p>\n Software development is one place this has been measured at scale. Faros AI’s AI Productivity Paradox Report 2025<\/a> drew on data from more than 10,000 developers across 1,255 teams. On teams with high AI adoption, developers completed 21% more tasks and merged 98% more pull requests (code changes submitted for review), while the time those changes spent in review rose 91%. Faros found no significant correlation between AI adoption and improvements at company level. OpenAI hit a version of the same strain: according to Let’s Data Science<\/a>, reporting on an OpenAI engineering post, OpenAI built a new Git backend because “the systems behind its internal monorepo struggled with the volume of work Codex makes possible.” Two limits apply. Faros’s analysis is correlational: it shows AI adoption and longer reviews moving together, not that AI caused them. And all of this is software, not quotes, bookings, content or reports. The principle carries over. The numbers do not.<\/p>\n None of this means AI speedups never pay off. Google’s 2025 DORA report<\/a>, a survey of nearly 5,000 technology professionals, found a positive relationship between AI adoption and software delivery throughput, so in some organisations the gain did reach delivery. In customer support, a study by Brynjolfsson, Li and Raymond (NBER Working Paper 31161, “Generative AI at Work”<\/a>) followed 5,179 agents at one firm and found that an AI tool raised issues resolved per hour by 14% on average. There, the step the tool sped up was the job itself, so a faster step meant more output.<\/p>\n So “does AI help?” is the wrong question. The useful question is: was the step you sped up the one the work was waiting on?<\/p>\n You cannot answer that from the inside. In a study by METR<\/a>, experienced open-source developers working on their own mature projects took 19% longer with early-2025 AI tools than without them, and afterwards still believed AI had sped them up by 20%. The result is narrow, and METR’s study page, checked on 8 November 2026, marks it out of date and points readers to a February 2026 update. The lesson is not that AI makes people slower. It is that felt speed and measured speed can point in opposite directions.<\/p>\n Drafts that appear in seconds feel like progress. Whether the customer got the quote sooner is a different question, and only timestamps answer it.<\/p>\n Here is the trace Dr-Business suggests. It is not a published standard. It applies the constraint principle to a single item, using records most teams already keep.<\/p>\n Here is what a finished trace could look like for the hypothetical quote from earlier. The numbers are illustrative, not from a client:<\/p>\n AI cut the drafting work from two hours to ten minutes, and the customer still waits about two and a half days, because 54 of the 60 waiting hours sit at approval. The saving is under 3% of the old turnaround. To run the trace on your own work, copy this table and replace the rows with your item’s steps.<\/p>\n Then repeat it for two or three more items. One item can mislead you, because one manager’s holiday looks exactly like a workflow bottleneck.<\/p>\n Now look at two things: how much time is left in the step you sped up, and how the total splits between waiting and working. When the wait is large next to the work, no tool that makes the work faster will move the finish date much.<\/p>\n David Sabine makes the same point for software teams on the Scrum.org blog<\/a>: “Notice where the work waits in the flow. Those are the new bottlenecks.”<\/p>\nWhat software teams saw when coding got faster<\/h2>\n
When the speedup does reach the business<\/h2>\n
Feeling faster is not a measurement<\/h2>\n
Trace one piece of work, step by step<\/h2>\n
\n
\n\n
\n \nStep<\/th>\n Waiting (arrived to started)<\/th>\n Working (started to left)<\/th>\n<\/tr>\n<\/thead>\n \n Request logged and assigned<\/td>\n 2 hours<\/td>\n 5 minutes<\/td>\n<\/tr>\n \n Quote drafted, now with AI<\/td>\n 1 hour<\/td>\n 10 minutes (was 2 hours)<\/td>\n<\/tr>\n \n Manager approval<\/td>\n 54 hours<\/td>\n 10 minutes<\/td>\n<\/tr>\n \n Quote sent to the customer<\/td>\n 3 hours<\/td>\n 5 minutes<\/td>\n<\/tr>\n \n Total<\/strong><\/td>\n 60 hours<\/strong><\/td>\n 30 minutes<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Where the next budget goes<\/h2>\n