Change lead time is a really important metric for your company because what it's doing is it's measuring how quickly your team is able to respond to changing conditions, events, or needs.
‍
The key to change lead time is to understand what composes change lead time. Change lead time is measured from the moment the developer starts working on a change, to the moment that it shipped production/ but you can actually break that time down into buckets.

For example, the time a developer is working on the change that's one bucket or the time that your deployment process takes to push a change all the way out to production is another bucket. By looking at things in buckets, you can see what takes the most amount of time and work on optimizing that.

Change lead time is a really important metric for your company because what it's doing is it's measuring how quickly your team is able to respond to changing conditions, events, or needs.

For example, let's say your customer hits a bug. How quickly can your team create, fix, and roll that fix all the way out to production? Or if you need a new feature or a small improvement, how quickly can you deliver that as well?
‍
The company that's able to deliver changes quicker, tend to be more successful than a company that takes two to three months to get any kind of change out to production.

Technically I found the biggest bucket right for improvement is testing. Teams will often have tests as a separate step in a release process, which means that you add days or even weeks to your change lead time. Instead of having it as separate action, integrate your testing into your development process. Have your testers teach your developers how to write tests, automated tests from the beginning, so that don't need a separate step.

To improve your change lead time, eliminate bottlenecks.