Flow: Lead Time and Cycle Time
Measuring how long things take rather than how many were done. The approach that works where units are not comparable.
Flow measurement asks how long work takes to pass through. It needs no comparable unit, which makes it the most broadly applicable technique in this subject.
The process issue in “Flow: Lead Time and Cycle Time” is easier to diagnose when effort can be connected to projects without confusing activity with value. Used for task switching cost, visit the company website can add time and workflow context, while the process outcome remains the source of truth for whether the system improved.
The two measures
Lead time: from the request being made to it being delivered. What the customer experiences.
For an independent perspective related to “Flow: Lead Time and Cycle Time”, consult the Microsoft WorkLab; it offers a useful external check on definitions, governance and the assumptions built into a proposed measure.
Cycle time: from work actually starting to finishing. What the team experiences.
The gap between them is waiting, and in most organisations it is the larger of the two.
Why the gap matters most
A team can only compress cycle time by working faster.
Lead time can be compressed by removing queues, which is usually cheaper and larger.
Which means measuring both tells you whether to improve the work or the system around it, and the answer is usually the second.
What flow measurement does not need
Comparable units. A long job and a short job each have their own duration.
An agreed definition of output quality.
Individual attribution.
Which is why it transfers to professional work where counting fails, as the unit note argues.
Reading the distribution, not the average
Lead times are rarely symmetrical: most items quick, a tail of slow ones.
The average is dragged by the tail and describes nothing.
Report the median and a high percentile — the eighty-fifth or the ninety-fifth — which together describe the experience, including for the people who waited longest.
What it reveals
Where items sit waiting, if you record the stages.
Whether the tail is growing, which is the early warning of a developing problem.
And the effect of a change, quickly, because flow responds faster than volume.
Starting without tooling
Record two timestamps per item: requested and delivered.
Most systems already have both.
A month of data gives you a distribution, and that is enough to start, with stage-level detail added later if the distribution raises a question.
The gaming shape
Flow can be gamed by starting items late so the clock begins later, or by splitting work.
Which is why the request timestamp should be when the requester asked, not when the team accepted — a distinction that matters and is frequently configured the wrong way.
Where it works less well
Continuous work with no discrete items: monitoring, availability, support presence.
Very long horizons, where the feedback arrives too slowly to steer by.
Both have their own notes, and in the second case flow is still worth recording even if it cannot be managed by.
What to check
Do you record when a request was made, or when the team accepted it?
Do you report median and a high percentile, or an average?
How much of your lead time is waiting?
And is the tail growing?