DORA Metrics Baseline for Small Engineering Teams

DORA metrics measure five things: deployment frequency, lead time for changes, time to restore service, change failure rate, and deployment rework rate. The research behind them started in 2014, and the numbers that get quoted most, the "elite tier" figures, describe the top slice of a distribution built mostly from large organizations. A five-person team stacking itself against that top slice is comparing itself to companies with dedicated platform groups running hundreds of services, and that comparison is wrong on its face. Most small teams make it anyway, and it costs them: they either give up on the metrics entirely or chase a target built for a different species of company.

The fix requires something other than more DORA. It's reading the whole distribution instead of just the top row, then setting targets that match the size of the team actually doing the work.

What the published tier benchmarks actually look like across the full distribution

Four tiers, and here's how they break down. Elite teams deploy on demand, often multiple times a day, with lead time under a day, change failure rate under 5%, and service restored in under an hour. High performers deploy somewhere between once a day and once a week. Medium performers land between once a week and once a month. Low performers deploy less than once a month.

Now look at where the industry actually sits, not where the elite row implies it sits. The 2024 State of DevOps Report showed the high-performance tier shrinking from 31% to 22% year over year, while the low tier grew from 17% to 25%. Elite stayed roughly flat. That's the industry moving backward: the tier most teams aspire to is getting smaller, and the bottom tier is absorbing the difference.

Run the math on that current distribution, and a team deploying once a week with same-day recovery is performing meaningfully above the low tier. That's a genuinely strong result. It looks nothing like the "elite" row that gets pasted into slide decks, and treating that row as the bar to clear is where most teams go wrong before they've even started measuring.

Why applying enterprise benchmarks to a small team produces false signals

Deployment frequency is a count, and counts scale with team size. A team running one or two services with three engineers generates fewer deployable changes per week than an org running 200 microservices with 400 engineers. That's not a performance gap. It's arithmetic, and treating it as a skills problem is the first mistake.

Lead time works the same way, except the distortion runs deeper than headcount. On a two-person team, code review often means the only other engineer available looks at the change. No rotating review pool, no backup reviewer, no parallel path when that one person is out sick or heads-down on something else. The bottleneck is baked into the team's shape, not a sign the process is broken.

Time to restore service suffers a similar mismatch. Without an on-call rotation, a 2am incident might take three hours to resolve, not because the team lacks skill, but because nobody's paged, nobody's awake, and whoever eventually notices has to get oriented before doing anything. Set that against an org running a follow-the-sun rotation with a dedicated incident commander, and the raw number looks damning by comparison. It's a staffing reality, not a skills gap, and no amount of process tuning fixes a staffing reality.

Change failure rate gets distorted differently. Small teams often run a narrow test surface against a single production environment serving the whole product. One bad deploy can spike the rolling failure rate hard, because there's no segmentation to absorb the blow: no canary population, no partial rollout. A single incident can make a month look worse than it was.

The 2024 State of DevOps Report backs this up: run small, time-boxed experiments against a team's own baseline rather than chase industry averages. The framework is a diagnostic tool, not a scoreboard. The moment leadership starts writing OKRs off elite-tier numbers, teams start optimizing for the metric instead of the behavior behind it, and the diagnostic value is gone. That's the actual failure mode: not bad measurement, but measurement pointed at the wrong target.

Context-adjusted baselines small teams should realistically target, metric by metric

Deployment frequency. For a team running one to three services, once a day to several times a week is a strong target. Once a week is defensible, and it still places a team in the top half of the real world. The goal is small, consistent batches shipped over time, not infrequent, risky ones.

Lead time for changes. One day to one week is a realistic strong target for a small team. Under an hour is possible, but it typically requires CI/CD automation that takes meaningful setup effort, and there's no shame in not having built it. Clearing the more-than-a-week floor matters far more than chasing an hour.

Change failure rate. Under 10% counts as strong. Track it as a rolling four-week average, not a weekly snapshot, so one bad incident doesn't wreck the trend line. Before tracking anything, define what counts as a failure. A hotfix and a rollback are different events, and lumping them together muddies the number from day one.

MTTR. Under a day is realistic without a dedicated on-call rotation. Under an hour is achievable even at small scale, but it takes real alerting and a runbook someone actually follows under pressure. What matters is whether the response process is documented and repeatable, so recovery doesn't ride on one person's memory.

Deployment rework rate. No universal benchmark exists yet for this one. Track it as a trend, not against a target. A rising rework rate signals delivery instability no matter what the absolute number says. This is the metric where a small team gets ahead by instrumenting it early, before the org grows large enough that nobody agrees on what "unplanned" even means.

Most of this data already sits in tools a small team has running. A baseline across all five metrics is realistic within two to four weeks, using CI/CD logs, git metadata, and an incident log that already exists in some form, even if that form is a shared doc.

How AI-assisted development is shifting these baselines right now and what small teams should adjust for

More than three in four respondents in the 2024 State of DevOps Report said they use AI tools for daily development work. That's the environment the benchmarks now describe, whether the benchmarks have caught up to it or not.

The 2024 report found something genuinely tricky buried in the adoption numbers. A 25% increase in AI adoption correlated with a 7.5% improvement in documentation quality and a 3.4% improvement in code quality. At the same time, it correlated with a 7.2% decrease in delivery stability. Code gets better, delivery gets shakier, and both show up in the same dataset, at the same time.

Telemetry from Faros, drawn from over 10,000 developers, sharpens the picture: AI coding assistants produced 21% more completed tasks and 98% more merged pull requests per developer, but organizational delivery metrics stayed flat. Faros calls this the AI productivity paradox, and the mechanism isn't mysterious. AI tools inflate PR size, and bigger PRs pile up in the same review queue that used to handle smaller batches. The same review queue that handled smaller batches now handles much larger ones, and that queue backs up.

That conflicts directly with the small-batch discipline that drives healthy DORA numbers in the first place. If a small team adopts an AI coding tool and sees deployment frequency dip or change failure rate creep up in the following weeks, don't read that as a red flag on the team. It's PR size inflation clogging the review pipeline, the expected early cost of adoption.

The practical move is to watch PR size and review cycle time alongside the five DORA metrics whenever an AI tool gets introduced. If throughput rises while stability falls, invest in review capacity and pipeline throughput. Pushing deployment frequency even higher and hoping stability catches up on its own is the wrong instinct, and it's the one most teams reach for first.

How to instrument DORA measurement without a dedicated platform engineering team

None of this requires buying a platform product on day one. Most teams can stand up a working baseline in two to four weeks using tools already installed.

Deployment frequency comes almost free. GitHub Actions, GitLab CI, and CircleCI all log pipeline runs natively, though CircleCI needs an extra deploy marker configured before it'll show deployments in a dedicated dashboard. Either way, it's counting events per week per service, not building new tracking infrastructure.

Lead time is a subtraction problem. Git commit timestamps against deployment event timestamps give the raw interval, and most CI/CD platforms surface that through built-in analytics or a simple query against the deployment log.

MTTR starts as low-tech as a shared doc or a Slack channel with timestamps on when an incident started and when it resolved. That's genuinely sufficient at small scale. Tools like PagerDuty or Grafana are worth adopting once incident volume justifies the automation, but they're not a prerequisite for getting a baseline.

Change failure rate needs a definition before it needs a dashboard. Decide what counts as a failure, such as a rollback, a hotfix within some window, or a user-reported incident. Then count failed deployments against total deployments over a rolling window.

Deployment rework rate needs the same discipline. Label unplanned deployments triggered by production incidents separately from planned releases, and track the ratio of unplanned to total. A manual label in the deployment log is enough to start.

DORA's research also pushes teams to track developer experience alongside these five numbers: burnout rates, onboarding time, psychological safety on the team. A team hitting strong delivery numbers while quietly burning out its engineers is borrowing against next quarter, not building something durable.

A PaaS that deploys directly into a team's own AWS, GCP, or Azure account tends to surface deployment frequency and lead time data as a natural byproduct of how it runs the CI/CD pipeline. Teams already running that kind of setup often find the instrumentation question mostly answered before they go looking for a metrics tool at all.

Turning the baseline into an improvement loop rather than a report card

The core DORA recommendation is consistent: run small, time-boxed experiments against a team's own baseline. The comparison that matters is this quarter against last quarter, not this team against the elite tier in a report built from a very different population.

Pick the single metric doing the most damage and treat it as the one lever to pull for a sprint cycle. Trying to move all five at once spreads effort thin and makes it impossible to tell which change caused which result.

Lead time stuck over a week almost never means slow coding. It usually means review queue congestion or an overbuilt deployment gate, and the fix is process work: smaller PRs, clearer review ownership, fewer approval hoops. Change failure rate that stays persistently high often points to gaps in pre-production validation. A staging environment that actually mirrors production, plus a pre-traffic hook for database migrations, closes most of that gap. Deployment frequency stuck at once a month is almost always fear dressed up as caution, and that fear usually traces back to a lack of rollback capability. Feature flags and automated rollback on failed health checks lower the cost of a bad deploy enough that shipping stops feeling risky.

The research case for DORA holds regardless of team size: these metrics are diagnostic indicators of delivery health and team sustainability. What changes for a small team is scale. A team's own baseline, tracked quarter over quarter, is what counts as real progress, not a number lifted from a report describing a different kind of company.

Track developer experience in parallel with all of this. A team that improves its DORA numbers by piling on process pressure hasn't solved anything. It's traded a delivery problem for a retention problem, and retention problems take longer to show up and cost more to fix. The point of the whole exercise is faster, steadier delivery without wearing down the people doing the delivering.