How to Introduce Metrics Without Losing the Room

The technical work of setting up engineering metrics is straightforward. The conversation with the team is what determines whether the programme survives, and most managers improvise it.

That's a mistake, because the research says framing does real work — and because engineers have usually seen this go badly somewhere before.

Why the resistance is rational

Assume anyone objecting is drawing on experience rather than being difficult.

Individual scorecards were the norm in this category for years. GitPrime, the product that created engineering intelligence as a category, built its reputation on ranking engineers by commits, lines of code and pull requests. Plenty of people currently on your team have been on the receiving end of a dashboard like that, or watched it inform a layoff list.

Kent Beck and Gergely Orosz named the underlying dynamic directly in their 2023 response to McKinsey: a common reason executives want individual productivity data is to work out who to let go. Your team knows this. Pretending they don't is where these conversations go wrong.

So the objection isn't "measurement is bad." It's "what is this going to be used for," and it deserves a direct answer.

What the research says about framing

Peer-reviewed work published in Communications Psychology in 2024 by Schlund and Zitek, with roughly 1,200 participants, tested algorithmic monitoring. It quadrupled complaints and reduced idea generation.

The important part is the exception: those effects largely disappeared when the monitoring was framed as developmental rather than evaluative. Same data, different stated purpose, materially different response.

Two things follow. Framing is not a communications trick — it changes the outcome measurably. And it only works while it's true. The moment the data appears in a performance conversation, the developmental framing becomes false, and you have spent the credibility permanently rather than temporarily.

The conversation

Do it before instrumenting anything, not after the dashboard exists.

Lead with the decision, not the metrics. Start with the problem you're trying to solve, stated concretely. "I can't tell whether we need more reviewers or a smaller service, and I keep guessing" is a real opening. "We're going to start measuring productivity" is not.

Say what you're not measuring, explicitly. Name it: no individual comparison, no leaderboards, no input to performance review. Vague reassurance reads as evasion, and people fill the gap with the worst plausible interpretation.

Say who sees it. Team level, your level, above you, and at what granularity. If executives will see aggregate numbers, say so now rather than having it discovered later.

Put the commitment in writing. A short written policy on what the data can and can't be used for. Verbal commitments don't survive a manager change, and everyone knows it.

Ask what would make it useful to them. Engineers usually have a clear view of where their time goes and often want the friction documented. A programme that surfaces the flaky test suite and the two-week review queue has the team on its side.

Answer the evaluation question directly when it comes. It will come. "No, and here's the written commitment" works. "Not at this stage" does not — it's heard as "yes, later," which is usually accurate.

What not to do

Don't present the dashboard first. Leading with a tool implies the decision was made without them, because it was.

Don't say metrics are for their benefit if that isn't the whole truth. If leadership pressure is part of why this is happening, say so. Engineers respect a manager who names the constraint far more than one who pretends it doesn't exist.

Don't compare teams in public. Even innocently. Different services, different constraints, different work — the comparison measures the systems, and everyone knows which team looks worse.

Don't promise the numbers won't be misused by someone else. You can't promise that. What you can commit to is what you will do, and what you'll do if you're asked for something you said you wouldn't provide.

Handling the pressure from above

The hardest version of this is being asked for a per-developer breakdown by someone senior.

The useful move is to find out what decision they're making. It's almost always a resourcing, performance or investment question that has a better answer available. Refusing outright makes engineering look evasive — which is precisely the frustration that made the McKinsey framework marketable in the first place.

The productive response is to say what you can provide, why the individual version is misleading rather than merely uncomfortable, and then actually provide the better answer. Team-level delivery data, outcome measures, and a direct account of what shipped and what it changed. Declining without an alternative loses the argument, and probably should.

What to do afterwards

Show the team the data first. Before it goes up, not after.

Close the loop visibly. Use the numbers to change one thing within the first quarter, and say which number prompted it. A measurement programme that never causes a change is a reporting programme, and teams work that out fast.

Delete metrics publicly. Whatever hasn't informed a decision in three months comes off the dashboard, announced. It demonstrates that this is a working tool rather than a surveillance layer accumulating over time.

Frequently asked

What if someone flatly refuses to participate in surveys? Participation in perceptual measurement should be voluntary, and low response rates are themselves a signal worth reading rather than a problem to fix with pressure.

Do I have to tell them everything leadership sees? Yes. It will surface eventually, and discovering it later costs more than disclosing it now.

What if I'm later ordered to supply individual data? Tell the team before you do it, and say the commitment changed and why. Breaking it silently ends the programme and damages more than the programme.

How long before the conversation stops being necessary? It doesn't. Repeat the framing whenever the team changes, the tooling changes, or the metrics change.