McKinsey surveyed 1,719 leaders across 97 countries this past May and June. Nearly nine in ten use AI somewhere in the business, and about four in five say it has made them personally more productive. The share who say AI has contributed to EBIT is 37%, almost exactly where it sat a year ago. Adoption is finished, the productivity is real and widely felt, and it is not reaching the income statement.
I spent the last stretch of my career running delivery for a 50+ engineering organization across the United States, Italy, and India. When we started, releases slipped and defects averaged 170 a release. We got to 13 consecutive releases on time and on scope, with defects under 60. It is worth being precise about how, because it is the same thing this survey is describing. Nobody started typing faster and nobody on that team was underperforming. What changed was making all work visible, understanding where it queued, and who had to touch it before it could move. The steps were never the problem. The route was the problem.
You have read this book already
If you have been in engineering leadership any length of time, somebody handed you The Phoenix Project. Gene Kim, Kevin Behr, and George Spafford, 2013. It is a novel about a man given ninety days to save a late project or watch his department get outsourced, and it taught a generation of IT leaders more than most of the non-fiction did, because it smuggled in Goldratt's Theory of Constraints without making anyone read a textbook.
The character everyone remembers is Brent. Brent is brilliant, knows how everything fits together, and so nothing ships without him. Every escalation and change routes through one person, and the organization moves at the speed of Brent's calendar no matter how many people get hired around him. The lesson underneath is that an improvement made anywhere other than the constraint is not an improvement. It moves work into the queue in front of the bottleneck faster.
Hold that next to what your AI rollout has been doing. AI is an extraordinarily good machine for making an individual step faster, and that is what every tool is sold on. But the constraint is almost never an individual step. It is a person everything routes through, a review nobody can skip, an approval waiting on another timezone, a handoff where work goes to sit. So you buy speed, everyone gets faster at their own piece, and the work arrives at the constraint sooner and waits there longer. You have given Brent a faster keyboard.
Let me place the line, because there is a version of this argument that insults people doing work. If you run a small operation and AI gave you back six hours a week, that is the entire win. Take the deal. But if you lead a team you have probably noticed the gains stopped compounding, and the ceiling has the shape of the workflow you already had. A process with two days of touch time inside eleven days of calendar time does not get fixed by turning the two days into one. You optimized real savings in those two days, and left the calendar time as your customer experience.
Efficiency is the entry fee
Here is the finding I would put in front of a leadership team, because it quietly dismantles the assumption most AI plans rest on. About 80% of the high performing companies are pursuing efficiency gains from AI. About 80% of everybody else is pursuing exactly the same thing. Efficiency is not what separates them. It is the entry fee, and the whole market has paid it.
What the companies seeing AI in their financials do differently is not a technology choice. They redesigned how work flows instead of inserting AI into the flow they inherited, and they went after growth rather than cost alone. Roughly three-quarters of high performers report fundamentally redesigning workflows, up from 55% the year before, compared to about a quarter of everyone else. One group bought a faster engine for the same route. The other group redrew the route for the faster engine.
What redesigning a workflow actually means
The phrase has been used loosely enough to stop carrying information, so here is what it looks like from the inside. Three things change, and if none of them did, it was not a redesign. There are fewer steps rather than faster ones, usually because a step existed only to carry information between two places that now share it. Second, the handoffs change, so work stops travelling down a chain and goes to whoever can finish it. Most calendar time is spent waiting at a handoff rather than being worked on, which is where the recoverable time hides.
Third, and this is the jump most organizations have not made: review becomes exception based rather than routine. Right now somebody reviews everything, because there is no way to know in advance which ones have a problem. That review is necessary work and in a lot of shops it is the actual constraint, which is why automating the step before it changed nothing. It is Brent in a different chair. The alternative is a system that assesses its own output, passes what it has grounds to be confident about, and escalates what it does not, so your reviewer reads the fraction that got flagged instead of all of it. That is not a faster review. It is a different job, and it is where the capacity comes from.
It is also the answer to what makes experienced leaders reluctant to hand work to a machine. The fear was never that it would be obviously wrong, because obvious errors get caught immediately and loudly. The fear is that it will be quietly wrong with complete confidence, in a way nobody notices for a month and you hear about from a customer. A system built to know the edge of its own competence and stop there is how you get out of that, and it cannot be bolted on afterwards.
Why this lands on you
This is the part that explains why it stalls, and it is not a technology or a talent problem. Nobody can redesign a workflow from inside a tool, because the workflow crosses teams. It touches how another function accepts work, who signs off, what somebody promised a customer, and which report an executive reads on Monday. Changing that requires authority over how work moves through the business, and the person holding that authority is usually not the person evaluating the software. So AI gets handed to whoever will build something with it, and they do the only thing they are permitted to do, which is make the existing steps faster. Everyone gets quicker, the route survives untouched, and the number at the end of the year is 37%.
The same survey found that at larger companies the element with the most impact on AI's contribution to EBIT is executive oversight. Not model selection, not platform, not spend. Whether somebody senior owned the outcome. Which is, again, the plot of the book: Bill Palmer fixes his company by buying nothing at all, and no framework does it for him. He finds out where the work actually is, makes it visible, and takes responsibility for how it flows.
Where that leaves you
If AI has made your team faster and your quarter looks the same, nothing has gone wrong and you are not late. You did the sensible thing first and it worked as well as it was ever going to. The next move is not another tool. Take one workflow that matters, map how it really runs including the parts nobody wrote down, and find where work waits rather than where work is slow. Then ask which steps could stop existing, which handoff costs you days rather than minutes, and what would have to be true for your reviewer to stop reviewing all of it.
One last thing, from the delivery side rather than the strategy side. Nothing is hands free on day one. A redesigned workflow needs weeks of somebody watching what the system flagged, what it passed, and what it got wrong, before anyone sensibly trusts it running unattended. Budget those weeks and you end up with a system your people rely on without thinking about it. Treat go live as the finish line and you end up with a prototype and a launch party. The gains are real and still sitting there. They are just not in the part everybody automated first.
If your team got faster and your numbers did not, I am genuinely interested in which workflow you would pick first. Reply, or find me on LinkedIn. I do this work for a living and I am happy to talk it through either way.
Tim Gemoll runs T2C, where he leads AI and automation delivery for companies that need it working in production. He has spent nearly twenty years in software delivery, climbing four levels at one company to run a 50 engineer organization across the United States, Italy, and India, where his teams delivered 13 consecutive releases on time and on scope and cut release defects by more than half.
If you want somebody to map that workflow with you, that is what the ClearPath Technology Map is for.