# Change Lead Time
{% hint style="info" %}
⭐️ This metric is one of the [4 Key Metrics published by Google's DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/) team.
You can see all 4 key DORA metrics on the [DORA Metrics page](https://app.multitudes.co/DORA) of the Multitudes app.
{% endhint %}
********What it is:** This is DORA's `Change Lead Time` (previously called `Lead Time` in the app), a metric that shows how long it takes the team to write code, request and give feedback, make revisions, merge the PR, and then deploy into production. It’s an indicator of how long it takes to deliver value to customers.****
**Why it matters:** `Change Lead Time` is one of the top four indicators of software team performance, according to [Google’s DORA research](https://cloud.google.com/devops/) (the DevOps Research and Assessment research). Their research shows that a faster `Change Lead Time` is correlated with better business outcomes. Specifically, teams with a faster `Change Lead Time` do work that is better, more stable, and more secure. If you want to dive deeper into this, check out the [Accelerate](https://itrevolution.com/book/accelerate/) book. Note that this is closely related to `Cycle Time`; we measure `Change Lead Time` since that's recommended by DORA. [See here](https://www.multitudes.com/blog/lead-time-vs-cycle-time) for more about the differences between `Change Lead Time`, `Cycle Time`, and `Lead Time`.
**How we calculate it:** To calculate `Change Lead Time`, we measure the **number of hours from the first new commit** on a pull request’s (PR’s) branch **to a successful attempt of deployment to production for that PR, or to PR merged** if there is no deployment data.
{% hint style="warning" %}
This means some of the PRs included in this chart will not yet be deployed. This is so that you can get insights for all repositories, even ones that don’t have workflows configured. You can get a breakdown of how long PRs are taking to merge vs. deploy with the Change Lead Time subsets chart or the specific line charts (like [this one for deploy time)](https://docs.multitudes.com/metrics-and-definitions/process-metrics/flow-of-work/..#deploy-time).
{% endhint %}
{% hint style="success" %}
**What good looks like**
The latest DORA research ([from 2025](https://dora.dev/research/2025/)) shows that the top 15% of responses have a `Change Lead Time` of less than 24 hours.
{% endhint %}
### **Additional calculation notes for Change Lead Time & subsets**
Here are a few additional notes that affect the calculations for `Change Lead Time` and/or its components, `Coding Time`, `Review Wait Time`, `Editing Time` and `Deploy Time`.
These exclusions apply to Coding Time, Review Wait Time, and Editing Time :
* Our focus is on PRs that the team collaborated on, so we exclude bot merges and selfie-merges (PRs merged by the PR author, with no comments or reviews by other collaborators).
* If you like, you can choose to exclude weekend hours from these calculation; simply toggle on “Exclude Weekend Hours”.
For just `Change Lead Time` and `Coding Time`, please note:
* When you first join Multitudes, your historical data (the first 6 weeks) will show a lower time metric if your company does a lot of rebasing. This is because we can’t get original commits from the historical data in GitHub, so the rebased commit is taken as the first commit.
* Once you integrate, we get events data from GitHub. This means we will get the original commits that are pushed to GitHub, even if your teams rebase or squash the commits later. Therefore, you might notice that your metrics are higher after the time that you onboard onto Multitudes, compared to your historical data.
* If you rebase your commits before pushing the branch to GitHub for the first time, GitHub notifies us of the rebase time rather than when the commits were originally made. In order to provide the most accurate measure of `Coding Time`, we therefore encourage you to push commits to GitHub as they are made, even if the intent is to rebase or squash these commits before opening a PR or requesting a review.
For `Review Wait Time`, please note:
* The counting for the `Review Wait Time` starts when a review is first requested. If a review was never requested (i.e. when someone provides a review without being asked to review), we fall back to counting from the time the PR was first opened or when it was first moved to "Ready for review" if it was initially a draft PR.
For just the separate `Deploy Time` line chart:
* If you’re using the [GitHub Actions integration](https://docs.multitudes.com/integrations/github-actions)…
* We do include selfie PRs (non-collaborative PRs) in this metric.
* This is because we want to provide the most comprehensive view of how long your deployment pipeline takes, which means incorporating all relevant data.
* Whether a deploy is of a collaborative PR or a selfie PR, this should not normally influence how long the deploy takes, therefore selfie PRs are a relevant segment of your team’s data on how long things take to deploy.
* If you're using the [Deployments API](https://docs.multitudes.com/integrations/deployments-api), we only look at what you POST, so you can decide how you want to treat selfie PRs
* For `Change Lead Time` we intentionally include all merged PRs, even if they are not yet deployed (or if [deployment metrics aren’t available](https://docs.multitudes.com/metrics-and-definitions/deployment-metrics)), so that you are getting insights across all repositories, even if some of them are not set up with GitHub Actions deploy pipelines or the Deployments API.
### **How Change Lead Time is broken into its subsets**
`Change Lead Time` is broken up into its four components, `Coding Time`, `Review Wait Time`, `Editing Time`, and `Deploy Time`. Where these start and end can depend on the events in each PR's life cycle. Here is a typical PR timeline. Click the dropdown below it for more scenarios.
Timeline showing Change Lead Time begins at the First new commit and ends when deployed.
