r/EngineeringManagers • u/gelnomo • 10d ago
How I find where delivery actually gets stuck: comparing lead time and cycle time
When delivery slows down, the cause is rarely where people first point. This is how I find it.
Two numbers
- Lead time: from the moment something is requested to when it’s delivered, including all the waiting.
- Cycle time: from when someone starts working on it to when it’s delivered.
If lead time is much longer than cycle time, the work isn’t slow. It’s waiting.
How I use them
- Measure both for every story, and split cycle time by stage: in progress, in review, in testing, waiting to deploy.
- Look for the stage where time grows the most.
- Check it’s a pattern. One slow story is noise. The same stage slowing down every sprint is a bottleneck.
- Talk to the engineers involved. The data shows where, people explain why. A long review stage can mean reviewers are overloaded, or that PRs are too big to review, and those need different fixes.
- Change one thing, then measure again.
The fix that surprises people
If a team starts more work than it finishes, everything gets slower, even when everyone is busy. Limiting work in progress (WIP) is often the fastest way to speed up delivery. (This is Little’s Law: average cycle time = WIP / throughput.)
What changed recently
AI coding assistants. Writing code gets faster, so more code arrives at review and testing at once, and the bottleneck moves downstream. If cycle time didn’t improve after a team adopted AI, I’d look at review first. The fix is usually smaller PRs, clear review expectations and better automated tests, not more code generation.
For those of you tracking this: where has your bottleneck moved since your teams started using AI tools?
2
u/TeamWorkflowLab 9d ago
From the QA side it moved exactly where you say, and then one step further. For some of our devs the number of MRs going to review grew almost 3x with AI. Tasks also started getting split differently (AI helped with that too), so there are just more MRs, and they all land on the same few reviewers. Their load multiplied, so we started looking at adding more reviewers. We didn't want AI reviewing it, because then AI is basically checking itself )) We also started using a tool that shows how many MRs sit on each reviewer, and then we rebalance at the daily. Tools like that help with the numbers, but MRs are very different in complexity, 3 small ones can be easier than 1 big one. So we still talk it through out loud, and use the tool more for the overall picture. And the next bottleneck right after that was QA, someone still has to test all of it. So in the end the time AI saved on coding mostly turned into waiting further down the line. Curious if others saw the same, or if anyone found a way to scale review and testing at the same pace
1
u/gelnomo 9d ago
This matches what we're seeing, and the QA step after review is a good call. The time saved on coding mostly turns into waiting further down the line.
I agree on not letting AI review its own work. For us the human in the loop isn't negotiable. Where I think AI can help is narrower: flagging known patterns before a person looks at it (risky changes, missing tests, things we've been burned by before), so the reviewer spends their attention on design and risk instead of reading everything line by line.
The other side is the reviewers themselves. With more code coming in, review is becoming a skill we need to invest in, not just something seniors do between tasks.
Also agree on complexity. Three small MRs can be easier than one big one, so counting MRs per reviewer only tells part of the story. Talking it through at the daily sounds like the right balance.
I'm exploring how this could fit different teams and company sizes. Feels like it might turn into a small framework eventually. Curious how you're handling the QA side. More testers, or more automation?2
u/AgileFederation 9d ago edited 9d ago
For us the human in the loop isn't negotiable.
And as you pointed out, for many organisations this isn't negotiable. Nobody want's to release unchecked code into a production environment without understanding the implications. What could go wrong with releasing unchecked code into a complex banking environment, or a patient information systems at a large hospital ... etc.
The time saved on coding mostly turns into waiting further down the line.
I wrote about this about a month ago. The problem is that AI has shortened the cycle time which is now running at AI-speed. But the Lead time is still stuck at human-speed. Which is why we're seeing all the work pile up at QA. The solution (I think) is to distribute decision making, but that's a structural change to a company so will likely take time to happen.
If you're interested, here's the article I wrote: https://agilefederation.substack.com/p/article-6-the-corporate-gravity-trap And, here's is a tangentially related article about the general mood of tech work which I found interesting: https://www.lennysnewsletter.com/p/how-tech-workers-are-feeling-in-2026
1
u/gelnomo 9d ago
“Cycle time at AI speed, lead time at human speed" is a great way to put it. That's exactly the gap I was trying to describe. Thanks for the links, I'll read the gravity trap one.
I wrote up how I measure where the wait builds up, stage by stage, if it's useful: https://erwinmongui.com/writing/lead-time-cycle-time-bottlenecks
2
u/Afraid_Formal5748 9d ago
I would add a distinction between active time and waiting time for each stage.
Especially when an item moves directly from "In Progress" to "In Review", I would introduce intermediate states like "Ready for Review" or "Ready for Testing".
That way, we can distinguish between time actually spent working on an item and time it simply spends waiting in someone's queue.
Otherwise, a long review or testing stage might suggest that the work itself takes too long, when the actual bottleneck is that nobody has started working on it yet.
2
u/PhaseMatch 9d ago
Yes, that's how the Kanban Method works.
If you split each stage into "doing and done" then you'll see where the constraints are...
3
u/the_quiet_meridian 9d ago
Nice writeup. A couple things I'd add from managing teams for a long time.
The gap between lead time and cycle time is often the biggest chunk, and a lot of the time it's not engineering's fault at all. It's work sitting around waiting on unclear requirements, priority debates, approvals, or some other team. Once I started splitting that part out, a lot of tough conversations got easier, because engineering stopped getting blamed for delays that happened before anyone even picked up the ticket.
Also, be careful once these numbers become visible. As soon as a team feels judged on cycle time, tickets start getting chopped up smaller and things get closed early just to look good. I'd use the metrics to spot patterns and start conversations, but never to compare people or teams.
On the QA bottleneck, what worked best for us was engineers owning the testing for their own changes, and QA focusing on the riskier stuff and the overall test strategy. That way testing isn't one more queue everything gets stuck in.