Engineering Metrics
Engineering metrics are measures that help a software team understand how it delivers, operates, and improves software. They reveal system behavior over time; they are not a productivity score for individual engineers.
itEngineering leadership and delivery management | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Engineering Metrics
Engineering metrics are a way to make a software delivery system visible without pretending that people are vending machines with commit counters. They describe how a service moves from a committed change to production, and what happens when that trip goes badly. The number is not the point. The decision it helps a team make is the point, which is less glamorous but has the advantage of being useful.
Start with one application or service and a question such as where changes wait, whether recovery is improving, or whether production failures are generating rework. Then decide what counts as a production deployment, a failure, and a recovery. Those boundaries sound administrative until two charts disagree. At that moment they become the small hinges on which a large argument swings.
The DORA lens keeps two ideas in the same room: throughput, or how changes move, and instability, or how deployments behave after release. Change lead time and deployment frequency say something about movement. Change fail rate, failed deployment recovery time, and deployment rework rate say something about the consequences. A service can deploy often and still be producing recovery work. It can fail rarely because it releases rarely. Numbers are annoyingly capable of telling the truth while still leaving out the reason.
The SPACE framework supplies the missing human dimension: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. A pull request count can describe activity. It cannot settle whether work is sustainable, whether collaboration is healthy, or whether the delivered change was useful. This is good news for everyone who has ever suspected that a line chart was not an adequate biography.
The operating move is modest: record a baseline, review the delivery trend with the people closest to the work, choose one candidate constraint, make one bounded change, and measure the same system again. If the trend and the team disagree, inspect the disagreement. The chart is evidence, not a judge wearing a very small hat.
For the compact definitions and review sequence, open Cheatsheet. Slides shows the relationships among throughput, instability, and team context. Practice turns the definition work into a repeatable technique, while the Exercise gives you a small event set to calculate and review. Field Notes covers the traps that appear after a dashboard looks finished. Reference leads back to the DORA and SPACE sources when the local definitions need more depth.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://dora.dev/guides/dora-metrics/
Supports
- DORA delivery performance as throughput and instability
- Definitions of change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate
- DORA guidance that speed and stability are not inherently a trade-off
- Service-level use, trend interpretation, and quizzes 1 through 4, 6, and 7
- The first reference-link rationale
- https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/
Supports
- SPACE dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow
- Developer productivity as multidimensional rather than one metric or dimension
- Activity signals as an incomplete view of productivity
- Quizzes 1, 5, and 7 and the third reference-link rationale
- Timeline event for the February 2021 SPACE publication
- https://dora.dev/research/2017-and-earlier/
Supports
- Publication history for the 2014, 2015, 2016, and 2017 State of DevOps Reports
- Timeline events for the earlier Puppet and DORA research partnership
- https://cloud.google.com/blog/products/devops-sre/new-research-what-sets-top-performing-devops-teams-apart
Supports
- Timeline event for DORA's 2018 availability measurement research
- https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
Supports
- Timeline event for the September 2020 Four Keys project
- Practice technique and exercise event chains linking commits, deployments, incidents, and recovery
- Need for explicit definitions when calculating delivery measures from system records
- https://cloud.google.com/blog/products/devops-sre/supercharge-your-devops-practice-with-sre-principles
Supports
- Timeline event for DORA's 2021 reliability terminology
- https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now-out
Supports
- Timeline event for the 2022 delivery-performance clusters
- https://research.google/pubs/developer-productivity-for-humans-a-human-centered-approach-to-developer-productivity/
Supports
- Timeline event for the 2023 human-centered developer productivity publication
- https://linearb.io/platform/engineering-metrics
Supports
- LinearB Landscape entry and its engineering-metrics capabilities
- https://www.swarmia.com/product/engineering-metrics/
Supports
- Swarmia Landscape entry and its DORA and SPACE-oriented engineering metrics
- https://www.sleuth.io/metrics/
Supports
- Sleuth Landscape entry and its deployment, incident, and DORA metric tracking
- https://jellyfish.co/platform/engineering-management-platform/
Supports
- Jellyfish Landscape entry and its delivery-management, allocation, and team-health context
- https://devlake.apache.org/docs/DORA/
Supports
- Apache DevLake Landscape entry and project-level DORA event configuration
