liveBook · Manning

Lead time

As explained in "Looks Good to Me"

The elapsed time from committing a code change until it successfully runs in production.

Lead time is the elapsed time from committing code until it successfully reaches and runs in production. It is one of the four DORA metrics used to assess delivery performance. section 4.4.2 section 2.5

Use lead time to decide whether delivery or code review needs attention:

  • A low-performing team has a lead time of one to six months. section 4.4.2
  • A medium-performing team has a lead time of one week to one month. section 4.4.2
  • If lead time is slow, inspect code reviews and other deployment-pipeline bottlenecks rather than assuming reviews are the cause. section 4.4.2

A review bottleneck

When code reviews contribute to longer deployment times or slower lead time, check whether one person’s approval is routinely required. Spread that person’s knowledge over time to reduce dependency and approval burden. section 4.4.2

Figure 4.2 Distributed teams can use bookend meetings to decrease code review delays.
figure

Distributed teams can use bookend meetings to decrease delays in code review and protect lead time. section 4.4.2

How "Looks Good to Me" covers it

How deep it goes
Defines the production boundary and gives performance ranges, but defers detailed measurement procedures.
Examples
Uses one-to-six-month and one-week-to-one-month ranges, plus single-approver and distributed-team review scenarios.
What you can do after
Diagnose delivery delays by comparing lead time with review phases and other deployment-pipeline bottlenecks.
How it connects
Connects lead time with DORA metrics, code review, deployment frequency, change failure rate, and deployment pipelines.

Also explained in

Compare how 6 books explain lead time →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of "Looks Good to Me". The section links point to the parts of the book it draws on.