top of page

Instrument Lead Time — Engineering Metrics & DORA, Part 2

  • Shawn West
  • Jul 28
  • 4 min read

Updated: Aug 20

Engineering Metrics & DORA · Part 2

"How long does it take to get a change to production?" sounds simple until you try to measure it — and the answer usually surprises the team, because most of the elapsed time is spent waiting, not working. Lead time makes that visible. This walks through instrumenting it end to end, then reading it to find the actual bottleneck — which is almost always review or deploy, rarely the coding itself.

Lead time is commit-to-prod. Find the slow segments; fix them.

Before you start

  • API access to your source host and CI/CD, enough to read commit timestamps, pull-request events and deploy events. Everything here is derived from data you already emit; the work is joining it, not collecting it.

  • A decision about which commit starts the clock. First commit on the branch and the merge commit give very different answers, and the gap between them is exactly the coding time you are trying to see.

  • One team's repositories, not the whole estate. Lead time aggregated across teams with different release models describes none of them.

  • Somewhere to store per-PR records. You need the distribution, not the average — Step 4 is where that becomes the point.

Step 1: Define the Endpoints (10 min)

  • Start: first commit on the branch / PR

  • End: code reaches production (and serves traffic)

Different definitions exist:

  • Commit on feature branch

  • PR open

  • First review

  • First customer sees it

Pick one. Stick with it.

Step 2: The Segments (15 min)

Break lead time into:

  1. Code time — commit to PR open

  2. Review time — PR open to PR merge

  3. Pipeline time — merge to ready-for-prod

  4. Deploy time — ready to live

Each contributes. Improvements come from finding the biggest.

Step 3: Get the Data (15 min)

GitHub API:

gh api /repos/myorg/myrepo/pulls?state=closed --paginate

For each PR:

  • created_at → PR open

  • merged_at → merge

  • First commit timestamp

  • Deploy timestamps (CI logs)

Tools collect this:

  • LinearB, Swarmia, Cortex

  • Or roll your own with GitHub + CI logs

Step 4: Aggregate (10 min)

Per PR:

PR #1234:
  Commit → PR open: 2 days
  PR open → merge: 1.5 days
  Merge → prod: 3 hours

Total: 3.6 days

Aggregate:

  • p50 (median)

  • p75 (typical)

  • p95 (slow ones)

Trend over weeks / months.

Step 5: Find the Bottleneck (15 min)

Common patterns:

  • Long code time: features too big; split sooner

  • Long review time: reviewer bandwidth; PR size; team norms

  • Long pipeline time: slow tests; flaky tests; queue backups

  • Long deploy time: manual steps; release cadence

Where's your bottleneck?

Step 6: Action on Review Time (10 min)

If reviews are slow:

  • Smaller PRs

  • Dedicated reviewer rotation

  • Async-first culture

  • SLA on first response

Common quick win. Most teams here.

Step 7: Action on Code Time (10 min)

If code time is long:

  • Smaller scope per PR

  • Pair-programming complex parts

  • Better local dev (faster iteration)

  • Removing blockers (unclear specs, broken local env)

Pre-PR investment.

Step 8: Action on Pipeline / Deploy (10 min)

Slow tests:

  • Parallelize CI

  • Test pyramid (more unit; fewer integration)

  • Caching dependencies

  • Skip-when-unchanged optimizations

Manual deploys:

  • Automate

  • Continuous delivery (auto-deploy on merge)

  • Trunk-based development

Step 9: Beware Goodhart (10 min)

If you optimize "lead time as the goal":

  • Engineers split PRs into nonsense

  • Reviewers approve faster (less rigorously)

  • Quality drops

Lead time is signal. Improve via the underlying practices, not by gaming.

Step 10: Visualize (5 min)

Dashboard with:

  • Lead time trend (4-week rolling)

  • Breakdown by segment

  • Per-team comparison

  • Outlier PRs (drill-down)

Visible = remembered = improved.

Where lead time actually goes

The total is not the useful number. The segments are, because each one has a different cause and a different fix — and teams routinely optimise the shortest one because it is the most visible.

Segment

Clock runs from

When this is your bottleneck

What actually moves it

Coding time

First commit to PR opened

Long-lived branches, large diffs, work started before it was understood

Smaller slices and earlier PRs, not faster typing. This is a decomposition problem wearing a schedule

Review time

PR opened to approved

PRs sit overnight; the same one or two people are on every review

Review capacity and batch size. A 400-line PR waits because reviewing it is a task, not a favour

Pipeline time

Approved to build finished

Slow or flaky suites; queueing for shared runners

Test parallelism and flake removal. Flaky tests cost twice — the rerun, and the trust

Deploy wait

Build finished to running in production

Release windows, change boards, manual gates

The gate itself. No amount of engineering speed moves a Thursday-only release window

You're done when

  • You can produce a per-PR record with all four segment durations, for one team, without asking anyone to remember anything.

  • You are reading the median and the tail rather than the mean, and you can name the slowest segment for your team — with a number, not an impression.

  • You have checked your assumption against the data at least once. The segment teams believe is slowest is very often not the one the timestamps identify.

What You Just Did

Lead time instrumentation: definition, segments, data, aggregation, bottleneck, actions per segment, Goodhart, visualize. The first DORA in production.

Common Failure Modes

One-time measurement. No trend.

Optimize lead time; quality drops. Goodhart.

Don't segment. Don't know where the slowness lives.

No per-team view. Some teams stuck without help.

No actions from data. Tracking without improvement.

Sources

Continue the Engineering Metrics & DORA path

Part of the Engineering Metrics & DORA learning path.

bottom of page