DORA 2025, Part 2. Defining software delivery performance: a look at seven team profiles

Nathen Harvey - Head of DORA, Google Cloud

The release of a new software product is always an event, because the real value of the work becomes clear only when the world can start using it. Those users may be customers, partners, colleagues, strangers, or even other technical systems. It is also the moment when we begin to understand how the software will behave in a live environment and how well it meets user needs.

We can do a lot in advance to make sure the product works as intended, but the release itself shows whether expectations become reality - or not. Launching new software is not just releasing an application or service. After release, users begin giving feedback, and that feedback will either encourage or directly force you to make improvements.

There are many reasons you may need to change an application: fix security vulnerabilities, improve performance, reduce operating costs, or lower the carbon footprint. These actions are driven by a desire to help users and ensure the application's long-term success. But it is important to think not only about the product, but also about the long-term well-being of the teams that build, deploy, operate, and support it.

For these teams to achieve sustainable, high-quality outcomes, they need the right conditions and the necessary skills. Together with business pressure to move faster and deliver more, these factors led DORA to make software delivery performance a central theme of our research.

We conducted cluster analysis to understand the human and systemic factors behind software delivery performance and to identify recurring team behavior patterns. Statistical analysis identified seven team types based on the following parameters: 1. Team effectiveness Assesses how effectively a person's immediate team works and how well it collaborates. 2. Product effectiveness Measures the quality and success of the product or service the team works on.

Factors such as the ability to help users complete important tasks, data security, and performance metrics such as latency are taken into account. 3. Software delivery throughput Shows the speed and efficiency of the delivery process. 4. Software delivery instability Reflects the quality and reliability of the deployment process. 5. Individual effectiveness An employee's self-assessment of their productivity and sense of accomplishment at work. 6.

Work value The share of time a person considers truly useful and meaningful. 7. Process friction Assesses how much obstacles interfere with getting work done. Less friction means better results. 8. Burnout Measures feelings of exhaustion and cynicism related to work. A lower level is a positive sign.

Organizations, teams, and individual contributors typically aim to improve team and product performance, throughput, individual effectiveness, and the share of valuable work, while reducing delivery instability, friction, and burnout. Our analysis showed seven distinct team archetypes - from those achieving strong results in a healthy and sustainable environment to those constrained by technical debt or inefficient processes. Cluster 1: Basic Difficulties These teams operate in survival mode.

They face serious challenges caused by fundamental gaps in processes, the work environment, and outcomes. Share of respondents: 10% of survey participants belong to cluster 1. Performance metrics: key metrics related to team effectiveness, product delivery quality, and value creation are consistently low. Team well-being: According to the study, employees show high levels of burnout and significant work obstacles. System stability: There are clear problems with software and operational environment stability.

Cluster 2: Legacy Bottleneck Teams in this cluster operate in constant reactive mode. Unstable systems shape their daily work and undermine morale. Share of respondents: 11% of survey participants belong to cluster 2. Performance metrics: key product quality metrics are low. The team releases updates regularly, but their value is significantly reduced by persistent quality issues. Team well-being: The data show a difficult work environment.

Employees report a high level of work impediments and increased burnout. System stability: there are serious and frequent problems with software and operational stability, leading to a large amount of unplanned, reactive work. Cluster 3: Process-Bound These teams are like running on a treadmill. Despite working with stable systems, their efforts are absorbed by inefficient processes.

The result is high burnout and low impact on the product and business. Share of respondents: 17% of survey participants belong to cluster 3. Performance metrics: key metrics reflect low effectiveness and a limited ability to create business value or user benefit. Team well-being: The data show high burnout and significant friction at work.

This indicates that the current workflows create a difficult and unbalanced environment for the team. System stability: the team's software and operational environment is stable and reliable. This means technical instability no is a source of performance and well-being problems. Cluster 4: High impact at a low pace These teams create high-impact work, as shown by strong product metrics and high individual effectiveness.

However, their way of working is low-frequency delivery: low throughput and high release instability. Share of respondents: 7% of survey participants belong to cluster 4. Performance metrics: the team consistently achieves high levels of productivity.

Both individual effectiveness metrics and product value metrics are strong. Team well-being: The data show low friction, indicating efficient and well-aligned processes. System stability: the operational environment is highly unstable. This level of volatility creates serious risks for service reliability and long-term sustainability. Cluster 5: Stable and Methodical These teams are like dependable masters of their craft.

They create a high-quality, valuable product while working at a measured and sustainable pace. Share of respondents: 15% of study participants belong to cluster 5. Performance metrics: key metrics for product quality and value creation are consistently high.

At the same time, delivery throughput is in the lower percentiles, which suggests a calmer, more deliberate work pace. Team well-being: The data show low burnout and friction, a sign of a healthy and sustainable work environment. System stability: the team's software and operational environments are highly stable and reliable.

Cluster 6: Pragmatic Performers These teams consistently deliver with high speed and reliability, even if the work environment has not yet reached the highest level of engagement. Share of respondents: 20% of study participants belong to cluster 6. Performance metrics: key software delivery metrics are strong - throughput is above average, and instability is low.

The team maintains a steady cadence and consistently delivers valuable work, reliably meeting expectations. Team well-being: The key difference between this cluster and the absolute leaders is well-being metrics. The data show average levels of burnout and friction.

This suggests that the work environment is functional and resilient, but may not provide enough factors that increase engagement. System stability: the software and operational environment is stable and reliable, providing a solid foundation for high team performance.

Cluster 7: Harmonious High-Performing Teams This is what true mastery looks like: a sustainable work cycle where a stable environment without unnecessary obstacles allows the team to build a high-quality product without burnout and for the long term. Share of respondents: 20% of survey participants belong to cluster 7. Performance metrics: the team shows strong results across all key areas - from employee well-being to product metrics and software delivery quality. Team well-being: the work environment is marked by low burnout and a minimal number of factors that interfere with work. System stability: the team works on a reliable, sustainable technical foundation that supports both speed and quality.

You may want to understand how your team compares with the other participants in this year's study. It is important to remember that measurements are made at the application or service level. This approach helps build shared accountability and involvement across functions in improving outcomes. In addition, the most useful comparison is comparing the same system over time. The goal is not necessarily to rank at the top on delivery metrics, but to build continuous learning and improvement.

The data below shows how responses from the DORA 2025 survey were distributed and helps clarify the overall picture. Distribution of change lead timeSurvey question: What is your change lead time - that is, how long does it take from commit to a successful code deployment in production?

Deployment frequencySurvey question:How often does your organization deploy code to production or release it to end users?

Distribution of recovery time after a failed deploymentSurvey question: How long does it usually take to restore the service after a production change or user-facing release degrades service performance (for example, a failure or outage) and requires a fix such as a hotfix, rollback, forward fix, or patch?

Distribution of failed deployment rateSurvey question:Approximately what percentage of production changes or user-facing releases result in degraded service performance, such as failures or unavailability, and require a follow-up fix, hotfix, rollback, forward fix, or patch, if such cases occur?

Distribution of rework shareSurvey question:Approximately what percentage of deployments over the past six months were unplanned and carried out to fix a user-impacting issue?

Performance metrics provide a high-level view of how the entire delivery process is working. If you track them over time, you can tell whether you are improving or not. The ways to improve will differ for each application, although some common problems do appear - for example, drawn-out review and approval cycles. Consider an example. At a regular retrospective, the team discusses its metrics and notices that lead time - the time from commit to production - has started to increase.

The team may have seen this on a dashboard, but most often these issues are felt in the flow of work. These metrics do not always require second-level precision - teams usually know whether they are moving in the right direction or not. To reverse the trend, you need to understand what is causing it. The team looks at data in the repository and analytics tools and sees that code reviews are taking longer.

The team decides this is the first thing to work on and discusses specific steps: - prioritize code reviews in daily work; - make changes smaller so they are easier and faster to review. After choosing actions, the team agrees to revisit change lead time and all key delivery metrics in a month to assess whether it worked.

Whatever the team’s current profile - "Process-Constrained" or "Stable and Methodical" - the goal is the same: to build a culture of continuous improvement that over time leads to more resilient, productive, and balanced work. Read the third part of the study, dedicated to the use and application of AI in development.

In this section, we examine how developers use AI in everyday work, which tasks they automate, what benefits they gain, and what limitations they face. This part provides a practical understanding of how AI is truly changing development processes and why its impact is becoming critical for teams and companies.