Cycle Time vs Lead Time: What Each One Hides

TL;DR: Lead time is the customer's clock: request to delivery. Cycle time is the team's clock: work started to work shipped. Lead time hides where the time goes; cycle time hides the queue of work that hasn't started; both, as averages, hide the tail where the risk lives. The move that actually finds your bottleneck is decomposing cycle time by stage - coding, pickup, review, merge, deploy - because the widest slice is almost always waiting, and waiting is cheap to fix.

Two teams can both say "our lead time is three days" and be describing completely different realities - one measuring from the first commit, one from the Jira ticket's creation, one (nobody, in practice) from when the customer actually asked. These metrics get used interchangeably in exactly the meetings where the difference matters most. So: definitions first, failure modes second, and then the version of the metric that's actually actionable.

What is lead time?

Lead time comes from lean manufacturing: the elapsed time from request to delivery, the clock a customer experiences. Order the car, receive the car; everything between is lead time, no matter whose fault the waiting was.

Software borrowed the term and then, usefully but confusingly, narrowed it. DORA's "lead time for changes" (one of the four keys) starts the clock at the commit and stops it at running in production. In the 2024 DORA bands, elite is under a day, high is a day to a week, medium a week to a month, low one to six months.

Both definitions are legitimate. What's not legitimate is comparing your commit-to-production number against someone's request-to-delivery number and concluding anything at all.

What is cycle time?

Cycle time starts when work actually begins and stops when it ships - the team's clock rather than the customer's. In practice, most engineering tools operationalize "work begins" as the first commit. LinearB's 2026 benchmarks, built on 8.1 million+ PRs from 4,800+ teams, measure first commit to production at p75, and band it:

Band	Cycle time (first commit → production, p75)
Elite	under 25 hours
Good	25-72 hours
Fair	73-161 hours
Needs focus	over 161 hours

Note the fine print, because it's load-bearing: those are p75 figures under one vendor's definition. A tool that measures PR-open to merge at the median will produce a much smaller number for the same team. Benchmarks are only comparable when the definition and percentile match. Quote the definition every time you quote the number.

What lead time hides

Where the time went. Lead time is one aggregate number over four or five very different activities. A 6-day lead time tells you that you have a problem; it refuses to say whether the problem is slow coding, a review queue, a deploy train, or a codebase where technical debt turns every two-line fix into archaeology. It's a thermometer, not an X-ray.

Everything before the first commit. The commit-based definition starts the clock when an engineer starts typing, so the three weeks a request sat in the backlog, in refinement, in "waiting for design" never appear. A team can post elite commit-to-production lead time while customers wait a quarter. That's not lying, exactly. It's measuring the part of the river you own and calling it the river.

The tail. Published bands are aggregates; your risk is in your distribution. A healthy median with a rotten p90 means most changes flow and a meaningful minority get stuck. The stuck ones are disproportionately the risky, expensive ones. Averages are where outliers go to hide.

What cycle time hides

The queue of unstarted work. Cycle time deliberately excludes the waiting before work begins. That makes it precise, and it makes it blind. A team drowning in WIP can show improving cycle time while its backlog ages into irrelevance. Little's law is undefeated: start more than you finish, and the invisible queue grows regardless of how fast each item moves once started.

Batch-size laundering. Make cycle time a target and work gets sliced into tickets sized to flatter the chart. The number improves; nothing ships sooner. Any cycle-time win should be validated against deployment frequency and batch size before anyone celebrates.

Who's actually waiting on whom. As a single number, cycle time attributes delay to nobody, which in practice means the author's "it's been in review for three days" and the reviewer's "it was ready yesterday" both survive the retro. Only decomposition settles it.

How to decompose cycle time by stage

This is the version of the metric worth operating on. Split every change's journey into stages and measure each:

1. Coding: first commit to ready-for-review. Long here usually means oversized scope or a codebase that fights back.
2. Pickup: ready-for-review to first reviewer action. In most teams this is the widest slice and the least examined; pickup time has published bands of its own (elite under an hour), and it's the cheapest stage to fix because nothing about the work changes. The queue just has to move.
3. Review: first action to approval. Google's study of ~9 million reviewed changes puts the overall median for the entire review process under 4 hours. If your review stage runs to days, the gap is size and waiting rather than reading speed. The SmartBear/Cisco research says why: reviewers are effective on 200-400 lines at a time, and effectiveness collapses past that. The fix lives in reducing PR review time.
4. Merge: approval to merged. Long here is CI flakiness or merge-courage deficit.
5. Deploy: merged to production. Long here is a release-train problem, and no amount of review discipline will save you from a train that leaves monthly.

The punchline of decomposition, in team after team: the work stages are fine and the waiting stages are the problem. That's genuinely good news.

Waiting is the one thing in a delivery pipeline you can remove without asking anyone to work faster, review shallower, or test less.

Lead time tells you how it feels from outside. Cycle time tells you how it feels from inside. The stage breakdown tells you what to fix - and of the three, only the last one ever shortened anything. (The stage-matched fix playbook is its own article: how to reduce cycle time.) For where this sits in the bigger scoreboard, start at the delivery-metrics hub.