How to improve DORA metrics is a different question depending on which tier your team is starting from, and most playbooks skip that distinction entirely. The path from low to medium performance looks nothing like the path from high to elite. This guide breaks the improvement work down by starting tier and by metric, using the same framework DORA’s own research (dora.dev) documents as capabilities rather than tips.
Start by defining your terms before touching anything
Before improving any DORA metric, define exactly what counts as a deployment and what counts as a failure, and write both definitions down. A deployment is typically a merge to your main branch, a tagged release, or a successful production pipeline run, pick one and apply it consistently. A failure is usually a rollback, a hotfix shipped within 24 hours of a release, or a P0/P1 incident opened during a deployment window. Skipping this step is the single most common reason teams end up with DORA numbers nobody trusts, since inconsistent definitions make month-over-month comparisons meaningless.
Improving deployment frequency
If you’re moving from low to medium tier, the priority is consistency over speed. Establish a regular deployment cadence, even weekly, before worrying about daily deploys. Automate the deployment pipeline to remove manual steps, and reduce pull request size, since large PRs are slower to review and riskier to ship.
If you’re moving from medium to high, the friction usually isn’t the deployment mechanism itself but the process around it. Move toward trunk-based development, using short-lived branches merged frequently rather than long-lived feature branches that accumulate conflicts. Invest in test coverage deep enough that engineers actually trust the pipeline rather than manually re-checking things it should already catch.
If you’re moving from high to elite, the remaining friction is almost always the last manual approval step. Use feature flags to decouple deployment from release entirely, meaning code ships to production but stays inactive until you choose to turn it on for users. This removes the pressure to bundle everything into a single “ready” release. Elite teams also typically get CI run times under ten minutes, since a slow pipeline caps how often deploying is even practical regardless of process maturity.
Improving lead time for changes
Lead time has several distinct phases, and improving it starts with identifying which phase is actually your bottleneck rather than optimizing the wrong one. The phases are typically: coding, code review, CI execution, and deployment itself. Most teams find that review wait time, not coding or testing, is their largest single component.
Concrete fixes by phase: for review bottlenecks, establish review service-level agreements and break work into smaller, more reviewable units. For CI bottlenecks, parallelize and cache test runs rather than running a full suite serially on every commit. For deployment bottlenecks, remove manual approval gates and automate what’s currently a human sign-off step. Pair or mob programming can also meaningfully shrink the coding-to-review handoff, since the code arrives already reviewed by a second person.
Read: DORA Metrics Benchmarks 2026: What Good Actually Looks Like by Team Size
Improving change failure rate
The instinct to slow down deployments when change failure rate is high is usually the wrong move. DORA’s research consistently shows that high performers achieve both speed and stability together, not one at the expense of the other. If your failure rate is high, the fix is almost always better testing and observability, not fewer deployments.
Practical steps: expand automated testing beyond basic unit tests to include integration and end-to-end coverage, since a comprehensive suite is your primary defense against shipping a bad change. Use canary deployments and feature flags to enable partial rollouts, so a bad change affects a fraction of users rather than everyone at once. Reduce PR size and strengthen code review practices, since larger, less-reviewed changes fail more often in production.
Improving recovery time
Recovery time, sometimes called mean time to recovery or failed deployment recovery time, is the metric most directly tied to operational maturity, and it’s the one DORA’s own research suggests matters more than change failure rate in practice. Achieving elite-tier recovery, generally under an hour, requires specific capabilities most teams build over years rather than weeks: alerting that fires within minutes of a production problem, not hours, backed by structured logging and distributed tracing for complex systems; the ability to roll back a bad deployment in minutes rather than requiring a manual fix; and documented runbooks for your most common incident types so recovery doesn’t depend on one specific engineer being available.
Instrumenting the measurement itself
Manually collecting DORA data through spreadsheets and CI logs is workable for a few weeks but becomes unsustainable quickly. The practical path: deployment frequency and lead time can typically be derived from data you already have in GitHub or GitLab, merge events, release tags, and workflow runs, without new instrumentation. Change failure rate and recovery time require linking deployments to incident tracking, whether that’s PagerDuty, Opsgenie, or even a well-maintained spreadsheet in the early stages. Start with one metric, typically deployment frequency since it’s the easiest to derive from existing pipeline data, and add the others over the following months rather than trying to instrument all four at once.
One current caveat: AI-assisted development complicates the picture
DORA’s own 2025 research shifted its annual reporting focus specifically to AI-assisted software development, and one of its central findings is that AI adoption improves throughput but simultaneously increases delivery instability for many teams. That means the improvement playbook above still holds, but teams adopting AI coding tools heavily should watch change failure rate and recovery time more closely than usual during that transition, since faster code generation doesn’t automatically come with equivalently faster or better testing discipline behind it.
Frequently Asked Questions
What’s the fastest DORA metric to improve first?
Deployment frequency is usually the quickest win for lower-performing teams, since automating an existing manual deployment process from monthly to weekly delivers a large relative improvement without requiring deep architectural change.
Should we slow down deployments if our change failure rate is high?
No. DORA’s research shows elite performers achieve high deployment frequency and low change failure rate simultaneously. Slowing down deployments to reduce failures typically just delays the same problems rather than fixing the underlying testing or observability gaps causing them.
How often should we review our DORA metrics?
A monthly review cadence works well for spotting genuine trends, since weekly data can be noisy and skewed by short-term factors like team absences or holidays. Quarterly reviews are useful specifically for assessing whether larger improvement initiatives, like a shift to trunk-based development, actually moved the numbers.
