Metrics for Managing and Metrics for Reporting Are Not the Same Metrics

Two entirely different jobs get called "engineering metrics."

One helps a team decide what to change this week. The other explains engineering to people who don't work in it. They need different metrics, different cadences, different granularity and different audiences — and most measurement programmes fail by building one artefact and pointing it at both.

How they differ

The mismatch is structural rather than a matter of taste. A weekly p90 review-wait figure for one service is the right instrument for a team deciding whether to add reviewers, and completely useless in a board deck. A quarterly investment allocation chart is the right instrument for a CFO conversation, and tells a team nothing they can act on.

What management metrics look like

Close to the mechanism, high resolution, short cadence.

Stage-level cycle time rather than the total — coding, review wait, review duration, merge to deploy. The total hides the movement, and the movement is the finding.

Distributions rather than averages. A two-day median with a three-week p90 describes a team that is fast at easy work and unpredictable at hard work, and the second half is what breaks roadmaps. Averages report the half nobody needed.

Review time per change rather than total review time. If total hours held steady while changes rose 30%, depth per change fell by about the same. That's a bottleneck, computed from data you already have.

Outliers, named. The single worst pull request this week is more actionable than the median, because someone can go and look at it.

Test: could a team member change something on Monday because of this number? If not, it's not a management metric.

What reporting metrics look like

Further from the mechanism, aggregated, quarterly, and translated.

Outcome and impact rather than effort and output. This is the substance of the critique that made McKinsey's 2023 framework indefensible: Kent Beck and Gergely Orosz pointed out that work runs effort → output → outcome → impact, and measuring the first two while skipping the second two captures half the lifecycle and calls it productivity. A reporting metric that stops at output invites exactly the reading you don't want.

Investment allocation, if your issue tracking is disciplined enough to support it. Where engineering time went by business category, quarterly.

Delivery trend at organisation level, with context. Not "deployment frequency is 4.2 per day" but "up 30% since we consolidated the release process, and here's what that enabled."

Cost, stated precisely. Tooling spend, licence spend, and what changed as a result. Precision here buys credibility for the parts that are necessarily less precise.

Test: would someone outside engineering understand what this means and why it matters, without a translator? If not, it isn't a reporting metric yet.

Why merging them fails

A dashboard built for both serves neither. It's too aggregated for a team to act on and too detailed for an executive to read, so both audiences stop opening it. This is the most common way a measurement programme dies quietly.

Management metrics leak into evaluation. This is the serious failure. A per-service, per-week metric exposed to executives gets compared across teams, and the comparison measures the systems rather than the people. Once teams learn that their working numbers travel upward unfiltered, the numbers stop being honest — and the distortion is in the measurement itself, not merely the culture.

Reporting metrics get used for management. A quarterly aggregate can't tell a team what to change, so a team handed one either invents a story to explain it or ignores it.

Running both

Two artefacts, explicitly. A working view for the team and a quarterly report for everyone else. Different documents, different cadences, and say so.

Declare which travels upward. Before anyone is measured, state what leaves the team and at what granularity. Vague answers get filled in with the worst plausible interpretation, and usually correctly.

Aggregate deliberately, not automatically. The quarterly report is written, not exported. Someone decides what to include and adds the context that makes it interpretable. An auto-generated executive dashboard is a management view with a bigger date range.

Let the reporting view be less precise. Outcome measures are softer than cycle time and that's appropriate — they're closer to the thing that matters. Precision at the wrong level of abstraction is how organisations end up optimising deployment frequency while shipping features nobody uses.

Frequently asked

Can one tool produce both? The data source, yes. The artefact, no. Most platforms in this category are built around one audience — some for the boardroom, some for the manager — and picking the wrong one is the most common buying error.

Who writes the quarterly report? Whoever runs engineering. Delegating it to a tool export is how it ends up being effort and output rather than outcome and impact.

What if executives want the weekly view? Ask what decision they're making. It's usually answerable from the quarterly view with more context, and giving them the raw working data is how cross-team comparison starts.

Isn't this just more work? The quarterly report is a few hours, four times a year. It replaces the recurring argument about what the dashboard means, which costs considerably more.