RDEL #113: What are the seven team profiles of engineering delivery performance?
Seven distinct team patterns emerged from nearly 5,000 developers, each requiring fundamentally different improvement strategies
Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership and apply the latest research in the field to drive to an answer.
Traditional software delivery metrics like deployment frequency and change fail rate tell us what’s happening, but not why. Two teams with identical numbers can have completely different realities—one thriving sustainably, the other burning out while firefighting. This week we ask: What patterns of team health exist beyond traditional software delivery metrics, and how can leaders diagnose their team’s specific challenges?
The context
For over a decade, DORA has helped organizations measure software delivery performance through two key dimensions: throughput and instability. Teams track metrics like deployment frequency, lead time, change fail rate, and recovery time to understand their delivery capability. These measurements have proven valuable for identifying high-level performance trends and assessing software delivery.
However, these metrics are ultimately outcomes—they tell you what is happening, not why. A low deployment frequency might stem from technical debt, bureaucratic processes, or team burnout, and the numbers can’t distinguish between them. More importantly, teams can achieve similar metrics through vastly different means. One team might deploy frequently through excellent practices and sustainable workflows, while another maintains the same cadence through heroics and mounting stress. Understanding the human and systemic factors behind the metrics becomes essential for leaders seeking genuine improvement rather than just better numbers.
The research
DORA’s 2025 research conducted a cluster analysis of nearly 5,000 technology professionals to identify common team patterns beyond isolated performance metrics. The analysis examined eight factors including software delivery throughput, software delivery instability, team performance, product performance, individual effectiveness, valuable work, friction, and burnout.
Key findings from the study:
Seven distinct team profiles emerged (with their relative prevalence):
Foundational challenges - 10%
The legacy bottleneck - 11%
Constrained by process - 17%
High impact, low cadence - 7%
Stable and methodical - 15%
Pragmatic performers - 20%
Harmonious high-achiever - 20%
The speed-versus-stability trade-off is a myth. The best-performing teams (“Pragmatic performers” and “Harmonious high-achievers”) achieve both high throughput and high stability simultaneously, while struggling teams often fail at both dimensions.
Legacy systems create a reactive cycle. Teams in the “Legacy bottleneck” profile face constant firefighting, where frequent challenges with the stability of the software and its operational environment lead to high friction, elevated burnout, and a high volume of unplanned reactive work.
Process inefficiency drives burnout, independent of technical factors. The “Constrained by process” profile operates on stable systems yet reports high levels of both burnout and friction, suggesting that inefficient workflows create unsustainable environments even when technology isn’t the problem.
High impact doesn’t require high cadence. Teams in the “High impact, low cadence” profile demonstrate “top-tier levels of productivity” and “strong product performance” despite low software delivery throughput, though this comes with “elevated levels of friction and burnout” and “a high degree of instability.”
The application
The seven team profiles reveal that identical metrics can mask fundamentally different problems requiring different solutions. Leaders need to diagnose whether poor performance stems from technical debt, process overhead, or unsustainable practices—each demanding distinct interventions.
What engineering leaders can do:
Capture data beyond system telemetry. When you see declining deployment frequency or rising change failure rates, don’t stop at the metric. Investigate whether the root cause is technical debt (legacy bottleneck), process overhead (constrained by process), unsustainable practices (high impact/low cadence), or foundational capability gaps. This often means capturing qualitative data through developers directly.
Watch for stability-burnout warning signs. If your team maintains good throughput but experiences high instability, check team burnout levels. The research shows these patterns often travel together—teams can keep shipping through heroic effort while accumulating both technical and human debt.
Use the profiles as conversation starters. Share these seven archetypes with your team and ask which resonates most with their experience. Teams often lack vocabulary to describe their specific dysfunction beyond “we’re too slow” or “things break too much.” These profiles provide language for more nuanced discussions about whether you’re fighting legacy systems, drowning in process, or achieving impact through unsustainable means—each requiring different paths forward.
The key insight is that improvement starts not with changing your metrics, but with understanding which of these patterns your team embodies—and addressing the specific root causes behind your numbers.
—
Happy Research Tuesday,
Lizzie