How do you measure engineering excellence without gaming the score?

Audience and what this page is not

Audience: a CTO, engineering leader, or founder who needs a balanced definition of engineering excellence and a measurement approach that improves delivery, quality, and reliability together — without collapsing to one number that teams will game. This page is not legal advice. It does not certify that your organization is excellent, does not rank individuals, and does not substitute for your own engineering judgment.

Engineering excellence is not a regulation. No statute defines it. What follows separates legal requirements (none apply to this topic), regulator guidance (not applicable here), industry best practice and research frameworks (DORA, SPACE, SRE literature, ISO/IEC 25010), and ShipReady Metrics recommendations (SRM's own scoring choices, clearly labeled). Last verified 10 September 2026. Not legal advice.

Anti-Goodhart guidance — when the measure becomes the target

Goodhart's law applies directly: once a metric becomes a target, it stops measuring what you cared about. Deployment frequency rises when trivial deploys are counted. Lead time shrinks when the clock starts at merge instead of commit. Change failure rate drops when failures are reclassified. Satisfaction scores climb when the survey is optional and anonymous responses are scarce.

The discipline is pairing every metric with a counter-metric, reading trends and distributions rather than single absolutes, describing teams and systems rather than grading people, and changing definitions rarely and visibly. A number that moved because the definition drifted is not evidence of improvement.

• Never use delivery metrics alone — pair throughput (deployment frequency, lead time) with stability (change failure rate, time to restore).
• Never use activity counts alone — commits, PRs, and lines changed are SPACE Activity signals, not Performance.
• Never rank individuals by DORA or authorship share — the frameworks are team- and system-level by design.
• Publish the definition next to every number so a trend cannot be misread after a quiet definitional change.
• Treat benchmark tiers as orientation, not targets — DORA performance bands shift year to year and are survey-derived guidance, not standards.

Framework guidance versus SRM scoring choices

The table below labels each source. DORA, SPACE, the Google SRE book, and ISO/IEC 25010 are industry frameworks and research guidance — useful for choosing what to measure, not mandates. ShipReady Metrics applies its own weighting and coverage rules when it turns connected data into domain scores; those choices are SRM recommendations, not industry standards and not audit opinions.

Balanced scorecard example

The example below is illustrative — thresholds are recommendations for conversation, not standards. Replace the example values with your own baselines and trend them under fixed definitions.

What you need to do now

As of last verification on 10 September 2026, the steps below are operational preparation. They are not a certification, not a ranking, and not legal advice.

• Pick three to five signals spanning delivery, stability, quality, and people — not one hero metric.
• Write down the definition for each signal (numerator, denominator, window, production-only or not) before you publish a number.
• Pair every throughput metric with a stability counter-metric and review them in the same meeting.
• Separate framework guidance from vendor scores: DORA and SPACE tell you what to measure; your platform's weighting is a recommendation to inspect, not a standard to cite in diligence.
• The dora-metrics-explained guide on this site is the DORA definitions page. The measure-ai-developer-productivity guide on this site is the SPACE-aligned productivity page. The engineering-risk-score-explained guide on this site is the SRM composite methodology page.

Checklist

This is a question list for engineering leaders, not a grade and not legal advice.

• Do we measure both throughput and stability, not speed alone?
• Is every published metric accompanied by its definition and data coverage?
• Are we describing teams and systems, not ranking individuals?
• Do we have a counter-metric for every metric that could be gamed?
• Have we separated industry frameworks from our vendor's scoring choices?
• Are unmeasured domains visible as gaps rather than silent zeros?

Where this shows up in ShipReady Metrics

Signed-in Delivery Health (/scores/delivery-health) grades DORA metrics from connected CI and deployment sources. When a metric cannot be observed, it reads Not measured — not a fabricated value.

Signed-in domain scores in the Engineering Excellence family — Technical Debt, Security Readiness, IT Modernization, Lifecycle Risk, Delivery Health, Cloud Health — each compute from connected systems over eligible repositories. Repository scope affects which repos feed scoring; scope does not affect Compliance allowlists.

The engineering risk score explained on this site describes how SRM composites measurable signals with coverage-as-confidence. It is a ShipReady Metrics measurement, not an industry standard, not a certification, and not an audit opinion.

Signed-in AI ROI scoring and the AI-authored-code floor contribute context to AI-assisted engineering health; figures are estimates labeled as such, not audited financials. This product does not certify engineering excellence.

Primary sources (last verified 10 September 2026)

Every framework claim on this page is taken from one of these. If a later revision changes the guidance, the date above is how you can see we have not re-checked yet.

DORA research program: Accelerate (Forsgren, Humble, Kim; IT Revolution Press, 2018); Google Cloud State of DevOps Report 2024; dora.dev metric definitions — industry research and guidance, not legal requirements.

SPACE framework: Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, The SPACE of Developer Productivity, ACM Queue, 2021 — industry research guidance.

Site Reliability Engineering: Beyer et al., O'Reilly Media, 2016 — operational guidance literature, not a regulation.

ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — product quality model — international standard.

CISA Known Exploited Vulnerabilities catalog, FIRST EPSS specification, and CVSS v3.1 specification — issuing-body definitions for vulnerability prioritization signals referenced in the scorecard example.

ShipReady Metrics methodology page (/methodology) and what-we-measure page (/what-we-measure) — vendor documentation for SRM scoring choices, labeled SRM recommendations. Not legal advice.

Frequently asked questions