Here is a question I ask engineering leaders when they tell me their team is "doing fine": how long does a pull request sit before someone reviews it? Most cannot answer within a factor of three. They know it feels slow lately. They know one team is faster than another. They do not have a number, and without a number they do not know whether last quarter's process change helped, hurt, or did nothing at all.
That is the case for measuring engineering metrics, in one paragraph. Not because a dashboard makes anyone faster, but because without a baseline every improvement effort is a guess, every retrospective is a debate between whoever speaks loudest, and every conversation with the CFO about headcount is you asking for trust you cannot back up. This post makes the case properly, addresses the objections (some of which are good), and gives you a concrete first week. It is the "why and how to start" post. If you already measure and want to know which five metrics matter most, read improve productivity with just these 5 engineering metrics instead.
The problem with not measuring is not ignorance, it is drift
Teams that do not measure are not clueless. They have a rough mental model of how work flows, and it is usually right in the broad strokes. The problem is that the model was built once and never updated.
The review process that worked at fifteen engineers is quietly taking two days per PR at forty. The CI suite that took eight minutes last spring takes twenty-two now, and everyone adjusted their habits around it without anyone deciding to. Three people are doing sixty percent of the reviews, and they are the three people you are most worried about burning out. None of this shows up in a standup. All of it shows up in the data, and it shows up months before it shows up in attrition.
Drift is the enemy, and drift is invisible without a baseline. That is the whole argument for starting today rather than next quarter: the baseline you take now is the one you compare against later, and you cannot retroactively measure what you did not record. (You can, actually, for anything that lives in git and your CI system, which is a point I will come back to.)
What measurement actually buys you
Three things, in order of how quickly they pay off.
Faster diagnosis. When something feels slow, a handful of flow metrics tells you where the time is going in an afternoon instead of a quarter. If cycle time is up, is it coding, review pickup, review itself, or the wait to deploy? Each of those has a different fix, and guessing wrong costs a month. We broke down that decomposition in cycle time: the DORA metric that actually changes behavior.
Evidence for decisions you are already making. You are going to reorganize teams, buy tooling, add reviewers, split a monolith, or cut a process. Doing that with a before-and-after number is the difference between "we think it helped" and "review pickup time fell from 19 hours to 6." The second sentence gets you the next budget.
A shared language with people who are not engineers. Your CEO does not care about story points. They do care that the time from "engineer starts" to "customer has it" dropped by a third, and that the rate of changes that had to be rolled back did not go up. Metrics that map to those two ideas end the "what does engineering actually do all day" conversation permanently.
The objections, and which ones are right
I have heard every objection to engineering metrics, and about half of them are correct. Take them seriously.
"Metrics get gamed." True, if you attach them to individuals and to consequences. A metric that determines a promotion will be optimized for, and the optimization will not be the behavior you wanted. The fix is not to stop measuring; it is to measure at the team level, to look at trends rather than absolutes, and to use the numbers to ask questions rather than to grade people. Measuring engineering performance without damaging culture is our longer treatment of how to do this without wrecking trust.
"Lines of code and commit counts are meaningless." Also true. Nobody serious proposes them. The metrics worth having are about flow (how long work waits, how long it takes) and outcomes (did the change work, did it have to be reverted), not volume.
"Our work is too varied to measure." This one is mostly wrong. Individual tasks vary enormously. The aggregate flow of a team over a month does not. Median pull request cycle time is remarkably stable for a given team and process, which is exactly why it is useful: when it moves, something changed.
"We'll build a dashboard nobody looks at." True if you start with a dashboard. Start with one question instead.
Where the data already is
The best-kept secret of engineering metrics is that you do not need to instrument anything. The events are already recorded, with timestamps, in systems you already use:
- Git and your code host record when a branch was created, when each commit landed, when the PR was opened, when review was requested, when each review was submitted, and when it merged.
- Your CI system records when each run started, how long it took, whether it passed, and (if you keep test reports) which tests failed.
- Your deploy tooling records when each deploy happened and what was in it.
That means you can compute a baseline for the last six months today, from history. You do not have to wait for data to accumulate. Here is a rough version of the single most useful number, median time from PR open to merge, using nothing but the GitHub CLI:
# Median open-to-merge time (hours) for the last 200 merged PRs in a repo
gh pr list --repo your-org/your-repo --state merged --limit 200 \
--json createdAt,mergedAt \
| jq -r '
map(((.mergedAt | fromdate) - (.createdAt | fromdate)) / 3600)
| sort
| .[length / 2 | floor]
| "median open-to-merge: \(. * 10 | round / 10) hours"'
Run that for each team's repos and you have your first baseline in ten minutes. It is crude (it ignores draft time and weekends), and that is fine. A crude number you have beats a precise number you are planning to have.
A first week that works
Here is the sequence I recommend, because I have watched the alternative (buy a tool, wire up everything, present forty charts) fail repeatedly.
Day 1: pick one question. Not a metric, a question. "Why do PRs feel slow?" or "Are we shipping less than we were in the spring?" or "Is CI the bottleneck?" The question decides the metric, not the other way around.
Day 2: compute the baseline from history. Use the script above, or your code host's API, or a tool that does it for you. Get the last three to six months, weekly, for the whole team. Look at the shape before the number: is it stable, trending, or spiky?
Day 3: decompose once. If the question was about slowness, split cycle time into its stages: coding (first commit to PR open), pickup (PR open to first review), review (first review to approval), and deploy (approval to production). One stage will dominate. That stage is your first target, and now you have a hypothesis instead of a hunch.
Day 4: check the signal you are measuring against. This is the step everyone skips. If your CI suite is flaky, "time to green" and "change failure rate" are contaminated before you start. A PR that waited four hours for a rerun did not have a slow reviewer. Before you trust any downstream metric, look at the pass rate of your test suite on unchanged code. We wrote about how badly this distorts one specific number in change failure rate is lying to you if your tests are flaky.
Day 5: share the one chart with the team, and ask them what it means. Not what to do about it. What it means. The engineers usually know exactly why pickup time is 19 hours, and they have been waiting for someone to ask.
That is it for week one. No dashboard. One question, one baseline, one decomposition, one conversation. Week two is where you pick a change, make it, and check the number again in a month.
What to measure first, and what to leave alone
If you want a concrete short list, start with flow and outcome, and ignore volume.
Measure first:
- Cycle time, from first commit to production, with its stages broken out.
- Review pickup time, because it is the stage most often dominant and most easily fixed.
- CI pass rate on the main branch and flaky test rate, because they determine whether every other number is trustworthy.
- Deploy frequency, as a coarse measure of batch size and confidence.
- Change failure rate, the fraction of deploys that needed a fix or rollback.
Leave alone:
- Lines of code, commit counts, and PRs per engineer. They measure typing.
- Story points completed, for reasons that get their own post: beyond story points: what to measure instead.
- Anything per individual, until your team has trusted the team-level numbers for at least a couple of quarters.
Building a habit, not a report
The teams that get value from metrics look at them briefly and often. A five-minute check in the weekly team meeting beats a quarterly deck. The question each week is the same: did anything move, and do we know why? Most weeks the answer is no, and that is fine. The weeks where the answer is yes are where the improvement happens, and they only stand out because the other weeks were watched too.
This is also the place where tooling earns its keep. Computing a baseline once with a shell script is easy. Computing it weekly, per team, with the stages decomposed and the CI signal cleaned of flaky failures, is the kind of thing that quietly stops happening after the second month unless it is automated. That is what our engineering metrics product does: it reads the events already in your repos and CI, breaks cycle time into its stages, and keeps the trend in front of the team without anyone maintaining a spreadsheet. But the habit matters more than the tool, and the habit starts with one question and a baseline you can compute today.
FAQ
Won't measuring make my engineers feel surveilled?
It will if the first thing they see is a leaderboard. It will not if the first thing they see is a team-level chart, presented with the question "what does this mean?" Be explicit about the rule: these numbers are for finding process problems, not for evaluating people. Then keep the rule, especially when it is inconvenient. Trust here is built slowly and lost in one review cycle.
How much history do I need before the numbers mean anything?
For a team merging a few PRs a day, four to six weeks of weekly medians shows a trend. For a smaller team, use a longer window and expect more noise. Because the data comes from git and CI history, you can usually compute the previous six months on day one rather than waiting.
Should I use DORA metrics or something else?
DORA's four (deploy frequency, lead time, change failure rate, time to restore) are a good outcome-level scoreboard and are widely understood, which helps when talking to non-engineers. They are too coarse for diagnosis on their own. Pair them with stage-level flow metrics, like review pickup time, that tell you where to look when a DORA number moves.
