Top Devs Pick Harder Bugs When the Leaderboard Shows Rank, Not Points
Picture a bug tracker that looks like a game. Every engineer has a profile, every fixed issue earns a badge, and a public dashboard ranks the whole team by how much they've "contributed." Now change one variable: instead of ranking people by points, you rank them by position — first, second, third, down to the bottom. Same work, same scoring, different display. Do people start reaching for harder problems? That's the question several engineering leads have been quietly arguing about over the last few years, and it turns out there's a real behavioral literature sitting underneath it.
The answer matters more than it sounds, because the way we display performance data inside developer tooling is a design decision — and design decisions shape behavior whether we intend them to or not. If a leaderboard nudges engineers toward the gnarly race condition instead of the seventh trivial CSS fix, that's a free win. If it nudges them toward gaming the metric, you've just built a machine for producing pull requests nobody wants to review.
The Display Effect: Why Rank and Points Are Not the Same Signal
The first thing to get straight is that points and rank are different psychological objects even when they're mathematically linked. Points are an absolute measure of accumulated output. Rank is a relative measure of standing against other people. A points leaderboard says "here's what you've done." A rank leaderboard says "here's where you sit relative to your peers" — and humans are exquisitely tuned to the second kind of information.
Leon Festinger's social comparison theory, published back in 1954, argued that people have a drive to evaluate their own abilities, and in the absence of objective standards they do it by comparing themselves to others. Software engineering is a domain with almost no clean objective standard. You can count commits, but everyone knows commits are a terrible proxy. So engineers look sideways at each other. The leaderboard just makes that sideways glance explicit.
What's less obvious is which comparison gets activated. Research on ranking versus absolute feedback suggests that ordinal position (you're 4th) triggers competitive, status-oriented processing, while cardinal scores (you have 340 points) trigger more of a personal-progress framing. A 2019 study in Journal of Consumer Research by Burson and colleagues on rank-based versus score-based feedback found that ordinal rank information shifts attention toward the gap between you and the person ahead of you — a "how do I close the distance" mindset — whereas raw scores tend to be evaluated against your own past performance. That distinction is exactly the lever a dev-team leaderboard is pulling.
There's a second effect layered on top: the reference point. Daniel Kahneman and Amos Tversky's prospect theory (1979) established that people evaluate outcomes relative to a reference point rather than in absolute terms, and that losses loom larger than equivalent gains — loss aversion. On a points board, your reference point is your own history; you're trying to beat last week's you. On a rank board, your reference point is the person directly above you, and every time they fix a bug, you lose relative standing without doing anything wrong. That's a moving reference point you don't control, and loss aversion makes it sting.
Put those together and you get a prediction: rank displays should produce more competitive, more effort-intensive behavior per unit of feedback. The question is whether that extra effort gets spent on the problems you actually want solved.
What Competitive Framing Does to Task Selection
Here's where it gets interesting for anyone who has ever triaged a backlog. Psychologists have a long-running interest in how competition changes which tasks people choose, not just how hard they work. The consistent finding is that competition increases the appeal of tasks that are visible, differentiable, and legible to observers — and decreases the appeal of tasks that are hard to attribute.
That's a problem, because a lot of the highest-value work in a codebase is hard to attribute. The engineer who spends two days reproducing a nondeterministic race condition and then fixes it with a four-line change produces a patch that looks trivial in a diff. The engineer who ships nine small feature tweaks produces nine visible PRs. A points system rewards the second person. A rank system, if you're not careful, rewards them even more, because relative standing amplifies the visibility premium.
But there's a countervailing force, and it's the one that makes the "harder bugs" hypothesis plausible. Research on need for cognition and on challenge-seeking suggests that a meaningful subset of high performers are actively drawn to difficulty when difficulty is legible as a status signal. In other words: if the leaderboard ranks by difficulty-weighted completion rather than raw count, the competitive frame flips. Now the hard bug is the high-status object. Now the person who takes on the race condition is the one climbing.
This is the design insight hiding in the question. Rank doesn't inherently push people toward easy work. Rank pushes people toward whatever the ranking measures. If you rank by points where every ticket is worth the same, you get a volume game. If you rank by a difficulty-weighted score — or better, by a measure that credits resolution of high-complexity, high-uncertainty issues — the competitive drive points at the hard problems.
The attribution problem
There's a catch that anyone building this kind of tooling runs into immediately: difficulty is much harder to measure than count. Story points are a social construction. Cycle time conflates complexity with stalling. Lines changed is worse than useless. The most honest difficulty signal in most codebases is a human one — a triage label, a senior engineer's estimate, a severity tag — and human difficulty labels are gameable and noisy.
This is where the incentive design and the measurement design have to be built together. A rank board over a noisy difficulty metric will produce exactly the behavior you'd expect: people optimizing the metric, not the work. Goodhart's law isn't a metaphor here; it's an operational hazard. The teams that make rank-based motivation work tend to use coarse difficulty buckets (trivial / normal / hard / very hard) with human review at the boundaries, precisely because fine-grained scores invite gaming while coarse buckets preserve the status signal without rewarding precision-hacking.
The Concrete Case: What Happened When One Team Flipped the Board
The clearest illustration I've come across is from a mid-sized platform team that ran an internal engineering dashboard for about eighteen months. I'll describe the setup because the mechanics are the instructive part.
For the first nine months, the dashboard ranked engineers by a points total: one point per merged PR, with small bonuses for review activity and documentation. The team watched two things — throughput and the distribution of issue difficulty. Throughput was fine. But the difficulty distribution skewed hard toward the easy end. Roughly seventy percent of resolved issues were tagged trivial or normal; the hard and very-hard buckets sat untouched for weeks at a time, and the same two senior engineers were quietly absorbing them without any leaderboard credit, because a four-line fix is still one point.
For the next nine months, the team changed two things at once, which makes it a messy natural experiment rather than a clean one — but the result is still worth reporting. First, they switched the display from points to ordinal rank. Second, they reweighted the score so that difficulty buckets carried multipliers (trivial ×1, normal ×2, hard ×5, very hard ×8), with the bucket assigned at triage by someone other than the person who'd fix it.
The difficulty distribution moved. Hard and very-hard resolutions went from roughly thirty percent of the mix to a bit over half. Total issue count dropped — which is what you'd expect when the scoring rewards depth over breadth — while the count of long-open high-severity issues fell sharply. The two senior engineers who'd been silently carrying the hard bucket became visible at the top of the rank board, which had a second-order effect nobody planned: mid-level engineers started asking to pair on hard issues, because that's where the status was.
The team also hit the predictable failure modes. Two engineers discovered that splitting one logical change into several PRs still paid, so the multipliers had to be paired with a merge policy. One person gamed the triage label by reclassifying their own tickets before the reviewer saw them, which is why the bucket assignment got moved to a separate role. And there was a stretch where review activity spiked in a way that looked like diligence but was really people farming the review bonus with rubber-stamp approvals — fixed by removing the review bonus entirely and letting rank reflect only resolved difficulty.
The lesson isn't "rank is good" or "rank is bad." It's that the display and the scoring are a single system, and the competitive energy that rank unlocks will flow to whatever the scoring makes visible. Flip the display without fixing the metric and you amplify the metric's flaws. Fix the metric without changing the display and you leave the motivational energy on the table.
Designing for the Behavior You Actually Want
If you're building internal tooling — and a surprising number of indie devs and small studios end up building exactly this, because off-the-shelf trackers don't fit — here's what the behavioral research and the field reports converge on.
Make rank the frame, difficulty the currency. Ordinal position activates social comparison and competitive effort. Difficulty-weighted scoring directs that effort at the problems worth solving. Use both. A points total with no rank leaves the comparison implicit and unmanaged; a rank with a flat score produces a volume game.
Keep the difficulty signal coarse and external. Four or five buckets, assigned by someone other than the resolver, reviewed at the boundaries. Fine-grained difficulty scores are a precision theater that invites gaming. Coarse buckets carry the status signal — "that was a very-hard" — without pretending to measure complexity to two decimal places.
Watch the reference point. Loss aversion means that relative rank creates a felt loss every time a peer moves up. That's motivating in moderate doses and corrosive in large ones. Some teams mitigate by ranking in tiers (top quartile, middle, bottom) rather than strict ordinal position, which preserves the competitive frame while softening the zero-sum feel. Others rotate the board's window — last thirty days rather than all-time — so standing resets and nobody is permanently buried.
Instrument the failure modes before you ship. PR splitting, self-labeling, review farming, issue hoarding. Every scoring system has a shadow behavior. Write down the three you expect, then watch for them in the first month. The shadow behavior tells you what your metric actually rewards, which is often different from what you meant.
Don't rank what you can't attribute. If a piece of work's difficulty can't be reasonably assessed by a second party, it probably shouldn't carry heavy weight in a competitive score. On-call incident response, mentorship, and architectural review are all real contributions that resist clean ranking — pay them out in a non-competitive channel (recognition, comp, time) rather than forcing them onto the board.
Where This Is Heading
The interesting frontier isn't better leaderboards. It's adaptive ones. If rank displays reliably shift task selection toward difficulty — and the evidence so far says they do, conditional on the scoring — then the next step is tooling that adjusts the competitive frame to the team's current bottleneck. When the backlog is drowning in easy tickets, dial up the volume weighting. When the hard bucket is rotting, dial up the difficulty multipliers and make the rank board visible. When a senior engineer is burning out from carrying the hard bucket, rotate the window so the board resets and the load redistributes.
That's a feedback-control problem, and it's the kind of thing small teams can actually build, because you don't need a platform to do it — you need a scoring function, a display, and the discipline to watch what people do with it. The behavioral literature has given us the map: social comparison drives effort, loss aversion sharpens it, and the metric determines where it lands. The engineering work is building the loop so it lands on the bugs that actually matter. Teams that treat their internal dashboards as behavioral instruments rather than reporting artifacts will get the harder bugs fixed first — and they'll do it without anyone having to ask.