DORA metrics for a high performance engineering team

On a rainy day in Saigon, sitting with my friend in a nice and cozy coffee shop, we talked about how to build a high performing team in this modern era. While the conversation covered from hiring to retention, what we did came to a consensus view was quite simple: At first, how to measure a high performance team?

As we all started our career as software engineer, we love to work with specific metrics from measuring to improving there are transparent among the team and the managers. We actually respect the metrics related to money/cost because it is important for any company not going to bankrupt. However, cost-driven culture is quite old, and now we want to build the company with value-driven culture that leads us to discuss about how DORA works as well as the good book Accelerate.

So, what is DORA?

DORA stands for DevOps Research and Assessment team, a research program that was acquired by Google in 2018. From their establishment, DORA tries to understand the practices, processes, and capabilities that enable teams to achieve high performance in software development with value-driven delivery. They are famous for a series of annual reports to benchmark DevOps practices and provide guidance for how DevOps teams can continuously improve their processes and capabilities.

In 2018, they published the book, Accelerate, identifying a set of metrics and indicating software teams’ performance as it pertains to software development and delivery capabilities. These metrics have come to be known as DORA metrics. Accelerate is a very good book that we recommend for next generation tech leadership in any companies that believe in the digital business strategy.

What is DORA’s metrics?

There are four metrics that matter the most to any high performance engineering team:

1. Deployment Frequency: How often an organization successfully releases to production
2. Lead Time for Changes: The time it takes a commit to get into production
3. Change Failure Rate: The percentage of deployments causing a failure in production
4. Time to Restore Service: How long it takes an organization to recover from a failure in production

If this the first time you hear these metrics, the high level of its meaning is quite simple as we divided into two groups: the first one is the 1-2 metrics, which indicates how fast it ships; the second group is the 3-4 metrics, showing how well it was shipped. These metrics can be pulled out automatically if you have your DevOps pipeline in place. So, it is quite easy to separate between a team that don't have those metrics and the team that visualize this information and provide many strategies to improve these metrics day by day.

Since it becomes a standard, it is easy to "google" and find a nice table as a reference goal for your team.

DORA's suggestion for a High Performance Engineering Team

The idea behind is start to measure and improve it with your team since the complexity of every organization, platform and product is different. Being on tech leadership role requires you to spend your dedication to work closely with the engineering team to coach and build the team together, even how big or how small your team size is.

Why don’t we talk about cost-related metrics?

Most of us believe in value-driven culture more than cost-culture, and money is a factor that plays an important role for building a business, not for developing engineering culture. Yes, anyone of us loves free pizza and good craft-beer, but these won’t lead to a culture that you want it to fly high.

Why don’t we talk about story point velocity?

This metrics look valid at first but again this only tided to very specific team internal improvement not really fit for external evaluation & focus on these metrics tend to make the development team estimate more time needed for the task instead of ship more & ship faster qualified features to the product.

Some last few words

We wrap up our conversation to go for a glass of beer since one of us hit a success on media this week.

You can’t improve what you don’t measure!

Even with a good measure, good managers still find the way to achieve them, but it does not mean delivering the real value to neither the product nor the team.