The Engineering Manager Handbook (Development Manager) · The Engineering Manager's Job
Measuring Delivery Without Gaming It
Use DORA's delivery metrics and the SPACE framework to understand team performance — computed from real data — without turning them into targets.
Scenario
Example organisation: the 40-engineer product organisation's VP asks each engineering manager for "a productivity dashboard". One manager reports story points per engineer; another reports commits. Within a quarter, points inflate, PRs get split artificially, and reviewing others' work drops.
What you see on the team
- Metrics that improve while delivery doesn't.
- Engineers optimising for the metric (smaller commits, inflated estimates).
- Less collaboration: reviews and pairing don't "count".
- Distrust: engineers feel watched rather than supported.
The common mistake
Measuring individual activity and using metrics as targets, instead of measuring team-level delivery and experience to find improvements.
Why it happens
Activity data is easy to collect and looks objective. But once a measure becomes a target, people change behaviour to move the number. Research-backed alternatives exist. DORA's software delivery metrics measure throughput — change lead time, deployment frequency, failed deployment recovery time — and instability — change fail rate and deployment rework rate (DORA). The SPACE framework (Forsgren et al., 2021) adds that productivity has several dimensions — Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow — and recommends using several of them together, including people's own perceptions (GitHub's summary).
The playbook
Compute DORA metrics from real data — deploy and incident logs, not self-reporting:
from datetime import datetime as dt
import statistics
# (deployed_at, first_commit_at, failed?, recovered_at if failed, unplanned?) - example 2-week log
deploys = [
(dt(2026, 9, 1, 11), dt(2026, 8, 29, 15), False, None, False),
(dt(2026, 9, 2, 16), dt(2026, 9, 1, 10), False, None, False),
(dt(2026, 9, 3, 14), dt(2026, 8, 27, 9), True, dt(2026, 9, 3, 15, 10), False),
(dt(2026, 9, 3, 15, 30), dt(2026, 9, 3, 14, 50), False, None, True), # hotfix
(dt(2026, 9, 7, 10), dt(2026, 9, 4, 12), False, None, False),
(dt(2026, 9, 8, 13), dt(2026, 9, 7, 9), False, None, False),
(dt(2026, 9, 9, 17), dt(2026, 9, 2, 11), True, dt(2026, 9, 9, 20, 30), False),
(dt(2026, 9, 9, 20, 15), dt(2026, 9, 9, 18), False, None, True), # hotfix
(dt(2026, 9, 11, 11), dt(2026, 9, 10, 15), False, None, False),
(dt(2026, 9, 14, 12), dt(2026, 9, 11, 16), False, None, False),
]
working_days = 10
lead_hours = sorted((d - c).total_seconds() / 3600 for d, c, *_ in deploys)
failed = [(d, r) for d, c, f, r, u in deploys if f]
print(f"deployment frequency: {len(deploys) / working_days:.1f} per working day")
print(f"change lead time (median): {statistics.median(lead_hours):.0f} hours")
print(f"change fail rate: {len(failed) / len(deploys):.0%}")
print(f"failed deployment recovery time: "
f"{statistics.median((r - d).total_seconds() / 60 for d, r in failed):.0f} minutes (median)")
print(f"deployment rework rate: {sum(1 for *_, u in deploys if u) / len(deploys):.0%}")
Output
deployment frequency: 1.0 per working day change lead time (median): 49 hours change fail rate: 20% failed deployment recovery time: 140 minutes (median) deployment rework rate: 20%
Add the human dimensions: a short quarterly survey (satisfaction, perceived productivity, what slows you down) — SPACE recommends combining measures across at least three dimensions, including perception.
Use metrics for questions, not targets or rankings: "lead time doubled — where is work waiting?" Never compare individuals.
Review trends with the team, monthly, and pick improvements together.
Report to leadership at team level, with context and the improvements underway.
What to say
To a VP asking for individual productivity:
"Individual activity metrics get gamed and push people away from reviewing and helping each other. I'd like to report the four or five DORA delivery metrics per team plus a quarterly developer-experience survey. They're backed by research and tell us where to invest. Here's this month's: median change lead time is about two days (49 hours); our main lever is the review queue."
Trade-offs
- DORA metrics need tooling to compute reliably; start with what deploy and incident logs already give you.
- Survey data is subjective — that's the point; combine it with system data.
- Team-level metrics can still be gamed (e.g. trivial deploys); keep them as signals and look at trends and context.
Signals it's working
- Metrics prompt questions and improvement experiments, not blame.
- Engineers discuss the numbers openly and suggest causes.
- Lead time and recovery time improve over quarters.
- Nobody asks for individual rankings any more.
Key points
- DORA measures delivery throughput (lead time, deploy frequency, recovery time) and instability (change fail rate, rework rate).
- SPACE: use several dimensions, including people's own perceptions.
- Compute from real data, review trends with the team, report at team level.
- Never use metrics to rank individuals or as targets.
Practice questions
Name DORA's software delivery metrics and what they measure.
Answer
Throughput: change lead time, deployment frequency and failed deployment recovery time. Instability: change fail rate and deployment rework rate.
A VP wants story points per engineer. What do you propose instead?
Answer
Team-level DORA delivery metrics computed from deploy and incident data plus a regular developer-experience survey — combining several SPACE dimensions — used for improvement, never for ranking individuals.
What are the five SPACE dimensions?
Answer
Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow.
Open in the app to mark lessons complete, take notes and track your progress.