The DORA metrics work for data teams. Most data teams aren’t measuring them.
DORA (DevOps Research and Assessment) gave software engineering four metrics that correlated with team performance across thousands of orgs. Deployment frequency. Lead time for changes. Change failure rate. Mean time to recovery.
The same logic applies to data pipelines. A pipeline change is a deployment. A bad model push is a failed change. A broken nightly run takes time to recover.
Here’s how I translate them for data:
- Deployment frequency: how often do new dbt models, schema changes, or pipeline updates ship to production?
- Lead time for changes: from “code committed” to “running in prod” for a typical data PR
- Change failure rate: percentage of deploys that cause an incident or require a rollback
- MTTR: when a pipeline breaks, how long until data is flowing correctly again?
The baseline I see at most scaleups: 1-2 deploys per week, 3-5 day lead time, 15-20% change failure rate, MTTR measured in days. That’s “low performer” territory in the DORA report.
Elite data teams I’ve worked with hit: multiple deploys per day, sub-day lead time, sub-10% failure rate, MTTR in hours.
Two things gate the jump:
- CI for data (schema tests, dbt tests, data contract checks). Without this, every deploy is a coin flip.
- Observability that catches problems before users do. Without this, MTTR includes the hours between “broken” and “noticed.”
If you’re starting, measure MTTR first. The conversations that surface around recovery time tell you most of what you need.
Of the four DORA metrics, which one would your team guess wrong about if I asked today?