Engineering Metrics Standard¶
Standards only matter if we can tell whether they are followed and whether they help. This standard defines what we measure about how we deliver, and how the measurements are used.
Delivery metrics¶
Every project with a production deployment tracks the four DORA metrics, reviewed monthly (proposed - pending owner confirmation in #16) by the Tech Lead:
| Metric | Question it answers | Source |
|---|---|---|
| Deployment frequency | How often do we ship to production? | Release tags / deploy pipeline |
| Lead time for changes | How long from first commit to running in production? | First commit on the PR branch to the production release that contains it |
| Change failure rate | What share of releases cause a rollback, hotfix, or incident? | Release log, hotfix/ PRs |
| Time to restore | How long to recover from a production failure? | Incident records |
Flow metrics¶
Tracked from GitHub, to keep the review loop healthy:
- PR size - median changed lines (target: a few hundred or fewer - Pull Request Standard).
- Time to first review - target within one business day (Code Review Standard).
- CI duration - target under ~10 minutes (CI/CD Standard).
- CI reliability - share of failed runs that were flaky rather than real.
The merge gate, per pull request¶
On GitHub Free nothing stops a merge, so the gate is measured where it actually happens - on merged PRs, tracked monthly (proposed - pending owner confirmation in #16) per repository:
| Measure | What it shows |
|---|---|
| Merged with a failing required check | The merge gate skipped |
| Human approvals per PR (median, p95) | How often a person reviewed, especially on higher-risk paths |
| Merged with an unaddressed review thread | Automated or human review left unanswered |
Reverts and direct pushes to dev, staging, production |
Changes that bypassed or failed review |
Standards conformance¶
make doctorruns on every repository at least monthly (proposed - pending owner confirmation in #16); its failures are tracked as issues until fixed.- The org reviews conformance quarterly (proposed - pending owner confirmation in #16): repositories without the protection their plan allows (rulesets
where GitHub offers them, the local hooks otherwise), with individual collaborators, with failing required
checks on
dev,staging, orproduction, or behind the current template version.
How metrics are used¶
- To find bottlenecks in the system, never to rank or evaluate individuals. A metric used to judge people stops measuring anything.
- Trends matter more than single numbers. Compare a project with its own history, not with other projects.
- Each metric has a named source, so it can be reproduced rather than estimated.
Measure the system, not the people
If a number looks bad, ask what in the process makes it so.