Engineering without measurement is management by opinion. Story points, velocity and burndown measure effort, not outcome. The board decides based on timeline, cost and margin. The gap between what engineering reports and what the business needs to know is where technology investment decisions lose credibility. More headcount looks like the solution when nobody measures where time is being consumed.
Subcapability 04 of 04 · High Performance Teams
Engineering Metrics & DORA
The four engineering metrics that correlate with organizational performance and shift management from narrative to data, connecting delivery velocity to financial results.
What is at stake
The board asks how long it takes for a change to reach the user. Engineering has no answer with a number. It knows it is "a few weeks." It knows it "depends." Without a measurement of delivery flow, every technology investment decision is made based on the intuition of who requests and the intuition of who approves. The cost of that imprecision goes into the IT budget that grows without clear results.
What it is, in practice
How we work
Installation of the four delivery flow metrics
We implement collection of the four engineering metrics in each pilot team, connecting them to existing pipeline and incident management tools, so the numbers are generated automatically from real work, not from manual data entry.
Baseline and benchmark per team
We establish the current baseline for each metric per team, produce the comparison with high, medium and low maturity performance ranges established by software engineering research, and identify the highest-impact levers for each specific team.
Executive dashboard with economic translation
We build a C-Level reading dashboard that translates deployment frequency, change lead time, failure rate and restoration time into financial impact language: revenue that did not reach the user due to wait, incident cost from failure rate, and downtime cost from restoration time.
Root cause diagnosis of below-expectation performance
When a metric is consistently outside the expected range, we diagnose the root cause: manual approval process adding wait time, fragile pipeline accumulating build time, dependency on another team blocking the flow, or excess load reducing quality and raising failure rate.
Quarterly evolution with metric-level goals
We set quarterly goals per metric for each team, connect the goal to the lever identified in the diagnosis, and track progress with monthly reviews that C-Level reads alongside business results.
Measurable gains
What changes in the result when this subcapability matures.
Change lead time from commit to production
Continuous lead time measurement exposes where the approval process, the pipeline queue or another team's dependency is adding wait to the delivery flow. Reducing this number has a direct impact on the speed at which new capability reaches the user.
Change failure rate and remediation cost per incident
A persistently high change failure rate indicates problems in automated tests, in the review process or in a deployment frequency so low that it accumulates risk in each batch. Reducing the rate reduces remediation cost and protects team confidence in the deployment process.
Service restoration time after a deployment incident
High restoration time indicates a lack of runbooks, absence of rollback automation or a team without context to act quickly. Measuring and reducing this number has direct impact on downtime cost and on the reliability the business can promise the customer.
Credibility of the technology investment argument in the board
With the four metrics installed and read by C-Level, the technology investment argument gains a number and a connection to financial results. The budget request to improve the pipeline has an answer when the team shows that each week of change wait time costs X in delayed revenue.
Frequently asked questions
Why these four specific metrics and not others?
Because longitudinal research across software organizations in different sectors, sizes and geographies identified these four as the ones that correlate most consistently with organizational outcomes: revenue growth, profitability, customer satisfaction and employee satisfaction. Other metrics like story points and velocity measure activity, not outcome. The four engineering metrics measure the delivery flow of value and system stability, which are the two factors with a direct connection to business results.
How do you collect the four metrics without a manual process?
Most pipeline and incident management tools already have the necessary data. Deployment frequency and change lead time come from pipeline history with commit timestamp and deploy timestamp. Change failure rate comes from crossing deployments with incident openings in the same time windows. Restoration time comes from incident management with open and close timestamps. Instrumenting existing tools is the first step, not buying a new observability tool.
What performance range do you expect from mature teams?
High maturity teams deploy multiple times a day, have change lead time under one hour, change failure rate below 5% and service restoration time under one hour. Low maturity teams deploy monthly or less frequently, have lead time in weeks, failure rate above 45% and restoration time of a day or more. The distance between the two extremes is one to two orders of magnitude and is reducible with systematic work on process, platform and topology.
How do you prevent the team from optimizing the metric instead of the outcome?
By using the metrics as diagnosis, not as individual targets. The risk of turning the metric into a target is that the team finds ways to hit the number without achieving the outcome. Deployment frequency that rises because the team started making smaller and safer deployments is good. Deployment frequency that rises because the team artificially split deployments to count more events is bad. Reading the four metrics together, with output quality context, is what keeps the diagnosis honest.
How long does it take to have the metrics installed and visible to C-Level?
Basic instrumentation with automatic collection of the four metrics in two or three pilot teams can be operational in four to six weeks. The C-Level reading dashboard with translation to financial impact takes another two to four weeks of configuration and calibration. Within one quarter, C-Level has the first real baseline and the technology investment argument shifts from narrative to data.
Other subcapabilities in this capability
Team Topologies
Four team types and three interaction modes that apply Conway's Law intentionally, eliminate invisible coordination cost and multiply delivery throughput without adding headcount.
Ownership & Autonomy
End-to-end ownership with autonomy calibrated by alignment that replaces one-off heroism with predictable results and eliminates the hand-off where invisible quality cost accumulates.
Cognitive Load Management
Three cognitive load types applied to team design that reduce extraneous load, free space for real work and turn an overloaded team into one that delivers predictably.
Want clarity on where to invest first?
A complete technology capability assessment with an evolution roadmap connected to financial result.