Few topics divide engineering managers as much as leaderboards. On one side, the advocates: "Visibility creates motivation — top performers love being recognized." On the other, the skeptics: "Publicly ranking developers destroys collaboration and incentivizes gaming."
They are both right. The real question is not "leaderboard or no leaderboard?" — it is "which leaderboard, with which metrics, in which context?"
## The Debate: For and Against Leaderboards
### Arguments for
- **Public recognition is a form of respect.** Developers who deploy frequently, respond quickly to reviews, and maintain high quality deserve to be recognized. Engineering work is often invisible.
- **Leaderboards create a sense of progression.** Seeing your position evolve over time gives concrete feedback on personal improvement — the video game principle applied to work.
- **Transparency aligns behavior.** When everyone can see which practices are valued, behavior converges toward those practices.
### Arguments against
- **Individual rankings break collaboration.** If your position depends on your performance relative to colleagues, helping a colleague improve diminishes your competitive advantage.
- **Quantifiable metrics are easily gamed.** A leaderboard that rewards commit count generates micro-commits. Developers are engineers — they optimize what you measure.
- **Individual context is invisible in rankings.** The person who finishes last may be paying down complex technical debt, onboarding junior engineers, or designing an architecture that will not show up as commits for weeks.
A leaderboard measures what it values. If you value the wrong things, you will get wrong behaviors. Designing a leaderboard is an act of organizational design.
## Mistakes of Bad Leaderboards
### Mistake 1: Ranking by raw outputs
Ranking by commit count encourages valueless micro-commits, artificially split changes to inflate counters, and disadvantages developers working on long-horizon tasks. Ranking by lines of code is worse: code value is not proportional to code size.
### Mistake 2: Ignoring role context
A Tech Lead who spends 40% of their time in code reviews and 1:1s will never match the commit volume of a full-time feature developer. Comparing them on a single leaderboard is objectively unfair.
### Mistake 3: Displaying rankings without context
A leaderboard without context is a source of anxiety. The person at the bottom does not know why, or how to improve. This anxiety is particularly damaging for developers going through a difficult period.
### Mistake 4: Making the leaderboard permanent with no resets
A fixed ranking creates fixed identities: "the top performer" and "the bottom." These identities become self-fulfilling prophecies.
## What Makes a Healthy Leaderboard
### Principle 1: Celebrate behaviors, not volumes
Healthy leaderboard metrics are measurable, resistant to gaming, and aligned with valuable behaviors:
- **PR review rate under 24h** (encourages a responsive review culture)
- **Successful deployment rate** (values quality)
- **Lead time improvement trend** (celebrates progress, not absolute level)
- **Incident-free deployment streak** (collective or individual)
### Principle 2: Prioritize the team over the individual
Team leaderboards — where the unit of measurement is the squad or service, not the individual — create solidarity rather than competition. "Our team moved from High to Elite on MTTR this quarter" is a collective celebration.
If you want individual leaderboards, making them opt-in is a sound practice.
### Principle 3: Reward progression, not absolute position
A developer who goes from a 10-day Lead Time to 3 days has made remarkable progress, even if they are still below the team's top performer. A leaderboard that celebrates progression rather than absolute position includes everyone in the positive dynamic.
### Principle 4: Make metrics resistant to gaming
Before adding a metric to a leaderboard, ask: "How could a developer optimize this metric without creating value?" If the answer is obvious, the metric is not suitable.
- "Number of PRs opened": easily gamed (trivial PRs)
- "First-attempt PR merge rate": more resistant (encourages quality before opening)
### Principle 5: Provide context alongside rankings
Every leaderboard position should come with context: what is the team average? What is the trend over the last 30 days? In which metrics does this person excel?
## Conclusion
An engineering leaderboard is not inherently good or bad. It is a tool whose effect depends entirely on its design.
A leaderboard that measures the wrong things in a low-trust environment is indeed toxic. But a leaderboard that celebrates positive collective behaviors, in a culture of trust and transparency, can become a powerful driver of motivation and continuous improvement.
The question to ask is not "should we build a leaderboard?" but "what do we want our team to feel when they look at it?" If the answer is "motivated to improve collectively" — you can build it. If the answer is "watched" — the problem is not the leaderboard. It is the management culture it reflects.
DevLyTicks implements a gamification model built around progression and collective contribution — visible at devlyticks.com.
Top comments (0)