AI is going to speed up delivery. That part isn't in question anymore, and most of the leaders I talk to have accepted it and are eagerly anticipating it. What far fewer organizations have thought through is what happens the moment it does. If it still takes you hundreds of days to decide what to build and why, then a faster build cycle doesn't buy anyone anything, because the building was never the part that was slow. And the constraint I think most of us learned to explain away as the cost of doing business at scale is about to become the only thing anyone can see.
Barry O'Reilly sent me a message this week that I haven't been able to stop thinking about. He's been developing an idea about AI creating a "processing tax" inside organizations, and the observation he shared was this: AI dramatically increases the amount of work teams can produce, but the bottleneck shifts to deciding what actually matters. Then he asked whether I was seeing the same thing.
My first answer was that I could feel it as a person long before I could see it in my organization.
The part everyone can already feel
I can produce more in a morning now than I can read in an afternoon. Three versions of a blog post, a workshop agenda, an outline for this, new content for that, a summary of a summary. The production is fast and it's a little intoxicating. But then I have to read all of it to find out whether any of it is any good, and that reading is no faster than it's ever been. Same brain, same speed, just more input. Whatever I saved on the way in, I pay back on the way out, sometimes with interest, because now I'm evaluating four options instead of having written one.
If a single person can feel that in a single morning, what happens when ten thousand people feel it at once, inside the same company, all pointing their new capacity at whatever seemed reasonable that week?
Barry named it, and the credit belongs to him
He wrote about this publicly earlier this month, in a piece about measuring AI outcomes. His framing is that the production cost has collapsed while the processing cost has moved downstream, and that it keeps filtering upward toward executives, who have the least spare capacity to absorb any of it. He also makes a point I'd rather repeat than try to improve on: AI isn't creating these problems. Unclear ownership, duplicated effort, broken handoffs, slow decisions, all of that was already there. AI is just exposing the slow parts of our organizations that we used to be able to hide.
I think that's right. But knowing the bottleneck has been exposed isn't the same as knowing what to do about it, and that second part is what I want to add here.
What Goldratt already told us about this
Eliyahu Goldratt gave us the answer decades ago, in The Goal, which described the theory of constraints elegantly through a novel about a manufacturing plant. Every system has a constraint. Speed up a station that isn't the constraint and you don't get more throughput. What you get is more inventory piling up in front of the constraint that was already there.
That's the processing tax. AI is accelerating software delivery, and in doing so it leaves the upstream work completely untouched: deciding what to do, shaping features, aligning work to a strategy, understanding what customers actually need. Those activities are not getting faster. Which means the idea generators, the business and product leaders, become the constraint on the whole system.
And I know the objection, because I've already heard it: we're using AI in the business too. That's true, and it will help some. But I don't think it will help at anything close to the same rate, because the upstream work isn't slow for lack of typing. It's slow because it runs on agreement. Five stakeholders have to align, a risk review has to be scheduled, somebody with the authority has to decide what the company is willing to bet on. AI can draft the document that goes into that meeting and it can sharpen the options inside it, but it cannot get the meeting on the calendar any sooner and it cannot make the decision for you. A development team also knows when it is finished, because the tests pass and the code deploys. There is no equivalent signal telling you that you have decided the right thing, and I think that is a large part of why deciding has always been the slow end of the system.
And this is where an old piece of coaching advice gets a brand new reason to be true. We have been telling leaders for years to push decisions down to the teams closest to the work. Most organizations have nodded at that and kept deciding at the top, because they could afford to. The cost was a few weeks of delay nobody measured. That is about to change, because AI will make you the bottleneck if you don't.
The constraint was always upstream, in the part nobody ever timed
I've worked with organizations where a feature takes hundreds of days to get from somebody's idea to ready enough to hand to a delivery team. Hundreds, and sometimes closer to a full year. And when those same organizations describe themselves as agile, the scrutiny falls almost entirely on the development teams: their velocity, their sprint commitments, their burndown charts, their standups. Meanwhile that feature sat in an intake queue and went through a long stretch of big design up front, not only of the outcomes and possible solutions but of the legal, risk, and compliance conversations too, each one scheduled around somebody else's calendar. In many large companies, that upstream stretch is a bigger portion of total delivery time than the building part ever was.
Mik Kersten shares an eye-opening number that shows how big the problem really is. When Nationwide Insurance measured why features were taking 120 days to reach customers, they found that only 2.5 percent of that time was active development. Everything else was waiting, in the business to the left and in release management and deployment to the right. Doubling the size of the engineering team would have changed almost nothing about the customer's experience.
That's still the shape of most large organizations, even when it's better disguised. Sequential, committee-driven decision work upstream. An agile-looking middle. A gated release process downstream. Classic water-scrum-fall. The reason it persists is not that people are unaware of it. It persists because the full feature flow time is rarely calculated and almost never monitored, which means nobody ever has to look at it.
We ran this experiment once already
And this is the part that should make everyone a little nervous, because we've done this before.
Agile did to the middle of the value stream exactly what AI is now doing to it. It multiplied capacity at one station. What happened next is well documented and widely lived: the teams got demonstrably faster, the features didn't, and organizations spent the following fifteen years reporting velocity to executives who couldn't work out why customers weren't getting anything sooner.
Which is how we ended up with "agile didn't work for us." You have heard the agile transformation failure statistics, and I would treat the specific numbers with some suspicion, because the widely quoted ones rarely trace back to a study that holds up. But the sentiment behind them is real, and I think almost nobody names the real reason. The transformation believed it was going to improve the end-to-end flow of value from idea through delivery to the customer. All it ever worked on was the middle. And even where that was done extremely well, the organization didn't see much change and concluded, incorrectly, that agile had failed them.
AI is now running the same play on the same station, with a much bigger multiplier. The business has been just barely keeping its head above water producing new ideas and features for teams to build. When those teams start moving several times faster, that slowness stops being invisible. The people doing the deciding are going to start looking slow, and they didn't get any worse. They just stopped being hidden behind a slower middle.
What gets measured, and what never has
Velocity measures the part of the system we already optimized. Flow Time measures the whole thing, from the moment a customer need is expressed to the moment a customer can use the result. Flow Efficiency, which is active work time as a percentage of total elapsed time, is the number that produces silence in a leadership meeting, because it usually lands somewhere between 15 and 25 percent and nobody in the room believes it until they've drawn the map themselves.
Here's where the AI conversation is repeating the mistake in real time. A lot of companies are still early enough in adoption that their AI strategy amounts to an OKR encouraging people to use AI more. Count the licenses. Count the prompts. Count the training sessions completed. Barry puts adoption on the bottom rung of his outcome ladder for exactly this reason, and I'd say it a little more bluntly: "increase AI usage" is an output goal wearing a strategy costume. It tells you the tool is present in the building. It tells you nothing about whether one decision anywhere got better.
Jeff Gothelf and Josh Seiden have the question that breaks it open. Who is the user, what behavior do we want to change, and by how much? "Use AI more" addresses none of that. It's pure vanity.
Why deciding was always the slow part
But why is the deciding slow to begin with? This is the question I think most AI strategy conversations skip past, and it's the one that matters.
It's slow because in most large organizations, the authority to decide what matters is concentrated in a very small number of people and has never been distributed. Richard Rumelt would go further and say many of those organizations don't have a strategy at all. They have a list of goals with no diagnosis and no guiding policy behind it. When capacity was scarce, that was survivable. Teams only ever got through the top of the list, so the list looked like it was prioritized. Now the whole list can be attempted, and everyone finds out it was never ordered in the first place.
David Marquet's version of the fix is decades old and still the clearest one available: move authority to where the information is, instead of moving information to where the authority is. Marty Cagan arrives at the same place from the product side, arguing that a team is only empowered when it holds three things at once, which are authority over the how, context deep enough to use that authority well, and accountability for outcomes rather than output. Most organizations hand out one of the three, keep the other two at the top, and then wonder why every decision queues in the same place.
So of course the processing tax lands on executives. Every decision was already routed there. AI didn't change the routing. It just increased the traffic.
What to actually do about it
None of what follows is new advice, and I think that's the most interesting thing about it. The recommendations haven't changed in fifteen years. What has changed is the consequence of ignoring them.
Push product authority down into the product managers on the teams. If a product manager can't decide what their team builds next inside an agreed strategy, then every decision travels up and comes back down, and the number of decisions your company can make in a week is capped by the calendars of a handful of executives. That cap was survivable when delivery was the slow part. It won't be.
Measure and scrutinize the full idea-to-customer lifecycle. Not the sprint, not the release. The complete elapsed time from the moment somebody has an idea to the moment a customer can use the result, with every wait state drawn in and an owner named for each one. You cannot improve a stretch of the value stream that nobody has ever put a clock on, and I have never once seen a leadership team look at that number for the first time and stay comfortable.
Turn prioritization into a working process rather than a quarterly event. In a lot of organizations, deciding what matters happens in a big meeting every few months, and everything arriving between meetings waits for the next one. That is a batch size problem, and it is the kind that gets much worse when the teams downstream get faster. If your delivery capacity multiplies and your decision cadence doesn't, the meeting becomes the constraint on the entire company.
Write down the business strategy and the product strategy, including the customer impact you're after. Not the goal list. The actual diagnosis: which problems, for which customers, what behavior are we trying to change, and how will we know it worked. When that exists in writing, hundreds of small decisions can be made without a meeting, because people can tell for themselves whether an idea fits. When it doesn't exist, everything has to be escalated, because nobody downstream has enough context to be confident.
Ask the upstream work to get leaner, the same way you asked the teams to. Smaller features, more experiments, evidence gathered before commitment, validation that happens sooner rather than at the end. The business side has been hearing this advice for years and has mostly been able to set it aside, because delivery was slow enough to absorb the delay. That cover is disappearing.
Four questions to ask before your teams get faster
How long does a feature actually take, from the moment someone asks for it to the moment a customer uses it? And what percentage of that elapsed time is active work? If you don't know, that is your answer, and I'd bet the real number is worse than your estimate.
Where is the longest wait state, and who owns it? Naming an owner is what makes a delay changeable. Nearly every wait state in a large organization is the residue of a decision somebody made years ago that nobody has revisited since.
What is your AI goal measuring? If it counts usage, you're standing on the bottom rung. If it counts decisions that got faster, decisions that got reversed less often, or rework that stopped happening, you're measuring something real.
Who in your organization is allowed to say no? If the honest answer is a very small number of people, you already know exactly where the work is going to back up.
The uncomfortable position
Barry asked whether I was seeing this yet, and my answer was that I'm somewhere earlier in the lifecycle than the companies he's describing. AI is still an experiment in a lot of places, with encouragement to use it and not much declared purpose behind the encouragement.
I've come to think that's the less comfortable position rather than the more comfortable one. A company already struggling to keep up at least knows it has a problem to solve. A company where most people are still treating AI as a slightly smarter search engine has every bit of this ahead of it, arriving on a timeline set by how quickly its own people get good.
And that timeline is shorter than it looks, because this was never only about people writing documents faster. Companies are building agents that augment delivery, and some are running teams where AI agents are pushing code to production. My friend Liz Rettig is speaking about exactly that at our Columbus Business Agility meetup this week, on how to stop estimating and use Kanban principles to forecast your flow, so that more AI-written code can reach production sooner without creating new jams on the way. When delivery capacity jumps by that kind of multiple, the business does not get a grace period to work out how to feed it.
Where this problem actually lives
I want to close by saying that the reason this problem has been so durable is that it doesn't belong to anyone. It sits in the seams. In this post we have touched on five critical pieces of what makes business agility work, and each of those five parts carries its own question.
Strategy and outcomes. Are we clear about what problems we're solving, and how we'll know we've solved them? If the answer is a list of goals, deciding will always be slow, because there is no basis for saying no to anything.
Product thinking and discovery. Are we solving the right problems for real customers in the right ways? This is the work that now has to speed up, through smaller bets and earlier evidence and decisions made closer to the customer.
Flow of work. How much sooner can we turn learning into customer value? This is where the wait states live and where the measurement has to happen. AI changes one segment of this and leaves the rest exactly as it was.
Team and org design. Is our organization structured to enable flow and learning? Water-scrum-fall is a structure, not an accident. The seam between the business and delivery is a decision somebody made about who reports where, and the handoff delay is what that decision costs.
Leadership and culture. Are leaders creating the conditions for ownership and learning to thrive? None of the other four survive without this one. Delegating product authority is a leadership behavior before it is a process change, and it is the piece most likely to quietly revert the moment things get tense.
The interdependence between these five parts is the whole argument of my book, Assembled. Aligned. Adaptive. Five parts of an operating model that only work when they're assembled together, because weakness in any one of them shows up as a symptom somewhere else, and it almost always shows up somewhere that looks like it's the delivery team's fault. AI is about to make that misdiagnosis a great deal more expensive.
Thanks to Barry O'Reilly for the question that started this. His piece on measuring AI outcomes is worth your time.