If you can only watch two numbers in your operation, watch lead time and cycle time. They sound interchangeable in casual conversation, and they get used interchangeably on most dashboards, which is why most dashboards quietly mislead. They measure different things, they respond to different interventions, and confusing them is the reason a process metric can look healthy while the customer is complaining.
This is a working guide. We'll define each, show why they diverge, and walk through what each one actually tells you to do.
The definitions, said plainly
Imagine a customer raising a support request at 9:00 on Monday. The team picks it up at 14:00 on Tuesday, works on it for 90 minutes, and resolves it at 15:30 on Tuesday.
- Lead time is the elapsed time from the customer raising the request to it being resolved. In this example, roughly 30.5 hours.
- Cycle time is the time the team actually spent working on it. In this example, 90 minutes.
Lead time is what the customer experiences. Cycle time is what your team controls directly. The gap between the two is queue time — and the queue time is almost always where the real opportunity sits.
Why the two diverge
Healthy operations should see lead time only modestly longer than cycle time. When the gap is wide, the work is sitting somewhere — waiting for triage, waiting for approval, waiting for a handoff, waiting for the right person to come back from leave.
Specific patterns that widen the gap:
- Batching.Work is processed in scheduled batches (“we triage on Mondays”) rather than continuously. Average queue time = half the batch interval.
- Specialist bottlenecks. Only one or two people can do a specific step. Their queue is permanent.
- Approval chains. Each approver adds a queue. Three sequential approvers can add a week of lead time without adding ten minutes of cycle time.
- Cross-team handoffs.The request moves from one team's backlog to another's and joins the back of a new queue.
None of these show up if you only watch cycle time. The team is working as fast as it ever did. The customer is waiting longer.
Why most dashboards quietly show only one
Most off-the-shelf reporting picks whichever number is easiest to compute. In Jira and Asana, that's usually cycle time (“time in progress”). In help desks, it's usually lead time (“time to resolution”). Neither tool prompts you to look at both.
The result is predictable. Engineering leaders look at sprint cycle times and conclude things are fine. Product leaders hear from customers that “everything takes forever.” Both are correct about the data they have. The data is incomplete.
How to act on each one
If cycle time is high
The work itself is taking too long once it's started. Interventions live inside the team:
- Skill gaps — does the right person have the right tools?
- Tooling friction — are they fighting the system to do the work?
- Scope creep — does the work as defined match the work as performed?
- Context switching — are people doing six things at once?
These are training, tooling, and discipline questions. Process re-design doesn't usually help.
If lead time is high but cycle time is fine
The work is sitting in queues. Interventions live between teams, not inside them:
- Reduce batch sizes. Daily triage beats weekly triage; continuous triage beats both.
- Add capacity at the specific bottleneck — and only there. Doubling team headcount won't help if the constraint is one approver.
- Collapse approval chains. Default-approve below a threshold; escalate only when the threshold is breached.
- Reduce handoffs. Cross-functional teams beat cross-functional processes.
This is where the highest-leverage interventions usually live. They're also the ones most resisted, because they cross organisational boundaries.
The percentile question
Averages on either metric are misleading. The customer experience that hurts most is the long tail — the request that took six weeks when most take two days. Always report at least median (P50) and P85 or P90. The gap between the two tells you whether you have a consistency problem or just a few outliers.
- P50 high, P90 close to P50: the whole process is slow and predictable. Re-design.
- P50 fine, P90 much higher: a small number of cases are getting stuck. Investigate the outliers individually.
- P50 fine, P90 fine, customers still complaining: you're measuring the wrong work, or the boundaries of your process don't match the customer's experience.
One trap to avoid: defining the start time conveniently
We've seen teams reduce lead time by 40% in one quarter without changing anything other than when the clock started. They moved the “start” from when the customer raised the request to when the team accepted it into their backlog — excluding the time the request sat in the inbox waiting for triage.
The metric improved. The customer experience didn't. If you catch this happening, you've also caught a cultural problem worth addressing.
The honest bottom line
Track both. Pair lead time and cycle time on the same dashboard, with both medians and tail percentiles. The gap between the two is the most useful number you're probably not watching — it tells you, almost without ambiguity, where to look next.
And whenever a stakeholder asks “how fast is the team?”, push back on the question. The team isn't slow. The process the team sits inside is slow. The two interventions you'd run are completely different.