Stack Ranking Software Engineers: Why It Backfires

TL;DR: Stack ranking forces every team onto a bell curve: someone must be rated bottom even when the whole team shipped brilliantly. Microsoft ran the famous experiment and ended it in 2013 with the memo line "No more curve," after years of commentary tying it to a collaboration-killing internal culture. For software teams the failure is structural: engineering is a team sport, the metrics that feed rankings are the most gameable data you own, and the people who win a knife-fight quarter are rarely the people who make the team better. There's a better answer, and it isn't "no visibility."

Somewhere right now, a leadership offsite is one slide away from proposing it: rank the engineers, reward the top, "manage out" the bottom, repeat until excellent. It feels rigorous. It photographs well in a board deck. And one of the largest software companies in history already ran this experiment at full scale, for years, with the results written up everywhere from engineering blogs to Vanity Fair.

What stack ranking is (and the experiment that already ran)

Stack ranking (forced ranking, forced distribution, the "vitality curve") requires managers to sort their people into a fixed distribution: a few stars, a big middle, and a mandatory bottom tier, regardless of how the team actually performed. As Marcus Buckingham put it in HBR when Microsoft finally killed the practice, managers were forced to rate team members "from excellent to poor (even if the whole team had, in fact, performed excellently)."

Microsoft's retreat is the part worth memorizing. In November 2013, HR chief Lisa Brummel announced the end of the system with the phrase "No more curve." The HBR analysis tied stack ranking to "Microsoft's inability to foster high-performing teams" during what the business press called its lost decade. The company with more performance data than almost anyone on earth looked at forced ranking and concluded it was making them worse.

Why stack ranking backfires for software engineers specifically

Engineering is a team sport scored as singles tennis. Software gets built in shared codebases through code review, knowledge transfer, and a thousand small unblockings. Under a forced curve, the colleague you're helping is the colleague you're competing against for the non-bottom slots. Every act of generosity - thorough review, patient mentoring, glue work - becomes a donation to a rival. You don't have to believe engineers are cynical; you just have to believe they can do math.

The input data is the most gameable data you own. Rankings need numbers, and the numbers available (commits, lines, PRs closed, points burned) are activity metrics that measure motion, not value. The SPACE research is explicit that productivity can't be captured by a single metric and that activity is the weakest, most abusable dimension. A ranking built on gameable inputs doesn't find your best engineers; it finds your best metric-optimizers, and it teaches everyone else to become one.

It manufactures the risk-aversion you'll spend years diagnosing. Under a curve, the rational engineer avoids the gnarly legacy migration, the documentation debt, the flaky-test swamp: anything with a high chance of looking unproductive this cycle. The work that most needs doing is precisely the work a ranked engineer can least afford to do.

Your best people can read a leaderboard. Senior engineers with options don't wait to discover which side of the curve they're on in a bad quarter. The people a forced distribution retains best are the people who've learned to win at it, which is a skill, but not one that ships software.

It shreds the psychological ground teams run on. Honest incident reviews, "I don't know," early warnings about a doomed approach: all of it depends on colleagues not being courtroom adversaries. A forced curve turns every meeting into evidence-gathering, and the silence that follows is expensive in exactly the ways team health metrics later struggle to explain.

"But we need to know who's underperforming"

You do - and a curve is a terrible way to find out. Forced distribution doesn't identify underperformance; it mandates it, in every team, every cycle, including your best one. A real underperformance case is built the boring way: clear expectations, specific evidence-linked examples, a manager who's been paying attention, and a fair chance to improve. None of that requires ranking the other nine people on the team against each other, and all of it works better without the fear tax.

The same goes for the opposite question: who to protect and promote. The answer lives in what each person uniquely carries: the systems only they understand, the load they quietly absorb, what it would cost to lose them. That's a scorecard question, and scorecards don't need a loser column to work.

What to run instead of stack ranking

1. Measure the system at team level. Flow, queues, review pickup time, knowledge concentration, delivery health. Most "low performer" stories dissolve into system stories on inspection. The engineer who "ships nothing" is often the one wedged behind every blocked dependency you never fixed.
2. Per-person scorecards, for support. Strengths, growth areas, unique contributions, irreplaceability, what the org loses if they walk. Multi-dimensional, evidence-linked, never collapsed into one sortable number. The moment it sorts, it's a ranking again, whatever the deck calls it.
3. Calibrate on receipts, not curves. Compare across teams to keep expectations fair, and bring concrete examples, never distribution targets.
4. Reward the collaborative work explicitly. If review quality, mentoring, and glue work count for nothing at promotion time, you're running a soft stack rank on activity anyway
   • just with extra steps.

Microsoft needed a decade and a "No more curve" memo to buy this lesson. It's available to you secondhand, at a considerable discount. The teams that outperform aren't the ones where engineers fight for rank. They're the ones where the system is measured, the people are seen, and nobody has to beat a colleague to be safe.