After reading through the 2024 DORA report, it’s clear that failure is inevitable, and high-performing teams don’t try to avoid failure—they prepare for and handle it gracefully when it happens.
The DORA group continues to provide critical insights into team performance, covering metrics such as change failure rates and exploring emerging themes like AI adoption and rework rates. It serves as a valuable resource for understanding trends in software delivery.
But data alone doesn’t tell the whole story. While the DORA Report lays out the “what,” we’ve taken a closer look at the “why” behind its findings—and uncovered insights about culture, systems, and leadership that go beyond the metrics.
We’ll start with one of the most counterintuitive findings.
Why do high-performing teams report higher change failure rates than their medium-performing counterparts?
DORA buckets performance level into four categories: Low, Medium, High, and Elite. As such, one might expect to see a direct correlation between performance and change failure rate. Shouldn’t high-performing teams have fewer change failures than medium-performing teams? The data tells a counter-intuitive story where the difference lies in their relationship with failure.
High-performing teams understand that failure is a natural part of the process. Rather than avoiding it, they focus on minimizing its cost and learning from it quickly. They build systems that catch issues early, allow for fast recovery, and empower developers to move quickly. This makes experimentation safe, and when something goes wrong, it’s often caught before it becomes a big deal. If it does become a big deal, their systems are designed to detect and roll back changes automatically, minimizing impact.
Low-performing teams may rely on layers of manual checks and approvals in an attempt to prevent mistakes entirely. But this approach slows everything down, increases frustration, and ultimately leads to worse outcomes when failure does occur—because it always does.
What sets these teams apart isn’t individual skill—it’s the systems they rely on. Even the best developers will struggle in a low-performing team if the environment doesn’t support quick recovery and continuous improvement. This distinction is reflected in the data, as the DORA Report shows just how far elite performers outpace low performers:
- 127 times faster lead times
- 8 times more deployments per year
- 182 times lower change failure rates
- 2,293 times faster recovery from failed deployments
The numbers are striking, but they aren’t the whole story. Achieving these results isn’t just about avoiding failure or relying on superstar developers—it’s about building sociotechnical systems that drive continuous improvement. This means addressing not only the technical aspects but also the processes and cultural factors that enable teams to thrive.
Change doesn’t happen overnight. Improvement requires a culture that enables learning, fast flow, and fast feedback. It’s about making failure less costly and more recoverable. By iterating step by step, organizations can create systems that push every team—whether low- or medium-performing—closer to elite standards. The best teams focus on elite improvement, not just elite performance. They design their processes with this in mind, creating an environment where learning from failure is just part of the routine.
Do High-Performing Teams Experience More Burnout?
The DORA Report highlights a clear link between rework rates, change failure rates, and burnout. Teams that spend more time reworking failed changes are more likely to experience higher levels of burnout. But what drives burnout in teams, and does performance level play a role?
Burnout is less about whether a team is high- or low-performing and more about the systems they work within. In low-performing teams, failure is often costly and difficult to manage. These teams rely heavily on manual checks and approvals to try to avoid mistakes, but when failure inevitably occurs, it leads to frustration and exhaustion. Developers often feel stuck in slow processes that make meaningful progress hard to achieve, compounding the emotional toll over time.
In contrast, systems designed to find failures early in the development process and reduce the scope of rework creates an environment where recovery is quicker and less disruptive. So overall, it’s not only about the people—it’s about the systems too. You could take someone from an elite-performing team, put them in a low-performing team, and their performance would significantly decrease.
So how can you build systems that prevent burnout? We recommend leaders focus on the following:
1. Encourage Open Communication:
- Run weekly check-ins where team members can share blockers, frustrations, or ideas for improvement without fear of blame.
- Create an anonymous feedback channel for those who may not feel comfortable speaking up publicly.
2. Streamline Workflows:
- Conduct a “waste audit” on current processes to identify redundant approvals or unnecessary steps. Remove one bottleneck at a time.
- Implement kanban boards or workflow visualization tools to track progress and avoid overloading teams.
3. Support Learning and Growth:
- Schedule retrospectives at the end of each sprint to discuss what worked, what didn’t, and what needs to change. Don’t let retrospectives get stale.
- Routinely offer team-wide training to upskill developers or introduce better tools and practices (frequency will vary per organization).
4. Promote Balance and Flexibility:
- Introduce “focus hours” where no meetings are scheduled, so developers have uninterrupted time to work.
- Allow team members to block time off for personal commitments and respect those boundaries.
5. Automate Where Practical:
- Use CI/CD pipelines to automate builds, testing, and deployments, reducing the manual work needed to push changes.
- Set up automated alerts for predictable system issues, so the team doesn’t waste time on repetitive troubleshooting.
6. Recognize and Celebrate Wins:
- Share a “win of the week” during team meetings to highlight individual and group successes.
- Post a virtual or physical “achievement board” where milestones are displayed and celebrated.
7. Foster Experimentation:
- Introduce a “failure log” where the team documents experiments that didn’t work and what they learned from them.
- Allocate 10% of sprint time to experimentation or technical debt work to encourage creative problem-solving.
8. Build Psychological Safety:
- Ensure team leads openly acknowledge their own mistakes and encourage team members to do the same.
- Pair junior and senior developers for collaborative code reviews, making feedback feel like a learning opportunity rather than criticism.
Burnout isn’t just a matter of working too hard—it’s a symptom of systems that aren’t designed to support people. Leaders who prioritize sustainable systems, fast feedback, and team recovery lay the foundation for long-term success—whether their teams are high-performing or still climbing the ladder.
Why Has AI Adoption Boosted Productivity but Not Software Delivery Performance?
The DORA Report reveals that while many teams report AI is improving productivity, 60% of organizations still classify their software delivery performance as medium or low. This raises an important question: is AI actually driving meaningful improvements, or are its benefits overstated?
The challenge lies in what “productivity” means. AI often assists with tasks like code explanation, ideation, or generation, which can make developers feel more productive by saving time and reducing cognitive load. However, the real impact on core software delivery metrics—like lead time and change failure rates—is less clear. When AI is over-relied upon to generate code, it often creates new problems, such as producing incomplete or incorrect outputs that require extensive debugging.
This common mistake can lead to several outcomes:
- Illusion of Speed: AI can generate a lot of code quickly, but it can also increase debugging time.
- Narrow Productivity Gains: AI is great for routine work but doesn’t always improve high-impact tasks like creative problem-solving or system design.
- Review Fatigue: When AI primarily handles code generation, developers perform a disproportionate amount of code review. This can be exhausting and lead to poor quality or incorrect code slipping through.
Organizations looking to close the gap between perceived and actual productivity can take specific steps to integrate AI into their workflows better:
- Limit Over-Reliance on AI: Use AI to enhance, not replace, critical thinking. Focus on code explanation and ideation over generation. When generating code, work in small increments with active human oversight.
- Strengthen Validation Processes: Invest in tools and practices to review and test AI-generated outputs before they are deployed.
- Encourage Skill Development: Train teams to understand AI’s strengths and weaknesses, so they can use it effectively without over-dependence. We’re all novices at using AI because it’s so new. Encourage people to keep learning what works well and what doesn’t.
- Monitor Impact on Metrics: Track how AI use affects measurable delivery performance—like lead time, failure rates, and recovery time—not just team perceptions.
AI is a valuable tool, but its benefits depend on thoughtful implementation and realistic expectations. Focusing on both its strengths and its limitations ensures that AI delivers meaningful improvements—not just in how productive teams feel, but in how well they perform.
How Can Leaders Truly Drive Transformational Change in Their Teams and Organizations?
True leadership isn’t just about driving team performance—it’s about continuously growing alongside your team.
Driving transformational change within an organization is no small feat. It requires leaders to balance the technical and cultural aspects of their teams while also committing to their own growth.
To lead transformative change, leaders need to get their reps in. For engineering leaders, a “rep” involves building context, making decisions, and learning from their outcomes while adopting a mindset of humility and curiosity. Great leaders revisit past decisions to ask, “Did this work? Was it the right call?” Leaders refine their instincts and improve over time by closing the loop on decisions.
Athletes often mentally rehearse their movements to prepare for high-pressure situations. Leaders can use a similar approach by considering how they would handle real challenges their peers have faced. Talking with other leaders at community events or in online groups can simulate real-world examples of tough decisions. By imagining how they’d respond in those situations, leaders can build confidence and prepare for similar challenges in the future.
To help their teams get their reps in, leaders can create an environment where their teams can practice, learn, and improve. Growth doesn’t happen without space to try things, make mistakes, and learn from them. When team members feel safe to experiment without fear of blame, they can put in their reps and improve over time.
In short, transformational leadership is about practicing deliberate decision-making, cultivating curiosity, learning from others, and prioritizing a growth mindset for the team and the leaders themselves.
Do the DORA Metrics Fully Capture Business Success?
Metrics are valuable, but they’re a means to an end—not the end itself.
DORA metrics are strongly tied to business success. Teams that excel in these areas tend to belong to organizations with higher revenue growth, stronger profitability, and expanding market share. These metrics aren’t just technical—they reflect how well an organization can innovate, respond to changes, and deliver value consistently.
That said, DORA metrics don’t tell the whole story. If you’re not tying those improvements to broader outcomes, you can have elite performers on paper and still not see the value reflected in business success. For example, customer satisfaction, retention, or operational efficiency matter just as much, if not more, in terms of business impact.
Organizations must expand their view to include metrics that help bridge the gap between engineering performance and business outcomes. DORA metrics show how well your delivery process is running, but consider asking yourself: What are we actually delivering? Is it what our users need? Is it moving the needle for the business?
In short, scoring well on DORA metrics doesn’t automatically mean your business will succeed. Look beyond the numbers. The real value comes when you can tie what’s being delivered to the results your company is trying to achieve—whether that’s growth, efficiency, or user satisfaction.
Key Takeaway from our Insights
The 2024 DORA Report offers a roadmap for organizations striving to improve their software delivery performance. But as we’ve seen, metrics are most impactful when viewed in context. Scoring well on DORA metrics or adopting the latest tools is only part of the equation. The real challenge—and opportunity—is tying those improvements to broader outcomes that support business success and team well-being.
Reducing the cost of failure, fostering a culture of continuous learning, and aligning technical efforts with user and business needs are the principles that drive meaningful, sustainable progress. Transformational change takes time, but organizations can create the conditions for long-term success by focusing on iterative improvements and building systems that empower teams.