Definition
Lead Time for Changes
Lead Time for Changes is the elapsed time from a code change being committed to that change running in production. It is one of the four DORA metrics and measures how long it takes work to travel from a developer's keyboard to live users.
What it measures
Lead Time for Changes measures the duration between the moment a change is committed and the moment it is deployed to production. It captures the full delay of your delivery path: review, merge, build, test, and release.
It is a delivery speed signal, not a coding speed signal. A short lead time means changes move through your pipeline quickly once written. A long lead time means work sits waiting in review, in a merge queue, or behind an infrequent release cadence.
How to measure it
Pair each production deployment with the commits it shipped. For every commit, take the difference between its authored or merged timestamp and the deploy timestamp of the release that carried it. Report the median across a window rather than the mean, since a few stuck changes will skew the average.
Git history gives you commit and merge times, your deploy pipeline gives you release times, and your pull request data lets you split the interval into review wait versus build and release wait. The hardest part is attribution: knowing exactly which commits a given deploy contained. Without a reliable commit-to-deploy mapping, you are estimating, not measuring.
What it does not tell you
Lead Time for Changes tells you how fast changes move, not whether those changes mattered. A team can drive lead time down to minutes while shipping work that advances nothing on the roadmap, and the metric will look excellent the entire time. It rewards a fast pipeline regardless of what flows through it.
It also hides where the delay lives unless you decompose it. A flat number cannot tell you whether the wait is slow review, a clogged merge queue, or a weekly release train, and it says nothing about the value or risk of any individual change. Two commits with identical lead time can be a one-line config tweak and a major migration.
This is the gap Execution Intelligence closes. Speed is motion, not direction. Reading execution honestly means knowing not just how fast a change shipped but what initiative it served, whether it moved the outcome it was meant to, and what it cost. Lead time is a useful input to that picture and a poor substitute for it.
How InteliG uses it
InteliG computes Lead Time for Changes from real git history and deployment records with no manual instrumentation and no agent in your pipeline. Cognis maps each deploy to the commits it carried, so the interval is measured from actual events rather than self-reported timestamps.
From there it connects the number to context: the initiative the work belongs to, the contributors who authored and reviewed it, and the cost of the time spent. That turns lead time from a standalone speed gauge into one thread in the chain from strategy to code to outcome to spend.
Related terms
- Deployment Frequency — How often a team ships changes to production
- Cycle Time — Elapsed time from starting work on a change to shipping it
- Execution Intelligence — Reading how an organization actually executes, from strategy to code to cost