Software teams generate an ocean of numbers — commits, tickets, story points, lines of code — yet the thing we actually care about, performance, stubbornly resists measurement. This post is about that gap: why individual output is so easy to misjudge, what signals are worth watching, and how to measure teams without corrupting the very behavior you want.
Every engineering manager eventually faces the same uncomfortable question: how do we know if we're doing well? And its more dangerous cousin: how do we know if this person is doing well?
Software is one of the hardest disciplines to measure. Output is invisible, quality is deferred, and the most valuable work — preventing a disaster, simplifying a design, unblocking a teammate — often leaves no trace in any dashboard. Meanwhile, technical debt quietly accumulates interest, and nobody can quite prove it until velocity collapses.
This post walks through what actually works: the frameworks, the key performance indicators (KPIs) worth tracking, how to measure technical debt specifically, and how to approach the parts that resist numbers entirely.
The first rule: Goodhart's Law
Before any metric, internalize Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."
Lines of code, commit counts, story points closed, pull requests (PRs) merged — every one of these has been tried, and every one has been gamed, usually unintentionally. Measure PRs merged and you get smaller, noisier PRs. Measure story points and estimates inflate. Measure bug counts and bugs get reclassified as "improvements."
This doesn't mean metrics are useless. It means metrics are thermometers, not steering wheels. They tell you where to look and ask questions; they should never directly determine rewards, rankings, or punishments. The moment a metric decides someone's bonus, it stops describing reality.
Team-level measurement: DORA and SPACE
DORA metrics
The four DORA (DevOps Research and Assessment) metrics, from the Accelerate research, remain the best-validated team-level indicators, because they measure the system, not individuals, and they balance speed against stability:
| Metric | What it measures | Dimension |
|---|---|---|
| Deployment frequency | How often you ship to production | Speed |
| Lead time for changes | From commit to running in production | Speed |
| Change failure rate | Percentage of deployments causing incidents or hotfixes | Stability |
| Mean time to recovery (MTTR) | How fast you restore service after a failure | Stability |
The genius of DORA is the pairing: two speed metrics and two stability metrics. A team gaming deployment frequency by shipping recklessly will see its change failure rate expose it. You cannot look good on all four without genuinely being good.
If you're on GitHub or GitLab, most of this is extractable from your existing data: deployment events, merge timestamps, revert/hotfix labels, incident tickets. GitLab has DORA dashboards built into Ultimate; on GitHub you can derive them from Actions and deployment application programming interface (API) data, or use tools like Sleuth, LinearB, or Swarmia.
SPACE framework
DORA measures delivery; the SPACE framework measures the humans doing the delivering. It deliberately spans five dimensions so no single number dominates:
- Satisfaction and well-being — surveys, retention, burnout signals.
- Performance — outcomes (did the feature move the needle?), not output.
- Activity — volume of work, useful only as context, never as a score.
- Communication and collaboration — review turnaround, knowledge sharing, discoverability of docs.
- Efficiency and flow — uninterrupted focus time, handoffs, waiting states.
The rule of SPACE: always combine metrics from at least three dimensions, and always include at least one perceptual (survey-based) measure. Perception data is not "soft" — a developer saying "our build is painfully slow" is a measurement.
Measuring technical debt
Debt is where "measure the immeasurable" gets concrete. You can't put a single number on it, but you can triangulate with several proxies:
Static analysis debt ratio. Tools like SonarQube estimate remediation effort versus development cost (the "technical debt ratio"). The absolute number is questionable; the trend is valuable. If the ratio climbs quarter over quarter, you're borrowing faster than you're repaying.
Churn × complexity hotspots. The most actionable debt metric there is. Cross-reference files that change most often (git log) with files that are most complex (cyclomatic complexity, file size). A complex file nobody touches is dormant debt — ignore it. A complex file changed weekly is where your bugs, slow reviews, and developer misery live. Tools like CodeScene automate this; a script over git log --format='' --name-only plus a complexity report gets you 80% of the way.
Interest paid. Debt matters because of its interest: the ongoing tax on every change. Track the share of engineering time going to unplanned work — bug fixes, hotfixes, incident response, "why does this take three days" tasks. If 40% of your sprint is unplanned work, that's your interest rate, and it's an argument any stakeholder understands.
Debt registry. Keep an explicit, lightweight inventory: each known debt item, its estimated cost to fix, and — crucially — its estimated ongoing cost of not fixing. This converts vague grumbling ("the auth module is a mess") into a prioritizable backlog and makes repayment visible and celebrated instead of invisible.
Trend metrics that keep you honest:
- Test coverage trend (not the absolute number — a stable 70% with meaningful tests beats a gamed 95%).
- Build and continuous integration (CI) duration trend.
- Time-to-onboard: how long until a new hire ships confidently. Slow onboarding is debt made flesh.
- Dependency freshness (how far behind latest majors you are).
Individual measurement: proceed with extreme caution
Here's the uncomfortable truth backed by both research and scar tissue: stack-ranking individuals by metrics reliably destroys teams. It rewards visible solo output and punishes exactly the behaviors that make teams great — reviewing others' code carefully, mentoring, writing docs, doing glue work, taking on the gnarly refactor nobody wants.
So what can you do?
Measure impact, not output. The question is never "how many PRs?" but "what changed because this person was here?" Did the checkout flow's error rate drop? Did the team's review turnaround improve after they streamlined the process? Impact is narrative plus evidence, assembled by the person and their manager together — not scraped from a dashboard.
Use metrics as conversation starters in one-on-ones (1:1s). "I noticed your review turnaround went from hours to days — is something blocking you?" is healthy. "Your review turnaround is below target" is poison. Same data, opposite effect.
Look at multiplier behaviors. The strongest engineers often show up in other people's metrics: teammates whose PRs they reviewed ship with fewer defects, juniors they mentor ramp up faster, systems they designed generate fewer incidents. Peer feedback (structured, periodic, specific) captures this far better than any tool.
Watch for the glue work. Someone is keeping the CI green, updating dependencies, answering questions in Slack, maintaining the shared component library. This work is essential and metric-invisible. If you don't deliberately account for it, you will systematically undervalue — and eventually lose — the people doing it.
Measuring the immeasurable
Some things genuinely resist quantification: code quality judgment, architectural taste, psychological safety, trust. Techniques that work:
Developer experience (DevEx) surveys. Quarterly, short, consistent questions: "I can get code reviewed quickly," "I'm confident deploying on a Friday," "our codebase is easy to work in," each on a 1–5 scale. Individual answers are opinions; trends across quarters are data. This is how you measure morale, confidence, and perceived debt before they show up in attrition.
Retro themes as signal. Tag retrospective items over time. If "flaky tests" appears in six consecutive retros, that's a measurement — arguably a louder one than any dashboard.
Incident narratives. Blameless postmortems, read across a quarter, tell you more about systemic health than MTTR alone: are the same components failing? Are fixes structural or band-aids?
The Friday-deploy test. A wonderfully compressed proxy: would your team deploy at 4pm on a Friday without anxiety? The honest answer encodes your test quality, rollback capability, observability, and confidence in one bit.
Proxy triangulation. For anything unmeasurable, find three imperfect proxies pointing at it from different angles. "Code quality" alone is unmeasurable — but review comment density, defect escape rate, and a survey question about codebase confidence together sketch its outline. No single proxy is trustworthy; agreement between three is.
A practical starter kit
If you're starting from zero, don't build a metrics empire. Pick this minimal set and run it for two quarters:
- Team: the four DORA metrics, plus percentage of unplanned work.
- Debt: churn × complexity hotspot report (monthly), CI duration trend, a living debt registry.
- People: a five-question quarterly DevEx survey, plus structured peer feedback twice a year.
- Individual: none on a dashboard. Impact narratives and 1:1 conversations only.
Then apply the meta-rules:
- Trends over absolutes. A number without a time series is trivia.
- Pair every speed metric with a stability metric.
- Metrics inform questions; humans make judgments.
- Never tie a raw metric to compensation.
- Re-evaluate the metrics themselves every six months — measures decay as people adapt to them.
Closing thought
The goal of measurement in software isn't precision — it's earlier, better conversations. A good metrics setup doesn't tell you who to promote or fire; it tells you where friction is accumulating, which debts are charging the highest interest, and which questions to ask before problems become crises. Measure the system relentlessly, measure the team carefully, and measure individuals almost not at all — talk to them instead.
References
- Goodhart's Law — Wikipedia
- Accelerate and the DORA research program — DevOps Research and Assessment
- The SPACE of Developer Productivity — Forsgren, Storey, Maddila, Zimmermann, Houck & Butler, ACM Queue (2021)
- Understanding measures and metrics: technical debt ratio — SonarQube documentation