Lead Time

For a long time the engineering team and the people making requests described the same piece of work with different numbers. Engineering said two days. The person who asked got the result three weeks later. Neither of them was lying. Two days was the time somebody spent working on it; three weeks included every day the request sat somewhere in a list.

Promises broke on that gap over and over. Sales would tell a customer it would land in two weeks, which was engineering's two days with padding on top, while the request itself was queued behind twelve others. A month in, the customer would call, engineering would say it had not been started yet, and sales had no idea which part they had misheard.

Lead time exists to fill in the missing piece. It doesn't measure how fast anyone writes code. It measures the whole wait the person who asked went through. Changing the span being measured changes what the team can see: the moment queue time lands inside the number, the length of the queue becomes visible for the first time.

Take the gap between the moment a request is accepted and the moment it is finished, measure it per item, then look at many items together as a distribution.

The team has to agree on where accepted and finished sit. On a kanban board, accepted is when the card first appears on the board and finished is when it reaches the last column. If people apply that differently, the same item's lead time can come out twice as long. The usual fork is whether the clock starts when the request arrives in chat or when somebody copies it onto a card.

The calculation has three steps.

1. Collect the accepted and finished timestamps for recently completed items. Around thirty is enough to see a shape.
2. Take the difference for each item. Decide up front whether you are counting calendar days or working days and hold to it. For promising a date to a customer, calendar days including weekends is the honest unit.
3. Sort the values from smallest to largest and read the median and the 85th percentile. The 85th percentile is the value that 85 out of 100 items finished within.

Averages get avoided because one item can drag the whole number. If twenty items mostly finished inside a week but one dragged on for two months while its owner was away, the average jumps to 12 days. The median of those same twenty items is 6 days and the 85th percentile is 14, which turns into "usually about a week, three weeks at the outside" for the person asking.

Mixing kinds of work together drains the number of meaning. A typo fix and a payments integration start from different places, so split by type and read each distribution on its own.

There is no number of days that counts as good. A copy change and a billing integration cannot share a yardstick, and requests reach every team through different routes. Two things get checked instead.

The first is spread. Compare the 85th percentile against the median; inside a factor of two, the number is usable for promises. A team with a median of 6 days and an 85th percentile of 10 can say "within ten days" and mostly keep it. A team with the same median of 6 and an 85th percentile of 25 will be wrong about half the time whatever date it gives. It's the difference between a thermometer being slightly off and a thermometer giving a different reading every time you use it.

The second is how much of that time was spent waiting. Measure cycle time alongside it — the stretch from when someone actually started working to when the item finished — and compare the two. A lead time of 9 days against a cycle time of 2 means seven days in a queue with nobody touching the work. Hiring into a team like that shortens cycle time a little and leaves lead time almost where it was, because what needs fixing is how work is queued rather than how fast it gets done.

The usual way to shorten the queue is a work in progress limit, a cap on how many cards can sit in one column at once. With a cap in place, new requests cannot simply be accepted and stacked, and whatever is already started clears first. Which column the queue forms in shows up on a cumulative flow diagram as a band that keeps thickening. That column is the bottleneck.

"What lead time should I quote on this? I need to give the customer a date."

Asking how many days from request to delivery, not how many days of engineering work.

"Median is six days but the 85th percentile is three weeks. Let's just say three weeks."

Half of them finish in six days, but the spread is wide enough to quote the safe number.

"Lead time went up but cycle time is flat."

Nobody got slower. The queue in front of the work got longer.

At Pagedeck, Sofia checks this number before she gives a customer a date. She used to ask Theo how many days something would take and pass his answer straight on, but that answer counted only hands-on time and missed by half. Now she reads the distribution by request type that Mia puts together each quarter. Bug fixes run a median of 2 days and an 85th percentile of 5; small feature requests run a median of 8 days and an 85th percentile of three weeks.

The number doesn't make the promise. After Sofia says "usually a week, three at the outside," whether that item gets pulled forward is something Mia settles against everything else in the queue.

The most common mistake is reading lead time as engineering time. Engineering keeps the number, so it looks like a statement about engineering. But the value contains every day the request waited for review, waited for a prioritization meeting, and waited for something else to finish. Read it as build time and 9 days turns into "why nine days for two days of work," and the team responds by redefining the metric to count hands-on time only. At that point the number drifts away from what the customer actually experienced.

Assuming it comes down by working faster is the other one. It measures time, so it looks like a speed problem. But in a team where waiting is seventy percent of the total, halving hands-on time moves 9 days to 8. Halving the number of things the team holds at once shortens the queue and moves 9 days to 5. It is the kind of number that barely responds to longer hours and responds well to accepting less at once.