Engineering Team Leaderboard: Motivation or Toxicity?

    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.