Your engineering team sits in a retrospective. Someone mentions that the tracking tools are now measuring individual pull request volume. The energy in the room drops. The best person on the team gets quiet. You watch it happen and don't understand why.
A week later, that engineer updates their LinkedIn. A month later, they're gone. And you're confused. The team is hitting velocity. The metrics look good. But your best person left, and the reason was there the whole time: they knew you were measuring the wrong thing and it meant you didn't actually understand what they did.
Why individual metrics drive out your best people
Here's the thing about top engineers: they're overindexed on autonomy and respect. They want to solve hard problems. They want their work to matter. They want to be trusted. What they don't want is to be managed like a factory line.
When you measure individual developers by pull requests, commits, or hours, you're saying "I don't trust you to decide what matters. I'm going to measure your output and assume volume equals value." And your best people hear that loud and clear.
They see it as disrespect. Not because they have something to hide, but because they know that the best work isn't always the work with the highest volume. A senior engineer who reduces 10,000 lines to 500 clean lines looks lazy on a commit count. A developer who protects the team from a bad architectural decision by saying "let's not do that" and spending a week on an alternative looks unproductive. A person who spends an afternoon helping a junior engineer design a feature looks like they're not shipping.
So they update their resume and start looking around. And you lose the institutional knowledge, the taste for good design, the person who would have caught the architectural mistake that's going to cost you six months of rework in year two.
The SPACE framework: what to measure instead
"We need to focus on augmenting human capability, not measuring human activity. Individual metrics are actively harmful. Team outcomes are what matter — and team outcomes require measurement at the team level, not the individual level."
Satya Nadella · Microsoft Engineering Systems Discussion
The research on developer productivity is clear. Nicole Forsgren and colleagues created the SPACE framework precisely because individual metrics were failing. It stands for Satisfaction, Performance, Activity, Communication, and Efficiency. And critically, most of these are measured at the team level, not the individual level.
Satisfaction: Do people want to be here? Do they believe in what they're building? This predicts retention more reliably than any activity metric. A team with high satisfaction will outperform a team with high line-of-code-per-developer for years. Measure it quarterly through surveys, retros, and engagement checks.
Performance: Is the team delivering what matters? Is scope getting done? Are features shipped on time? This is team-level. A team that ships one high-value feature on time outperforms a team that ships three mediocre features late. Measure velocity, predictability, and outcome delivery, not individual throughput.
Activity: Is the team moving? Are you seeing commits? PRs? Deploys? This is useful as a sanity check — if activity drops sharply, something's wrong. But it's not a performance signal. Activity volume tells you nothing about impact. Use it as a diagnostic signal, not a goal.
Communication: Is the team talking? Are they sharing decisions? Are blockers being flagged? This is where collaboration happens. A team that communicates proactively ships faster than a team that's siloed. Measure through retro attendance, daily standup participation, impediment flagging.
Efficiency: Are we doing work we don't need to? Is there rework? Technical debt? Churn? Measure at the team level — what's our rework percentage, our refactoring velocity, our incident response time?
How individual metrics get gamed (and why)
The moment you measure individual developers, they start optimizing for the metric. It's not cynical. It's rational. They're responding to what the system incentivizes.
Pull request count? They split commits into tiny PRs so each one looks like progress. Lines of code? They expand variable names and add unnecessary intermediate steps. Hours logged? They slow down work to make it stretch longer. Tickets closed? They close tickets without finishing the work, just to hit the number.
None of this is dishonesty. It's gaming. And smart organisations don't set up games they expect people to lose at. They measure things that align incentives. A team-level metric aligns incentive: we all win when this ship on time. An individual metric misaligns it: I win when my stats look good, which might not be the same as the team winning.
The team outcome framework that actually works
Replace individual metrics with team-level outcomes. Here's what to track:
Scope completion: Of what we committed to, what did we deliver? This is simple: plan 40 points, ship 38 points = high predictability = team is calibrated. The team that finishes what they commit outperforms the team that overshoots or undershoots repeatedly.
Cycle time: How long from idea to shipped? Fast teams compress this relentlessly. Slow teams watch it creep up and wonder why velocity dropped. This is a team metric because it captures the entire system — from planning through to release.
Impediment resolution: When a blocker emerges, how fast does it get cleared? A team that resolves blockers in hours will ship faster than a team that waits weeks. Measure how many impediments were flagged and resolved per sprint. Increasing resolution speed is a sign of a maturing team.
Rework percentage: What percentage of your effort is fixing previous work? High rework (>20%) signals technical debt or quality issues. Low rework (<5%) is unrealistic. The sweet spot is 10-15%. Track it by measuring story points reopened vs story points shipped.
Engagement: This one you can measure at the individual level, but aggregate at the team. Do people show up to planning? Do they speak up in retros? Are they learning? A team with high engagement will innovate and adapt. A team with low engagement will follow process and resist change.
How to transition from individual to team metrics
First, announce it. "We're moving away from individual metrics. We're measuring team outcomes instead. Here's why: because we want to measure what actually matters, and individual metrics measure activity, not value."
Second, remove the individual metrics from visibility. If you're tracking PR count per developer, stop. If you're logging hours, stop. If you're comparing developers against each other, stop. The moment you show a metric, the system starts optimizing for it. So stop showing metrics that optimize for the wrong thing.
Third, introduce team metrics. Start with the three that matter most for your context: predictability, speed, and health. Show them in your team standup every day. Track them sprint-over-sprint. Get the team invested in moving them.
Fourth, change your 1-1s. Instead of reviewing individual metrics, review individual growth and impact. "What did you contribute to the team's outcomes this sprint? What did you learn? What's blocking you?" This conversation matters. The metrics don't.
The payoff: the team you actually want to build
Within three months of shifting to team metrics, you'll notice the change. The pressure drops. People start collaborating instead of competing. The senior engineers stop looking at the exit door. The team starts raising their hand for hard problems instead of solving easy ones to keep the metrics up.
The best sign is when a junior engineer asks "what's the highest-impact thing I can work on right now?" instead of "what's the easiest ticket to close?" That shift in thinking is what you're actually optimizing for. And it only happens when the system stops measuring activity and starts measuring outcomes.
Measure team outcomes. Let individuals contribute to them however makes sense. Trust them to do good work. That's how you build engineering teams that ship, learn, and stay.