Metrics¶
Metrics exist to inform decisions, not to replace judgment.
The right metrics help you see patterns you would otherwise miss, catch problems early, and have grounded conversations about what is working and what is not. The wrong metrics—or the right metrics used badly—create perverse incentives, erode trust, and consume energy that could go toward building.
This section covers how to measure engineering effectively: what to track, how to interpret it, and how to avoid the common failure modes that turn measurement into theater.
Why Measurement Matters¶
Engineering is complex. Many important things—team health, code quality, sustainable pace—are not directly observable. You cannot manage what you cannot see, but in engineering, much of what matters is invisible by default.
Good measurement makes the invisible visible. It reveals:
- Whether you are getting faster or slower at delivering value
- Whether your systems are becoming more or less reliable
- Whether your team is thriving or burning out
- Whether quality is improving or quietly degrading
Without measurement, you rely on intuition and anecdote. These are valuable, but they are also biased, incomplete, and hard to communicate. Metrics provide a shared reference point for conversations that would otherwise be frustrating exercises in competing perceptions.
What This Section Covers¶
| Topic | Core Idea | Deep-Dive |
|---|---|---|
| Engineering Metrics | DORA metrics, cycle time, throughput, quality indicators—what to track and how | Engineering Metrics |
| Team Health Metrics | Engagement, sustainability, collaboration, psychological safety—the human side | Team Health Metrics |
These two domains—delivery effectiveness and team health—are complementary. Optimizing one at the expense of the other creates unsustainable systems. High delivery metrics with poor team health means burnout and attrition. High team health with poor delivery metrics means a pleasant team that does not ship.
Principles for Healthy Measurement¶
These principles apply to all metrics in this section:
Metrics are signals, not targets. The moment a metric becomes a target, it stops being a useful measure. People optimize for the number instead of the outcome it represents. Use metrics to understand reality, not to judge performance.
Team-level, not individual. Delivery and health metrics measure team and system performance, not individual productivity. Individual metrics destroy collaboration—people hoard work, avoid helping others, and optimize locally at the expense of the whole.
Trends over absolutes. Whether your cycle time is "good" matters less than whether it is improving, stable, or declining. Trends reveal whether your efforts are working. Absolute numbers require context that is often unavailable.
Pair quantitative with qualitative. Metrics tell you what is happening. Conversations tell you why. Always supplement numbers with direct feedback, retrospectives, and observation.
Fewer, better. A small set of metrics you actually review beats a large set you ignore. Choose metrics that answer important questions, and retire metrics that no one uses.
Transparent, not punitive. Metrics should be visible to the team being measured. They should spark conversations about improvement, not be used as weapons in performance reviews.
What Good Looks Like¶
You know your measurement approach is working when:
| Signal | What You Observe |
|---|---|
| Metrics inform decisions | You can point to decisions that were made differently because of what metrics revealed |
| Team understands the metrics | Anyone can explain what the metrics mean and why they matter |
| No gaming | People focus on outcomes, not on manipulating numbers |
| Balance maintained | You track both delivery and health; neither is sacrificed for the other |
| Trends are visible | You can show how metrics have changed over time and connect them to actions |
| Conversations happen | Metrics spark productive discussions about improvement, not defensive explanations |
What Usually Goes Wrong¶
| Anti-pattern | What It Looks Like | Mitigation |
|---|---|---|
| Goodhart's Law | The metric improves but outcomes do not; people game the measure | Focus on outcomes, not metrics; pair metrics with qualitative assessment |
| Measurement theater | Dashboards exist but no one looks at them; metrics are reported but not acted upon | Review metrics regularly; connect them to decisions; retire unused metrics |
| Individual targeting | Metrics are used to rank or punish individuals | Never use delivery metrics for individual evaluation; keep them at team level |
| Vanity metrics | Tracking lines of code, commits, or activity that does not correlate with outcomes | Choose metrics that matter; ask "what decision does this inform?" |
| Too many metrics | Dozens of dashboards, no clarity on what matters | Limit to 5-7 core metrics; sunset the rest |
| Health neglect | Delivery metrics tracked religiously; team health ignored | Explicitly measure and review health alongside delivery |
How to Use This Section¶
If you are setting up measurement for a team or organization, start with Engineering Metrics for the delivery side. It covers DORA metrics, cycle time, and quality indicators—the metrics most teams should track.
Then review Team Health Metrics for the human side. This covers engagement, sustainability, and psychological safety—the metrics that predict whether your delivery will continue.
Both pages include implementation guidance, review cadences, and copy-paste artifacts for getting started.
Related¶
- Engineering Metrics — DORA metrics, cycle time, quality
- Team Health Metrics — Engagement, sustainability, safety
- Metrics in Execution — Connecting metrics to daily work
- Continuous Improvement — Acting on what metrics reveal
- One-on-Ones — Where qualitative context for metrics often emerges