Move quickly with confidence.

It’s frustrating for everyone when work gets blocked. That’s why we look at how the work is flowing with Change Lead Time.
‍
This measures the time it takes to go from first commit until the commit has been deployed to production. It is one of the four key indicators of software team performance, as per Google’s DORA research. This is closely related to Cycle Time.

To help you find bottlenecks, we break down your Change Lead Time into its subsets: Coding Time, Review Wait Time, Editing Time, and Deploy Time.

‍We also look at other metrics that can impact the Flow of Work, like PR Size (since smaller PRs move through faster) and your team’s Focus Time (since it’s hard to move work forward without focus time). 

Bluntly speaking, coding work doesn’t have an impact until it’s deployed to customers.  To get an indicator of this, we look at Deployment Frequency, the number of successful deployments that a team made to the production environment. This is another one of Google's four key DORA metrics. We also look at Merge Frequency, which can be useful for teams on fixed deployment schedules. 

In addition to how much was shipped and how often, we also care about what kind of work we did. To show that, we measure Types of Work and Feature vs Maintenance Work. These insights are based on issue tracking and commits data.

To make sure we’re not sacrificing quality for speed, we look at two other DORA metrics: Change Failure Rate and Mean Time to Recovery (MTTR). Note that from 2023 DORA has replaced MTTR with Failed Deployment Recovery Time.

Change Failure Rate is the percentage of deployments that cause a failure in production. We also show Deployment Failure Rate, the percentage of attempts to deploy to production that failed (or timed out).

‍Mean Time to Recovery is a measure of how quickly an organization recovers from a production failure, and Mean Time to Acknowledge shows how quickly an incident is acknowledged. And if you’re trying to get a handle on noisy pages, or want to know which services or escalation policies have the most pages, check out our Number of Pages analysis.

To see the human impact of pages, check out our Wellbeing section.

Good collaboration is the backbone of good code. Extensive research shows that code reviews support code quality, knowledge-sharing, and learning. How people participate in reviews can also be an indicator of psychological safety on teams (more in Google’s team dynamics research).

To help teams understand their collaboration patterns, Multitudes looks at metrics like the Participation Gap (which shows the gap between those who do the most and least code reviews), Feedback Given (in code reviews), Feedback Received, and Feedback Flows (which shows who gives feedback to whom).

Research shows that 71% of tech workers are burned out.

That's why we look at Out-of-Hours Work, which shows how often people are working outside their preferred working hours – this looks across on-call pages, commits, and meetings. Collectively, these can be a warning sign of potential burnout.

Our Wellbeing metrics also show Page Disruptions and Meeting Load within work hours too. Research shows that more meeting interruptions at work leads to people working overtime and feeling more drained.

DORA is a 10-year  longitudinal research program that shows which software delivery metrics are linked to organizational performance and individual wellbeing (learn more about DORA and developer productivity). The Multitudes app has the four key DORA metrics – see them at a glance on the DORA page or dive deep in our detail pages.

‍Change Lead Time: The time it takes a code change to go from first commit to successfully running in production. This shows how well the work is flowing through.

Deployment Frequency:How often code is deployed to production or released to end users. This gives an indication of how much value is being delivered to customers.

Change Failure Rate: The percentage of changes to production that caused failures, requiring remediation like hotfixes or rollbacks. This gives an indicator of the quality of our change processes.

Mean Time to Recovery (MTTR) & Failed Deployment Recovery Time (FDRT): How quickly an organization recovers from a production failure. Note that DORA has now replaced MTTR with Failed Deployment Recovery Time (FDRT), which is the time it takes to restore service after a change to production results in degraded service. 

Source: DORA 2024