Lead time

Lead time is the total elapsed time between a request being made and that request being delivered. If a customer places an order at 9am on Monday and receives it at 9am on Thursday, the lead time is three days. The clock runs across every stage in between, including weekends, handoffs, and any period the work sits idle in a queue.

Lead time matters because it measures the experience from the requester point of view. A team can be fast at the actual work and still have a long lead time if requests wait days before anyone starts them. That waiting is invisible on most dashboards but very visible to the customer. Tracking lead time forces the waiting into the open.

Lead time is often confused with cycle time, and the distinction is the whole point. Cycle time starts when work begins and measures only active processing. Lead time starts when the request arrives and includes the wait before work begins. Lead time is always equal to or longer than cycle time, and the gap between the two is queue time you can attack.

Lead time is the difference between two timestamps: when the request arrived and when it was delivered. The headline number is simple. The value comes from breaking that interval into the stages a request passes through, so you can see where the time actually accumulates.

1. 1

   Request timestamp

   The moment the request enters the system. For a support ticket this is when it is logged. For a feature this is when it is committed to. Use the earliest reliable record of the request, not when someone noticed it.

2. 2

   Queue time

   The period the request waits before anyone starts working on it. This stage carries no activity and is often the single largest contributor to lead time. It rarely appears on team dashboards.

3. 3

   Active processing time

   The time spent doing the actual work once it starts. This is the portion most teams instinctively try to optimise, even though it is frequently the smaller share of total lead time.

4. 4

   Handoff and review time

   Time lost between stages as work passes between people or teams, plus any approval or review steps. Each handoff introduces a fresh queue, so multiple handoffs compound delay.

5. 5

   Delivery timestamp

   The moment the request is fulfilled from the requester point of view. Use the point of delivery, not the point of internal completion, so the number reflects what the customer experiences.

A worked example makes the stages concrete. A ticket arrives at 09:00 on day one and waits in a queue until 14:00 on day two before anyone picks it up. That is 29 hours of queue time. The work itself takes four hours, then it waits two hours for review, then it is delivered. Active processing was four hours, but the lead time was over 35 hours. Reporting only the four hours of work would hide almost the entire delay the requester felt.

A metric tree decomposes lead time into the stages a request passes through, then traces each stage back to the team and decision that controls it. This turns a single elapsed-time number into a map of where delay is created.

The first level splits lead time into the phases of the journey: the time before work starts, the time spent working, the time lost to handoffs and reviews, and the time spent waiting to ship. Each phase then breaks down further. Queue time decomposes into intake triage speed, prioritisation cadence, and available capacity. Active processing decomposes into the work itself and any rework caused by quality issues.

This structure makes diagnosis precise. If lead time is climbing, the tree tells you whether the cause is a growing intake queue, slower processing, more rework, or a review bottleneck. Each answer points to a different owner and a different intervention rather than a vague instruction to go faster.

Lead time benchmarks depend heavily on the domain, so the absolute numbers below are reference points rather than universal targets. What matters more than the raw figure is the trend over time and the ratio of active work to total lead time. A low ratio means most of the time is wasted waiting.

A useful companion benchmark is flow efficiency, which is active processing time divided by total lead time. Many teams discover that flow efficiency sits below 15%, meaning work is being worked on for less than a sixth of the time it is in the system. When that ratio is low, the fastest route to a shorter lead time is removing waiting, not adding effort.

Reducing lead time is mostly about removing waiting rather than working harder. Because queue time and handoff time usually dominate, the highest-impact changes target the gaps between stages rather than the stages themselves.

The metric tree approach to improving lead time starts by finding the branch with the largest share of total time, not the branch that feels slowest. If queue time is 70% of lead time, no amount of faster processing will help much. The tree settles that argument with evidence.

KPI Tree lets you connect each branch of the lead time tree to the team that owns it, with RACI ownership making the accountable owner explicit on every node. The intake owner is accountable for queue time. The delivery team owns processing and rework. The release process owner holds batch size and schedule. When lead time moves, the change is pushed to the accountable owner for that branch rather than landing on a shared dashboard nobody reads, so the team responsible sees it first and acts on it.

1. 1

   Measuring from work-start instead of request

   Starting the clock when the team picks up the work, rather than when the request arrived, hides queue time. That queue time is usually the largest part of the delay, so this single error makes lead time look far better than the requester experience.

2. 2

   Confusing lead time with cycle time

   Cycle time measures only active work. Lead time includes the wait before work begins. Reporting cycle time and calling it lead time understates how long requests actually take and removes the pressure to fix queues.

3. 3

   Using an average and ignoring the spread

   A mean hides the long tail. Two teams with the same average can have very different experiences if one has a wide spread. Track the median and a high percentile, such as the 85th, so outliers stay visible.

4. 4

   Stopping the clock at internal completion

   Marking a request done when the work finishes internally, rather than when it reaches the requester, drops delivery and release wait from the number. The requester only counts the moment it actually arrives.