What are DORA metrics, and why do they matter when hiring a dev team?

DORA metrics are the four indicators the software industry uses to measure, objectively, how fast and reliably an engineering team ships: deployment frequency, lead time for changes (the time from commit to production), change failure rate, and time to restore service. They were defined by the DORA (DevOps Research and Assessment) research team, now part of Google Cloud, and became the de facto standard for comparing a team's delivery performance without relying on what that team says about itself.

None of the four measures lines of code or hours worked — they measure the actual outcome: how often the team manages to get changes into production, how long a change takes to get there, what percentage of those changes breaks something, and how long the team takes to fix it when it does. It's the difference between asking “how many hours did you work?” and asking “how often do you deliver value without breaking anything?”

What does each of the 4 DORA metrics measure?

• Deployment Frequency — how often the team ships new code to production: multiple times a day, once a week, once a month.
• Lead Time for Changes — the time between a commit and that change running in production.
• Change Failure Rate — the percentage of deployments that end up causing an incident, a rollback, or a hotfix in production.
• Time to Restore Service — how long the team takes to restore service after a production failure.

Where do these metrics come from, and who defined them?

The DORA research program was founded by Nicole Forsgren, Jez Humble, and Gene Kim, and started publishing the State of DevOps Report in 2013 — originally alongside Puppet. The synthesis of that research arrived in 2018 with the book Accelerate: The Science of Lean Software and DevOps, which for the first time connected these four metrics to measurable business outcomes (profitability, productivity, market share) using rigorous statistical methods, not industry opinion. Google acquired the program shortly after, and DORA now operates as a research team inside Google Cloud.

What separates a high-performing team from a low-performing one?

The gap is much wider than intuition suggests. According to DORA/Google Cloud's 2019 Accelerate State of DevOps Report, “elite” performers were 973 times more likely to deploy on demand and recovered from a production failure 6,570 times faster than low performers. That's not a difference of degree — it's a difference of category.

The most recent report, DORA's 2025 State of AI-assisted Software Development (based on nearly 5,000 technology professionals surveyed), shows that gap still holds: only 19% of teams reach “elite” level, just 16.2% deploy on demand, and 23.9% still deploy less than once a month. AI adoption in development reached 90% in that same report — but more code volume alone doesn't move these numbers: without the underlying practices (version control, automated testing, fast feedback) that DORA metrics measure, a team just produces the same thing it already produced, faster.

Why do these metrics matter when hiring an external squad, not just in-house?

In-house, an engineering team has a manager, a track record, and daily visibility. With an external squad, that visibility doesn't exist by default: the company evaluates a profile, a few references, and a demo, and trusts that what the team says about itself is true. That's exactly the problem DORA metrics solve — they replace self-reported claims (“we're senior,” “we work agile,” “we ship fast”) with evidence that can be verified by looking at the repository: how many deployments happened, how long they took, how many broke something, how long it took to fix.

Does Zenit measure something similar?

ZenitRank follows the same underlying logic as DORA metrics: replacing self-reported reputation with objective delivery evidence — milestone compliance, GitHub evidence, consistency from one project to the next — instead of stars or testimonials nobody can audit. That's not a coincidence: it's the same problem (how to trust the delivery capacity of a team you don't watch work every day) solved with the same principle.

That same principle — evidence instead of status reports — is why Kaizen builds the match by cross-referencing real delivery history, not just an availability form, and why every milestone a squad executes on Zenit gets documented with GitHub evidence, not a status update typed by hand.

DORA metrics aren't a certification a team earns once and keeps forever — they're a continuous snapshot of how it delivers, project after project. That's the question worth asking before hiring an external squad: not “what do they say about themselves,” but “what evidence is left from what they actually delivered last time.”