DORA Metrics for Mid-Market Engineering Teams
DORA metrics are the clearest read on engineering delivery performance, but most guidance is written for large platform teams. Here's how a 10-50 person engineering team can instrument DORA cheaply, benchmark realistically, and account for AI-assisted development shifting the baseline.
Most DORA metrics content is written for platform teams at companies with hundreds of engineers and dedicated SRE functions. If you're running a 10-50 person engineering team at a growing Australian business, that context doesn't map cleanly onto yours. This article right-sizes DORA for mid-market reality — what to measure, what good looks like at your scale, and how AI-assisted development is shifting the baseline.
What are DORA metrics?
DORA metrics are four measures of software delivery performance — deployment frequency, lead time for changes, change failure rate, and mean time to restore (MTTR) — developed by Google Cloud's DevOps Research and Assessment (DORA) program. They are the most widely validated proxy for engineering throughput and stability, derived from years of research correlating delivery behaviour with organisational performance.
The appeal of DORA is that it measures outcomes, not activity. It doesn't care how many story points your team closed or how many standups you ran — it cares whether software reaches production reliably and how fast you recover when it doesn't.
Why do these metrics matter more at mid-market scale, not less?
At 10-50 engineers, you don't have a platform team to absorb inefficiency, and you don't have the headcount to throw at manual QA or incident response. Every hour lost to a slow release process or a bad rollback is a much larger percentage of your total engineering capacity than it would be at a 500-person company.
Mid-market teams also tend to carry more legacy surface area per engineer — a monolith inherited from an earlier stage of the business, a handful of integrations nobody fully owns, deployment processes that grew organically rather than by design. DORA metrics give you an honest, comparable read on how much that legacy surface area is actually costing you in delivery speed, separate from headcount or backlog size.
The four metrics, defined
Deployment frequency is how often an organisation successfully releases to production. Lead time for changes is the time from code commit to that code running in production. Change failure rate is the percentage of deployments that cause a failure in production requiring remediation. Mean time to restore (MTTR) is how long it takes to recover service after a production failure.
Together, the first two measure throughput; the last two measure stability. DORA's research consistently finds that high-throughput teams are not trading away stability to get there — the two move together, because the practices that speed up delivery (small batch sizes, automated testing, fast feedback loops) are the same practices that reduce failure and shorten recovery.
What does "good" look like for a 10-50 person team?
DORA's published research groups organisations into four performance tiers — Elite, High, Medium, and Low — based on these four metrics. The tier definitions themselves aren't team-size-specific, but a lean mid-market team should read them with a different lens: reaching Elite on every metric simultaneously is less important than knowing which tier you're actually in, and closing the gap between where you are and where your delivery risk tolerance says you should be.
| Tier | Deployment frequency | Lead time for changes | Change failure rate | MTTR |
|---|---|---|---|---|
| Elite | On-demand, multiple deploys per day | Less than one day | Low (single digits to low teens, %) | Under one hour |
| High | Between once per week and once per month | One day to one week | Low-to-moderate | Under one day |
| Medium | Between once per month and once every six months | One week to one month | Moderate | Under one week |
| Low | Fewer than once every six months | More than one month | Higher, and often variable | More than one week |
A realistic target for most mid-market teams without a dedicated platform function is High performance across all four metrics, with Elite on deployment frequency and lead time achievable once CI/CD and trunk-based development are properly in place. Chasing Elite change failure rate and MTTR usually requires investment in observability and incident tooling that isn't worth prioritising until throughput is solid — there's little value in deploying multiple times a day if you can't tell when something breaks.
How do you instrument DORA metrics cheaply?
You don't need a dedicated internal platform team or an expensive engineering analytics suite to start measuring DORA. Deployment frequency and lead time can be derived directly from your CI/CD pipeline and version control history — most teams already have this data sitting in GitHub, GitLab, or Bitbucket, plus their deployment tool. Change failure rate and MTTR require you to tag production incidents against the deploy that caused them, which is a process discipline more than a tooling problem.
For a lean team, the pragmatic path is: instrument deployment frequency and lead time first, using free or low-cost dashboards built on your existing CI/CD metadata, and track change failure rate and MTTR manually in an incident log for a quarter before deciding whether dedicated tooling is worth the spend. This is the same incremental, foundation-first approach we recommend for data infrastructure work generally — instrument what you have before buying a platform to manage data you haven't yet proven you need.
The common failure mode is treating DORA metrics as a scorecard for individual engineers or teams to be judged against. That erodes trust fast and encourages gaming — smaller, less risky commits masquerading as "velocity," or incidents quietly reclassified to avoid hurting MTTR. DORA metrics are a diagnostic for the system, not a performance review input.
How does AI-assisted development change these baselines?
AI-assisted development is measurably shifting deployment frequency and lead time for teams that adopt it well, because code generation, test scaffolding, and code review assistance all compress the time between writing a change and having it ready to ship. Organisations report meaningfully faster commit-to-review cycles when AI tooling is embedded properly into the workflow — but the effect on change failure rate is more mixed, and depends heavily on whether test coverage and review rigour scale alongside output.
The practical implication for a mid-market team: if you introduce AI coding assistants without also strengthening automated testing and code review discipline, expect deployment frequency and lead time to improve while change failure rate quietly gets worse. The fix isn't to slow down AI adoption — it's to treat test automation and review process as prerequisites, not afterthoughts. This is a large part of what we help clients think through under AI engineering — building the guardrails that let AI-assisted throughput translate into real delivery improvement rather than a spike in production incidents.
It's also worth being honest about limits here: AI tooling helps most with the mechanics of writing and reviewing code, and least with the parts of lead time that are organisational — approval chains, change advisory boards, deployment windows tied to legacy infrastructure. If your lead time bottleneck is process rather than code generation, AI coding assistants won't move the number much. Teams working through application modernisation often find that decomposing a monolith and simplifying deployment pipelines moves DORA metrics further than any tooling change, because it removes the structural reasons releases are slow and risky in the first place.
Where should a mid-market team start?
Start by measuring your current state honestly for one quarter before setting targets. Pull deployment frequency and lead time from your existing CI/CD data, and start a simple incident log tied to deploys for change failure rate and MTTR. Once you know which tier you're actually in, you can make a deliberate call about which metric to invest in first — and whether the constraint is tooling, process, or architecture.
If you're weighing where AI-assisted development or platform investment fits into that roadmap, our AI product strategy work is designed for exactly this kind of prioritisation call. You can also browse our insights for related thinking on legacy modernisation and MLOps.
If you're exploring how to instrument or improve your DORA metrics, we can help — start with a conversation about where your delivery pipeline actually stands today.
Chris Kerr
Partner at Horizon Labs, an AI product consultancy and venture studio. A commercially focused product and technology leader with 20+ years building and scaling digital platforms, teams, and businesses across SaaS, travel, eCommerce, logistics and transport, and digital marketing — operating at the intersection of product, engineering, and data. Writes about platform strategy, AI transformation, modern data ecosystems, and the operational discipline that separates AI demos from AI products.
