How do you set quality bars and metrics that actually motivate a team without burning them out?

Setting metrics is one of the most consequential lead-level decisions. Get it wrong and you either get gaming, burnout, or both. Get it right and you focus the team on what matters.

STAR walkthrough — sample answer:

Situation: I joined a previous role as head of quality for a 40-engineer org. There were existing quality "metrics" — but they were either symbolic (a coverage number nobody trusted) or weaponised (a velocity target used to penalise slow teams). The metrics weren't motivating quality work; they were sources of friction or rituals.

Task: Replace the existing metric set with something that actually focused the team on quality outcomes without crushing them.

Action: Six principles I applied:

1. Pick metrics tied to user impact, not internal proxy. Replaced "code coverage %" with "production incidents per quarter" and "customer-reported bugs per 100 active users." User-facing metrics are harder to game and harder to argue with.

2. Use bands, not points. "Pass rate above 95%" beats "Pass rate of 100%." A point target either gets gamed or makes every miss feel like failure. A band acknowledges that some variance is real and asks "are we within the band?"

3. Make targets achievable but stretching. Started each metric at the team's current trailing 12-week median, then set the band 10-20% better. Achievable in a quarter. Re-set each quarter as the team improved. Avoided "stretch" targets that were aspirational but mathematically unrealistic.

4. Distinguish leading from lagging indicators. Leading: PR pipeline trust, time-to-detect, flake rate. Lagging: incident count, customer-reported bugs. Track both, but tie individual squad ownership to leading indicators (which they can directly affect) rather than lagging (which depend on many factors outside the squad's control).

5. Treat misses as diagnostic. When a metric was missed, the response was a conversation: "what was different this quarter? what would unblock improvement?" Never "the team failed." This is the single biggest culture difference between metrics that motivate and metrics that demoralise.

6. Ban metrics that can be gamed. No "tickets closed" — incentivises closing without resolving. No "tests written" — incentivises low-value tests. No "coverage %" — incentivises useless coverage. If a metric can be optimised by doing the wrong thing, drop it.

Result: Over the following year, the metrics shifted from rituals to reference points the team actually used. Squads regularly self-organised around the leading indicators. Incident counts dropped substantially. Anonymous engineering surveys showed higher trust in the metric system year-over-year. No burnout reports tied to metric pressure (this was tracked specifically).

The hardest part: resisting senior leadership's instinct to add more metrics or set tighter targets. Several times I had to push back on requests to "add a metric for X" — explaining that more metrics dilute focus, not increase it. That's a lead-level conversation; you have to hold the line on what gets measured and on what doesn't.

What I learned: metrics are a leadership instrument, not a measurement system. They tell the team what matters and signal what doesn't. Setting them well is one of the highest-leverage things a lead does — and one of the easiest to get wrong by adding rather than subtracting.

Why this works: shows principled framework (bands, leading-vs-lagging, anti-gaming), measurable outcomes, the candidate holding the line on additions, and the cultural framing of misses as diagnostic. Strong lead signal of metric design as leadership.