Engineering Metrics & DORA
Measure engineering effectiveness with DORA metrics, flow metrics, and team health indicators without creating perverse incentives.
Engineering metrics provide signal about team effectiveness, delivery quality, and system reliability. Used well, they identify bottlenecks and guide improvement. Used poorly, they create perverse incentives and destroy psychological safety.
Measure to improve, not to judge. Track outcomes (deployment frequency, reliability) not outputs (lines of code, tickets closed). Treat metrics as diagnostic signals, not performance ratings. Expose metrics to the team, not to compare teams.
Workflow
- Track the four DORA key metricsDORA metrics correlate strongly with organizational performance and are the industry standard for engineering effectiveness.
- Add flow metrics for bottleneck discoveryDORA metrics tell you outcomes; flow metrics tell you where the pipeline is clogged.
- Measure reliability with SLOsDORA MTTR measures response; SLOs measure the customer's experience of reliability.
- Monitor team health metricsDelivery metrics can look great while the team is burning out-health metrics provide the leading indicator.
- Use metrics to drive improvement, not judgmentMetrics used for performance evaluation distort behavior (Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure").
Output Format
DORA dashboard (deployment frequency, lead time, CFR, MTTR), flow metrics per team, SLO dashboards per service, team health survey results.
Examples
DORA dashboard: Grafana panel querying CI/CD events: deployment_frequency = count of prod deployments per day (7-day rolling average)Error budget calc: SLO 99.9% → monthly budget = 0.1% × 43800 min = 43.8 min; current month downtime = 12 min → 72% budget remainingHealth survey question: "I feel safe raising concerns about problems in our team without fear of blame." (1=strongly disagree, 5=strongly agree)Edge Cases & Gotchas
- Deployment frequency gaming: engineers split changes into trivial micro-deployments to inflate the metric-review what's being deployed, not just frequency
- Different team contexts: platform teams have different cycle times than product teams; baseline per team type, not org-wide
- Lagging metrics mislead: high deployment frequency with high change failure rate is worse than low frequency with low failure rate-always read metrics together
When to Break These Rules
- Early-stage startups (<10 engineers) should track informally rather than invest in metrics infrastructure-the cost outweighs the signal until you have enough data volume.
Reference Files
DORA State of DevOps Report: https://dora.dev/research/Accelerate (Forsgren, Humble, Kim): https://itrevolution.com/accelerate-book/LinearB engineering metrics: https://linearb.io/Google SRE SLO chapter: https://sre.google/sre-book/service-level-objectives/