Lead Time for Changes: From Commit to Production
Lead Time for Changes measures the time from a developer's commit to that code running in production. It's a core DORA metric for assessing DevOps velocity. The key footgun is confusing it with 'Lead Time,' which tracks from idea to delivery.
Why it exists
To provide a clear, objective measure of software delivery velocity. Teams often feel 'slow' or 'fast' but lack a precise way to quantify the time it takes to get a completed piece of work into users' hands. This metric isolates the technical delivery process from the upstream phases of ideation and coding.
The mental model
Think of it as the time a package spends in the fulfillment center and on the delivery truck. The order (the commit) is placed, and Lead Time for Changes tracks how long it takes to pass through all automated checks (CI), packaging (build), and shipping (deployment) to arrive at the customer's door (production). A shorter time means a more efficient and responsive delivery system.
How it works
It's calculated by measuring the median time between a code commit's timestamp and the timestamp of the successful production deployment that includes it. For example, if a commit is made at 10:00 AM and deployed at 11:30 AM, the lead time for that change is 90 minutes. This is aggregated across many changes to find a median for a team. Tools like Google's Four Keys project automate this by ingesting data from version control (like GitHub) and deployment systems (like Cloud Build) for analysis.
When to use it
Use this metric to identify bottlenecks in your CI/CD pipeline. A consistently high or increasing lead time might point to slow build times, a flaky test suite, or a manual approval gate that needs automation. It is a key performance indicator for any team practicing continuous delivery and seeking to improve its velocity.
When not to use it
Do not use it as the sole measure of team performance or to compare unrelated teams. A team working on a legacy system will naturally have a longer lead time than a team on a modern microservice; context is critical. Also, do not confuse it with 'Cycle Time' or the broader 'Lead Time,' which often measure from the start of work or from a customer request, not just from the commit.
One canonical example
A team's Lead Time for Changes creeps up from 2 hours to 8 hours. By analyzing the data, they find the 'test' stage of their pipeline is the cause. A new suite of integration tests runs serially and takes 5 hours. By parallelizing the test runs, they reduce the test stage to 30 minutes, bringing their total Lead Time for Changes back under 1.5 hours.
Interview question
What specific aspect of the software delivery process does "Lead Time for Changes" primarily measure?
- a.The time elapsed between a code commit and that specific code running successfully in production.Correct
- b.The total time from a customer's initial request for a feature until it is live in production.
- c.The time spent by a team actively coding and testing a feature before it is ready for deployment.
- d.The duration from when a developer starts working on a task until it is released to users.
Why? this is the answer
Lead Time for Changes specifically measures the duration from a code commit to its deployment in production. Option B describes the broader 'Lead Time' from idea to delivery, which the card explicitly differentiates from this metric.
Just read this? Test yourself on what you have been reading.
Read the original → cloud.google.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles