openskills.info
Open Course

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

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