Lead time

Lead time is the total duration from the moment a request enters your system until it's delivered. In product development, this typically means the time from when a feature is requested or a bug is reported until it's released to customers. Lead time encompasses everything - the time work sits waiting in queues, the time it's actively being developed, the time it waits for review and testing, and the time until deployment.

Why it matters

Lead time is what customers experience. They don't care how much active work you did; they care how long they waited. A feature that takes two days of development but six weeks of lead time still feels like a six-week wait.

Long lead times damage competitiveness. When you can't respond quickly to market changes, customer requests, or competitive moves, you fall behind. Opportunities pass while work crawls through your system.

For product managers, lead time is a crucial health metric. Short lead times enable faster learning cycles, quicker response to customer feedback, and more adaptive strategy. Long lead times mean you're always reacting to yesterday's information while competitors act on today's.

Lead time vs. cycle time

These terms are often confused but measure different things.

Lead time measures the full customer-visible duration: from request to delivery. It includes all waiting time and all work time.

Cycle time measures the duration from when work starts until it completes. It excludes the time a request waited before work began.

The difference between lead time and cycle time reveals queue time - how long requests wait before anyone touches them. If lead time is six weeks but cycle time is one week, five weeks are spent waiting.

Both metrics matter, but they drive different actions. Improving cycle time means working faster or more efficiently. Improving lead time often means reducing waiting time - which may require changing processes, priorities, or capacity allocation.

Components of lead time

Understanding where lead time accumulates helps identify improvement opportunities.

Queue time is waiting for work to begin. Items sit in backlogs, await prioritization, or wait for capacity. In many organizations, queue time dominates lead time - work waits far longer than it's worked on.

Process time is active work: designing, building, testing. This is what teams typically focus on improving, though it's often a smaller component of lead time than they assume.

Wait time between stages occurs at handoffs. Work waits for review, waits for QA, waits for deployment windows. These transitions often introduce significant delays.

Blocked time happens when work cannot proceed due to dependencies, questions, or obstacles. Blocked work sits consuming no effort but extending lead time.

Mapping these components reveals where time actually goes. The results often surprise teams who assume their slow delivery is due to slow work, when it's actually due to slow waiting.

Measuring lead time

Accurate measurement requires clear definitions.

Define the start point. When does lead time begin? When an idea is first proposed? When it's formally requested? When it enters the backlog? Different definitions yield different measurements. Choose one that represents when the "customer" (internal or external) begins waiting.

Define the end point. When does lead time end? When code is merged? When it's deployed to production? When customers can actually use it? Again, choose what represents delivery from the customer's perspective.

Measure consistently. Whatever definitions you choose, apply them consistently. Changing definitions makes trends impossible to track.

Track individual items. Lead time varies by item. Tracking distributions - median, percentiles, outliers - provides more insight than averages alone. A team with an average lead time of two weeks might have some items taking one day and others taking two months.

Improving lead time

Reducing lead time requires addressing its various components.

Reduce batch sizes. Large work items take longer to complete and spend more time waiting at each stage. Breaking work into smaller pieces reduces lead time even if total effort stays the same.

Limit work in progress. Starting fewer things means finishing things faster. WIP limits force focus and reduce queue time by preventing work from accumulating at stages.

Eliminate handoffs. Each handoff introduces waiting time. Cross-functional teams that can take work from start to finish without external dependencies have shorter lead times than teams requiring multiple handoffs.

Improve flow efficiency. Flow efficiency is active time divided by lead time. A 10% flow efficiency means work is sitting idle 90% of the time. Identifying and addressing the causes of idle time dramatically improves lead time.

Reduce blocked time. Track why work gets blocked. Common causes include dependencies on other teams, unclear requirements, and waiting for decisions. Addressing systemic blockers pays off across many items.

Automate deployment. If deployment requires manual processes, scheduled windows, or long regression cycles, that's lead time waiting to be reduced. Continuous deployment practices can reduce deployment lead time from weeks to hours.

Lead time and predictability

Lead time distributions enable delivery prediction.

If you know that 85% of your items complete within three weeks, you can tell stakeholders with confidence that a new request will likely be done in three weeks. This probabilistic approach is more honest and more useful than point estimates that imply false precision.

Consistent lead times also enable better planning. When lead time is predictable, you can make commitments based on data rather than hope. When lead time is highly variable, the root causes of that variability deserve investigation.

Lead time by work type

Different work types often have different lead times.

Bugs might have shorter lead times due to prioritization urgency and smaller scope.

Small features might have moderate lead times - quick to develop but still subject to standard review and release processes.

Large features have longer lead times simply due to scope, plus they often hit more dependencies and require more coordination.

Technical debt might have long lead times if it's consistently deprioritized, or short lead times if the team has dedicated capacity.

Tracking lead time by category reveals where the process works well and where it struggles. It also helps set appropriate expectations - stakeholders should know that a large initiative will take longer than a bug fix.

Organizational implications

Lead time isn't just a team metric; it reflects organizational structure and priorities.

Dependency-heavy organizations have long lead times because work constantly waits on other teams. Restructuring to reduce dependencies - through team topology changes or architectural decoupling - can dramatically improve lead time.

Approval-heavy organizations accumulate wait time at each checkpoint. Streamlining approvals or delegating authority reduces these delays.

Low-investment organizations have long queues because capacity can't keep up with demand. Sometimes the only solution is more capacity or fewer commitments.

Interrupt-driven cultures have long lead times because work constantly gets paused for urgent requests. Protecting focus time and managing interruption expectations helps.

Lead time improvement often requires changes beyond the team level. Product managers advocating for lead time reduction may need to address organizational factors, not just team practices.

The business case for lead time

Shorter lead times have concrete business value.

Faster time to value. Features generate revenue or solve problems sooner.

Faster learning. Quicker delivery means faster feedback and faster iteration.

Competitive advantage. Organizations that respond quickly outmaneuver slower competitors.

Reduced risk. Shorter lead times mean smaller batches, which means lower stakes if something goes wrong.

Better predictability. Consistent short lead times enable reliable commitments.

Improved morale. Teams that finish things feel more productive than teams with endless work in progress.

These benefits compound. Organizations that invest in lead time reduction build a sustainable advantage that competitors with long lead times struggle to match.