"North Star" metrics allow you to get a holistic picture of how your engineering team is performing, allowing you to identify how interventions to improve engineering efficiency and developer experience impact your team.

Whilst it's important to keep an eye on all North Star metrics, there is one key metric that we have found separates the best software teams from the rest of the pack. Many notable engineering teams (like Google and Spotify) have achieved remarkable success by optimising Change Lead Time.

In short: Change lead time is the time from first commit to deployment. In other words, it’s the speed of your development.

As engineering teams have ownership and control over these components of the delivery process, it provides a great metric to measure engineering process improvements against.

Change Lead Time is the sum of the Development Time and the Review Time of the software development process, below you can see how we present it as such in the Haystack Dashboard. Understanding Change Lead Time as a sum of these two metrics will allow you to drill down to identify where the constraints are in your software engineering process.

Example of Cycle Time in Haystack as a sum of Development Time and Review Time

See definitions of Change Lead Time, Cycle Time, Development Time, Review Time and more


What Evidence Is There That Cycle Time Is an Effective Metric?

The following video provides an overview of some of the evidence that lower Cycle Time leads to better organisational performance:

See also: How do I convince my team about using metrics?


What Problems can Change Lead Time Help Uncover?

Engineering Teams using Haystack have managed to identify many different types of issues by drilling down from Change Lead Time, below we have included some examples of these:

  • Technical Debt

  • Context Switching

  • Team Burnout

  • Poor Communication

  • Poorly Written Tickets

  • Inefficient Code Review

  • Poor Quality Code

  • Long Compilation Times

  • Stuck Engineers

Again, Change Lead Time provides one of the most holistic measures of how well an engineering team performs, so this list is not exhaustive and indeed Change Lead Time is capable of identifying the most obscure challenges with the software engineering process.

By keeping an eye on your Change Lead Time (and, more importantly, changes to it) then you'll be able to quickly identify problems as they arise and work with your team to resolve them.

Just about every developer, team, and company wants to ship faster, build better code, and deliver more value to customers.

By understanding their Change Lead Time, dev teams can:

  1. Get a baseline for the development process

  2. Identify leaks and clogs in their process

  3. Optimize and improve the developer experience

Change Lead Time can help us reduce our own bias and replace gut feelings. More importantly, it gives us a baseline from which we can continuously drive improvement.

Next Steps

So how can you practically use these metrics to improve your software engineering process? Learn more in our best practice article: Finding Bottlenecks in your Software Development Lifecycle (SDLC) where we'll cover how you can improve your engineering team's North Star metrics by using the fastest and most effective ways to cut Change Lead Time and deliver faster.

Did this answer your question?