DORA Metrics for a Small Engineering Team, Without the Dashboard Sprawl

Each metric answers a specific question about your delivery process:

• Deployment frequency. How often you release to production. Count deploys per week, not per engineer.
• Lead time for changes. The time from a commit being merged to it running in production. Median, not average, because one stuck change skews the mean.
• Change failure rate. The share of deploys that cause a problem needing a fix, rollback or hotfix.
• Time to restore service. How long it takes to recover once a failure reaches users.

The first two describe speed, the last two describe stability. Reading them together is the point: a team that ships daily but breaks things every third deploy isn't fast, it's noisy.

You don't need a new platform to start. Follow these steps:

1. Pick one definition of a deploy. For most teams it's a successful run of the production deployment job. If you use GitHub Actions, that job's run history already has timestamps and the commit that triggered it.
2. Record the merge time for each change. The pull request's merge timestamp minus the production deploy time gives lead time.
3. Tag failures. When a deploy needs a rollback, hotfix or incident, mark it in your incident tracker with the deploy it came from. A simple label is enough.
4. Log restore times. For each incident, write the time it started and the time service was back.
5. Roll up weekly. Export to a spreadsheet and record the median lead time, deploy count, failures and median restore time.

When you outgrow the spreadsheet, an observability tool such as Datadog fits when you want to compare deploy times against latency and error trends. Confirm in a demo how it takes in deploy events.

Say a six-person team deploys eight times in a week, and two of those deploys needed a rollback. Change failure rate that week is two out of eight, one in four. On its own that number is alarming and meaningless, because eight deploys is a tiny sample. Track it over a month or a quarter before drawing a conclusion.

Now suppose lead time has crept from one day to four over two months. That's a more useful signal. Ask what changed: a slower test suite, a new manual approval step, larger pull requests waiting on one reviewer. Fix the largest cause, then watch the trend.

The method is the same each time: pick one metric that moved, ask what changed, make one change and measure again.

Small samples make ratios jumpy, so use rolling windows and look at trends instead of single weeks. Other traps are more human:

• Ranking individuals. These are team metrics. Using them to rate engineers invites gaming, such as splitting one change into ten to inflate deploys.
• Comparing teams with different systems. A team maintaining a regulated device shouldn't be measured against a marketing site.
• Counting deploys that don't matter. Documentation or config-only pushes inflate frequency.
• Ignoring context after a bad week. One large incident doesn't mean the process is broken. Look for the pattern.

Pair these with service-level objectives, so stability is defined by what your customers experience. See the SLO template for small engineering teams for one way to set them.

Match the fix to the metric:

• Low deployment frequency: shrink change sizes, and automate the manual steps between merge and release.
• Long lead time: look for waiting, not working. Queues for review, slow builds and approval gates are the usual culprits.
• High change failure rate: improve tests where failures cluster, add staged rollouts and make rollback a one-step action.
• Slow restore time: write runbooks for your most common failures, and rehearse a rollback so it isn't the first time under pressure.

Pick one metric per quarter to improve. If you're choosing monitoring tools to support this, the Datadog vs New Relic vs Dynatrace comparison can help you decide what fits a team your size.