After this lesson, you will be able to: Reason about engineering metrics that actually matter (DORA: cycle time, deployment frequency, MTTR, change failure rate) and avoid the vanity-metric trap.
Engineering teams are increasingly measured. This lesson covers the metrics that correlate with high-performing teams, the metrics that don't, and the trap of optimising for the wrong number.
From the DORA research program at Google: the four metrics that correlate with high-performing engineering teams. 1. Deployment frequency: how often you deploy to production. Elite teams deploy multiple times per day. 2. Lead time for changes: time from code committed to running in production. Elite teams: under 1 day. 3. Change failure rate: % of deploys that cause an incident. Elite teams: 0-15%. 4. Mean time to recovery (MTTR): how long after an incident starts until it's resolved. Elite teams: under 1 hour.
Lines of code measures activity, not output. Story points completed measures pretend currency. Hours worked measures effort, not impact. The DORA four measure system-level outcomes: how fast can the team ship safely, and how fast can they recover when they break something. They're also balanced: optimising any one in isolation hurts another. Pushing deploys more frequently with broken tests increases change failure rate. Recovering fast without root-cause means MTTR is low but the same incident keeps happening. The four together are the system.
Deployment frequency: count GitHub deployments (or your deploy log) per week. Lead time: timestamp of commit (in GitHub) minus timestamp of deploy. Change failure rate: count of incidents tagged 'caused by deploy X' / count of deploys. PagerDuty or a manual log works. MTTR: incident start timestamp minus resolution timestamp. PagerDuty tracks this automatically. Spreadsheet is fine to start. Tools like Sleuth, Swarmia, LinearB automate it.
Lines of code committed. Encourages verbose code. Number of commits. Encourages tiny commits that mean nothing. Story points completed. Easily inflatable. Hours worked. The wrong currency for knowledge work. Number of bugs opened. Penalizes thorough QA. Number of PRs merged. Encourages many tiny PRs. If a metric can be gamed without producing value, your team will eventually game it. Pick metrics where gaming = doing the right thing.
Measuring individual engineers on DORA metrics. The metrics are SYSTEM metrics, not personal performance. Misuse destroys teams. Optimising one metric at the expense of others. Deploy 10x a day without tests; change failure rate explodes. Ignoring qualitative signals. Engineer happiness, retention, on-call burden are not in DORA but matter as much. Treating elite-tier numbers as universal. A bank should NOT deploy 5 times a day to the core ledger. Elite for a SaaS startup; reckless for a clearing house. Skipping the conversation about what to MEASURE. Engineers given metrics they didn't help define resist them; engineers who helped pick them defend them.
Pick the most useful first investigation.
Sign in and purchase access to unlock this lesson.