We’re in a medium-sized tech services company. It is a quarterly review meeting. The management team is reviewing the delivery milestones as committed. When they get to the release calendar, the CEO asks why it’s the same.
Indeed, a few months earlier, upon a perfect slide deck from the VP of Engineering and the product leaders, the CEO committed to another investment budget for AI. That deck was about AI adoption. The shared benefit highlighted was everyone using it, with an implicit delivery performance improvement as a consequence. There was no more precision, but everyone saw the need to go all in on AI.
“Why is the release calendar the same?” The Engineering team, who owns delivery accountability there, stays silent.
You are not the only one surprised by this silence. Right now, across the industry, delivery calendars are not moving even as AI adoption explodes. In fact, that silence is about measuring the wrong thing.
Your numbers are blind
Since AI tools were introduced, you know tech teams are faster. You see developers producing more code faster than usual. You can even feel it during the standups. But the KPIs on the management board don’t reflect that. This feeling might be misleading you. In controlled trials, experienced developers systematically overestimate how much AI speeds them up. This gap between perceived and measured speedup is real.
That speed leaked out before it reached delivery. Somewhere between code done and applications running in production, a queue absorbed every hour the AI models saved you.
Another reason you cannot answer the CEO question is that your adoption numbers are structurally blind. They measure the purchase.
The answer lives in the flow.
What I measured
I worked with two project managers managing about twenty projects. When we started, 24% of their projects landed on time. They had 38 defects a month, and the customer satisfaction was 5.5 out of 10. Three months later, they reached 55% of projects on time (short of the 60% target we had set), 19 defects a month, and 9.4 satisfaction.
The number I want to highlight is completed projects: 9 at the beginning and 27 at the end, with no additional headcount. This is delivery, and the kind of answer management expects when investing in AI.
That story predates AI rollout on that client, and this is exactly the point. AI changed the speed of input into the system. It did not change where the answer lives for you. That answer is still a pace number at the exit door, and you can measure it anytime. If you have that number for your own teams today, the CEO’s question above would take you thirty seconds.
Why the standard answer fails
Adoption is a purchasing metric, while delivery is a flow one. So your initial numbers, largely driven by your AI vendors, were measuring the wrong thing. Vendors typically show you licenses purchased and code generated. But none of those tells you whether your customer got value faster.
You may object, saying that a well-structured organization would have requested a strong business case before investing in AI. For many organizations, it was the rush. AI was there. Even if the business applications were not clear and still evolving, it was critical to be in, to not miss the wave. Enterprises are in ecosystems. Between clients and providers, there was no way of being left behind.
The countermeasure
Pick one value stream from request to production. Baseline its end-to-end lead time and quality. You can also consider the delivery pace if that makes sense in your context.
Somewhere in that stream, you introduce AI and create working steps that shorten lead time.
Then walk the stream to find the queue where the speed pooled. It could be anything: a review, approval, waiting for an input, a handoff to another team, a testing window not opened at the right time, etc. So the time AI saved in the upstream just sits there, converted into waiting work. You have to put a number on it and make it visible to everyone. That number is your leverage to reduce the lead time you baselined at the beginning. Also, keep an eye on quality to ensure you are not losing any additional value for clients.
At the end of that improvement loop, you have a number for AI ROI. You can share a precise lead-time improvement since the AI rollout and be explicit about what you cleared to get there. You now have a better answer than silence.
The micro step for this week
Take your last 10 completed development tasks or features. For each of them, collect the real lead time between “code done” and the deployment in production. Then focus on the waste in that lead time.
Most teams I asked never measured it. Many found the code wasn’t the slow part.
One question
Where did your AI speed pool? Reply with the queue: review, approval, handoff, or somewhere else. I read every answer, and the best ones will feed a future issue.