Module performance_metrics 

Performance Metrics and Outcome Proxies

Performance, the P in SPACE (chapter 3.1), is the dimension most often confused with activity: it asks whether work actually produced a good outcome, not how much motion occurred. A team can be highly active and low performing, shipping constant small changes that never move an outcome, and the reverse is equally possible. Outcome is also rarely attributable to a single person or team — it emerges from collaboration, from decisions made months earlier, from market conditions no engineer controls — so SPACE researchers were explicit that performance should be measured at the system or team level using multiple, converging signals, never reduced to a single number or attributed to an individual.

Formula

Converging signal count      = count of independent signals indicating
                                positive performance (change failure
                                rate, defect-escape rate, adoption,
                                qualitative peer assessment, ...)
Sufficient converging evidence = converging signal count >= 2
    (no single signal is reliable alone)

Why it matters

No individual performance proxy is reliable enough to stand alone: a single metric can look good while quality quietly degrades, or look bad for reasons entirely outside a team’s control. Requiring several independent signals to agree before drawing a conclusion is what resists both accidental misreading and deliberate gaming of any one proxy — the same discipline chapter 5.3 applies to business-outcome attribution, applied here to the SPACE performance dimension specifically.

Example

use software_engineering::performance_metrics::{
    converging_signal_count, has_sufficient_converging_evidence,
};

// A single positive signal (adoption is up) is not enough on its own.
let adoption_only = [true, false, false];
assert_eq!(converging_signal_count(&adoption_only), 1);
assert!(!has_sufficient_converging_evidence(&adoption_only));

// Change failure rate down, defect-escape rate down, and adoption up
// all agree: two or more converging signals are trustworthy together.
let converging = [true, true, false, true];
assert_eq!(converging_signal_count(&converging), 3);
assert!(has_sufficient_converging_evidence(&converging));

Pitfalls

• Reducing performance to a single number — no individual proxy (velocity, adoption, a single quality metric) is reliable enough to stand alone.
• Attributing an outcome to one individual — software outcomes emerge from collaboration and prior work; individual attribution is usually false precision that discourages collaboration.
• Treating quality as separate from performance — a feature that ships on time but causes a wave of incidents did not perform well, even though an output-only view would count it as delivered.
• Ranking teams competitively on performance data — invites gaming and morale damage; the productive use is deciding where to invest or investigate, never a competitive ranking.
• Forcing a direct-outcome metric onto platform or enabling teams — their contribution is often several steps removed from any single customer-facing metric; measure their effect on the teams they enable instead.

Sources

• Chapter 3.3, Performance metrics and outcome proxies.
• Forsgren, Storey, Maddila, Zimmermann, Houck, and Butler, “The SPACE of Developer Productivity,” ACM Queue (2021).

Topic doc: software-engineering-metrics/locales/en-001/chapters/03-03-performance-metrics-and-outcome-proxies.md

Functions

converging_signal_count

The number of independent signals, out of those checked, that indicate positive performance.

has_sufficient_converging_evidence

Whether enough independent signals converge to trust a performance conclusion, per the chapter’s “no single one is reliable alone” principle.