Metrics and queries for development

What is worth measuring

Metric	Signals
Pull request cycle time	How long review takes — usually the biggest hidden delay
PR size	Large PRs get worse review; the correlation is strong
Build failure rate on `main`	Whether the trunk is healthy
Time to first review	Whether work sits unattended
Code churn	Repeated rewriting of the same area

Review latency is usually the bottleneck

Teams instinctively optimise build speed, which is visible on a dashboard. Time-to-first-review is often several times larger and rarely displayed — a two-minute build behind an eleven-hour review wait is not a fast pipeline.

Metrics that mislead

Metric	Why it fails
Lines of code	Rewards volume; deleting code is usually good
Commits per developer	Rewards splitting commits
Individual velocity	Punishes helping colleagues

The common thread: anything measuring an individual's output rather than the system's flow degrades collaboration, because helping someone else always lowers your own number.

Churn

High churn in one area means the design is not settled there. It is a prompt to investigate — the answer might be an unclear requirement, a missing abstraction, or a genuinely volatile domain — not a number to drive down.

Primary sources