Cycle Time vs Lead Time: What Each One Actually Tells You

Introduction

A support lead once told an engineering manager that fixes were taking a month. The engineering manager pulled up the board and showed that the median fix took under three days. Both of them were right, and they spent the next twenty minutes arguing because neither knew that.

The support lead was measuring from the moment a customer reported the problem. The engineering manager was measuring from the moment someone picked the ticket up. The twenty-seven days in between were invisible to the board and invisible to the argument.

That gap is what this article is about. Most explanations of cycle time and lead time stop at the definitions, which are easy. The useful part is what the distance between them tells you.

What Is the Difference Between Cycle Time and Lead Time?

Lead time measures from the moment a request arrives to the moment it is delivered. Cycle time measures from the moment work actually starts on it to the moment it is delivered. Lead time is what the customer experiences. Cycle time is what the team experiences. Lead time is always the larger of the two, and the difference is time the request spent waiting to be picked up.

Both are measured per item and reported as a distribution, not an average. Two items finished in two days and one in forty does not mean the team is a "fifteen day team". It means most work is fast and something about the third item was different.

Why Teams Conflate Them

The conflation is mostly a tooling artefact. Many systems start the clock when a card is created, and cards get created when someone decides to work on the thing rather than when the request arrived. Under that setup the tool reports lead time and calls it cycle time, or reports cycle time and calls it lead time, and nobody notices because there is only one number.

The second reason is that measuring true lead time requires you to capture the request before you have decided to do it. That means an intake list, an ideas inbox, a bug queue, something that holds work you have not committed to. Teams without that surface cannot measure lead time at all, because the request simply does not exist in the system until work begins. See building an ideas pipeline for the practical version of that.

Reading the Gap

Put the two numbers side by side and the diagnosis writes itself.

Lead time 30 days, cycle time 3 days

Ninety percent of the customer's wait is queueing. Your engineering process is not the problem and making it faster would change almost nothing. The problem is intake: too much accepted, too little prioritised, or a triage step that only happens when someone remembers. Fixing this is a prioritisation and commitment problem, and it is usually cheaper to fix than an engineering one.

Lead time 10 days, cycle time 8 days

Queueing is short and the work itself is slow. Now you look at what happens between start and finish, and the answer is nearly always waiting rather than working. Review queues, handoffs, a test environment that is occupied. See flow efficiency, which measures exactly this.

Both numbers stable, both acceptable

Leave it alone and go measure something else. A stable, adequate delivery time is not a problem that needs a project.

Cycle time stable, lead time climbing

The most common pattern in a growing product, and the most commonly misdiagnosed. The team is performing exactly as well as it did last quarter. Demand has grown and nobody adjusted what gets accepted. Hiring will not fix this, and telling the team to go faster will only produce a team that feels blamed for a queue it does not control.

Measuring Both Without a Formal Workflow

You do not need stages, swimlanes or a workflow designer. You need two timestamps per item:

• Requested: when the item first entered the system in any form, including as a raw idea or an unread bug report.
• Started: when someone moved it to in progress.
• Finished: when it reached done.

Lead time is finished minus requested. Cycle time is finished minus started. That is the whole measurement. If your tool records status transitions, you already have all three and can compute both retroactively for the last six months without asking anyone to do anything differently.

One judgement call: items that are started, paused, and restarted. The honest treatment is to keep the clock running through the pause, because the customer's wait did not pause. Teams that subtract paused time end up with a flattering number that predicts nothing. If paused time is large enough that this bothers you, that itself is the finding.

Which One to Report to Whom

Report lead time outward and cycle time inward.

A customer, a client or an executive asking "how long does this take?" is asking about lead time, whether or not they use the term. Answering with cycle time is technically accurate and reads as evasive the moment they compare it against their own experience of waiting.

A team asking "are we getting better?" wants cycle time, because it is the part they control. Holding a team accountable for lead time when they do not control intake is a good way to teach them that the metrics are political. For the wider version of this argument, see measuring team productivity.

How FlowBoard Shows This

FlowBoard computes cycle time and lead time from status transitions on work you already track. Because ideas and bug reports live in the system before anyone commits to them, the requested timestamp is real rather than reconstructed, which is the part most setups get wrong.

Both trends are visible together, which is the only way the gap between them becomes obvious. Reported separately on different screens, the most useful number in this article stays hidden.

What to Do This Week

Pull both numbers for the last quarter. If the gap is larger than the cycle time itself, stop optimising engineering and go look at intake. That single comparison redirects more improvement effort than any other measurement on the flow metrics guide.

Then read throughput, which is the other half of any conversation about delivery speed, and work item age, which tells you about the items still open rather than the ones already finished.