Your First 90 Days With Engineering Metrics

Most measurement programmes fail in month two. Not because the tooling is wrong — because the sequence was.

The common ordering is: buy a platform, connect everything, show the team a dashboard, discover that engineers hate it. The dashboard becomes a thing the manager looks at alone, and eighteen months later it's cancelled at renewal.

Here's a sequence that survives contact with a team.

Days 1–14: Decide what decision you're trying to make

Do not connect anything yet.

Write down, in one sentence, a decision you currently make badly. Not "we should measure productivity" — that's not a decision. Something like: we can't tell whether to add reviewers or split the service; we don't know why estimates are consistently wrong; we can't answer the CFO's question about where the quarter went.

Then write down what number would change that decision, and in which direction.

If you can't complete both sentences, you're not ready to measure. Teams that skip this step buy a platform and spend the next year looking for a question it answers.

Also decide, before anyone sees data: who will see it, at what granularity, and whether it can ever enter performance evaluation. Write the answer down. You will be asked, and improvising the answer under pressure is how programmes lose the room.

Days 15–30: Measure one thing by hand

Pick the single metric closest to your decision. Compute it manually for one team over the last quarter, from raw data — your CI logs, your git history, your issue tracker.

This is the step everyone skips and the one that pays.

You will learn whether the data is even usable, what your definitions actually need to be, and frequently that the answer is already visible without a platform. It also means that when a vendor's dashboard shows a number, you have something to check it against.

An afternoon of this reliably beats a month of demos.

Days 31–45: Tell the team before you tell anyone else

Present what you're measuring and why, to the people being measured, before the numbers reach anyone above you.

Cover four things: the decision you're trying to make, what you're measuring, what you're explicitly not measuring, and who sees it.

The framing matters more than most managers expect. Peer-reviewed research published in Communications Psychology in 2024, with around 1,200 participants, found algorithmic monitoring quadrupled complaints and reduced idea generation — except when it was framed as developmental rather than evaluative, where those effects largely disappeared. Same data, different stated purpose, materially different outcome.

That result only holds while the framing is true. If the data later appears in a performance conversation, you have spent the credibility permanently.

Expect the question: will this be used to evaluate individuals. Answer it directly. "No, and here's the written commitment" works. "Not currently" does not.

Days 46–60: Instrument, then validate

Now connect the tooling.

Then verify it. Take the metric you computed by hand and compare it against what the platform reports. If they diverge, find out why before anyone builds a decision on the dashboard.

Common causes: deployment events misclassified, bot commits counted as work, repositories excluded by an onboarding filter, reverts double-counted.

Skipping validation is how organisations end up making resourcing decisions on a number that was measuring their integration configuration.

Days 61–75: Change one thing

Use the data to make a single, specific change. Not a programme — one change. Reviewer assignment rules, a pull request size limit, a decision to split a service, a change to who is on call.

The point is demonstrating the loop closes. A measurement programme that never causes a change is a reporting programme, and teams work that out quickly.

Involve the team in choosing the change. A practice the team agreed to is a different thing from a practice imposed on it, and it's the difference between a working agreement and a rule people route around.

Days 76–90: Report outcomes, not activity

When you report upward, lead with what changed and what it produced. The delivery metrics are supporting evidence, not the headline.

This is the answer to the executive question that started the whole thing. Effort and output alone are what made the 2023 McKinsey framework indefensible — the useful report continues into outcome and impact. What shipped, what changed for users, what it cost.

Then delete a metric. Whatever you've been tracking that hasn't informed a single decision in three months comes off the dashboard. Doing this early sets the habit, and most dashboards in this category could lose half their tiles without losing anything.

What to avoid throughout

Don't roll out to the whole organisation at once. One team, one quarter, then expand with something to show.

Don't build a leaderboard. Not even informally, not even in a private document. It ends the programme.

Don't compare teams with different contexts. Legacy service versus greenfield is a comparison of systems, not of people.

Don't let the tool choose the metrics. Every platform ships with a default dashboard. Defaults are designed to demo well.

Don't measure during a reorganisation and expect the numbers to mean anything.

Frequently asked

What if leadership wants results faster than 90 days? Give them the day 15–30 manual measurement. One metric, one team, computed by hand, is a credible early answer and takes an afternoon.

Do we need to buy a platform at all? Not initially, and possibly not at all under 50 engineers. The open-source stack covers delivery metrics; the gap opens when you need survey data or reporting across many teams.

What if the team refuses? Find out what they expect the data to be used for. The refusal is almost always about evaluation rather than measurement, and it's usually well founded in something that happened at a previous employer.

How long until the metrics are trustworthy? One full quarter of clean data, minimum. Anything shorter is noise, particularly if a workflow change happened inside the window.