Stop tracking DORA metrics if you're a team of 12.
That's not a hot take for the sake of it. DORA metrics — deployment frequency, lead time for changes, change failure rate, and mean time to recovery — are genuinely useful. They've given the industry a shared language for measuring software delivery performance. The annual State of DevOps reports have produced real insight.
But if you're leading a small-to-mid-size engineering team and you're trying to figure out what to put on your dashboard, DORA is probably not where you should start. Here's why, and what to track instead.
Why DORA Metrics Miss the Mark for Small Teams
The DORA framework was built to measure DevOps maturity across large organizations. It answers the question: "How effective is our software delivery pipeline at scale?" That's a great question if you're running platform engineering at a company with 200 developers and a complex deployment infrastructure.
For a team of 5-15 engineers, though, these metrics either tell you nothing or tell you something you already know:
Deployment frequency — If you're deploying from a single main branch with CI/CD, your deployment frequency is basically "every time someone merges a PR." Congratulations, you're "elite" by DORA standards. But that doesn't mean you're shipping effectively. A team that deploys 20 times a week but takes 5 days to review each PR is not high-performing.
Change failure rate — Most small teams don't deploy enough changes to make this statistically meaningful. If you shipped 40 deploys last month and 2 caused incidents, is your 5% change failure rate a real signal or just noise? You won't know until you've collected six months of data, and by then your team and codebase have changed enough to make the baseline irrelevant.
Mean time to recovery (MTTR) — Critically important if you have incidents regularly. But most small teams running modern infrastructure have an incident every few weeks at most. Your MTTR is dominated by a handful of data points. One bad week skews the metric for months.
Lead time for changes — This one is actually useful, but it's a trailing indicator. By the time your lead time looks bad, you've been shipping slowly for weeks. You need the leading indicators that predict lead time problems before they show up.
None of this means DORA is wrong. It means DORA is solving a different problem than the one most small teams have. Your problem isn't "are we a mature DevOps organization?" Your problem is "why does everything take longer than it should, and where do I focus to speed up?"
The Metrics That Actually Move the Needle
Here are five metrics that give small-to-mid engineering teams actionable signal. You don't need all five — start with the first two or three and add from there.
1. PR Review Time
Time from PR opened to first review, and time from PR opened to merge. This is the single most actionable metric for most teams because it measures the bottleneck that compounds into everything else: waiting.
If your median time to first review is over 4 hours, you have a problem worth fixing. If it's over 8 hours, that's your top priority. Every other metric downstream — cycle time, throughput, developer satisfaction — improves when review time improves.
2. Cycle Time (PR Open to Deploy)
This captures the full delivery pipeline for a unit of work: how long from when a developer says "this is ready for review" to when it's running in production. It includes review time, feedback rounds, merge, and deployment.
Target: under 24 hours for standard PRs. Track the median, not the average. A healthy team might have a median cycle time of 8-12 hours with occasional outliers for larger changes.
3. PR Size
Measured in lines changed or files touched. Smaller PRs get better reviews, merge faster, and cause fewer incidents. It's a proxy for how well your team breaks down work.
If your median PR is over 400 lines changed, your team is batching too much work into single PRs. That directly causes slow reviews (nobody wants to review a 600-line diff), more merge conflicts, and lower review quality.
4. Review Distribution
Who is doing the reviews on your team? If one or two people review 60%+ of all PRs, you have three problems: a bottleneck (those people are overloaded), a bus factor risk (nobody else knows the code well), and a knowledge silo (the rest of the team isn't learning from review).
Track the percentage of reviews per team member. A healthy distribution doesn't need to be perfectly even, but no single person should account for more than 30-35% of reviews on a team of five or more.
5. Developer Experience (DX) Surveys
Not everything that matters can be measured from Git data. Run a quarterly pulse survey — 5-10 questions, takes 3 minutes to fill out. Ask about:
- How easy is it to get your PRs reviewed?
- How confident are you in the quality of reviews you receive?
- How much time do you spend on tooling friction vs. actual coding?
- How clear are priorities and requirements when you start a task?
DX surveys catch the problems that quantitative metrics miss: unclear requirements causing rework, flaky tests eroding trust, poor documentation slowing onboarding. They also give you signal on morale before it shows up as attrition.
Metrics That Don't Deserve Dashboard Space
Some metrics feel useful but actively mislead:
Lines of code. More code is not better. Some of the most impactful engineering work involves deleting code. Tracking lines written incentivizes bloat.
Commit count. Developers have wildly different commit habits. Someone who commits every 10 minutes and someone who commits twice a day might be equally productive. This metric measures style, not output.
PRs merged (without context). Ten small PRs that each fix a typo are not more valuable than one PR that redesigns a critical data pipeline. Raw count without size or impact context is misleading.
Story points velocity. Points are a planning tool, not a performance metric. Teams that track velocity as a productivity measure inevitably inflate their estimates to hit the number. You end up measuring estimation skill, not delivery capability.
How to Build Your Metrics Dashboard
Here's a practical approach that works for most teams:
Start with three metrics. Pick PR review time, cycle time, and one other from the list above. Three is enough to give you signal without drowning in data.
Review weekly as a team. Spend 5 minutes in your weekly sync looking at the numbers. Don't analyze deeply — just notice trends. "Review time went up this week. Anyone know why?" Often the answer is obvious: someone was on vacation, a big refactor landed, etc.
Act on trends, not individual data points. A single slow PR doesn't mean anything. Three consecutive weeks of increasing review time means something. Look for sustained patterns before making process changes.
Never use metrics to evaluate individuals. The moment developers feel that review time or cycle time is being used in performance reviews, they'll game the metrics. Use metrics to improve the system, not to judge the people in it. This is non-negotiable.
Reassess quarterly. Are the metrics you're tracking still the right ones? Has the bottleneck shifted? Maybe review time is great now but PR size has crept up. Rotate your attention to where the constraint is.
Measure What Matters to Your Team
The best engineering metrics are the ones your team actually looks at and acts on. A perfect DORA dashboard that nobody checks is worth less than a single metric — PR review time — that the team reviews every Monday and actively improves.
We built Revvie because we believe PR review time is the most actionable metric for most teams. It surfaces review health directly in Slack, where your team already works, so the data stays visible without adding another dashboard to your rotation. But whatever tools you use, start with the metric that's closest to the pain your team actually feels. That's where the leverage is.