Why workplace gamification usually fails, and the two cases where it does not

There is a version of this that everyone has seen. A dashboard appears with points on it. For two weeks people check it. By week six the only people still looking are the three at the top, and one of them has worked out that closing tickets in small pieces scores better. By the end of the quarter it is a link nobody clicks, and the phrase “we tried gamification” enters the organization’s vocabulary as a warning.

None of that is bad luck. It was predicted decades before anyone put a leaderboard in a work tool, and it happens for a reason you can design around.

The mechanism that kills it

The relevant research is on what happens when you attach an external reward to an activity somebody was already doing willingly. The finding, replicated across a lot of contexts, is that the reward tends to reduce the underlying motivation rather than add to it. The activity gets reframed. It stops being something you do because it is interesting or because it matters, and becomes something you do for the points, and when the points stop being interesting, so does the activity.

This is precisely the wrong medicine for most engineering teams, because most engineers are not suffering from insufficient motivation to do good work. They are suffering from nobody noticing that they did it. Those problems look similar on a survey and have opposite treatments.

Four failure modes, in the order they arrive

The number becomes the target. Any single metric exposed as a score will be optimised, and optimisation almost always means finding the cheapest input that moves it. Ticket counts produce smaller tickets. Line counts produce verbose code. Review counts produce approvals that took eleven seconds. This is not people cheating; it is people responding accurately to what you told them you valued.

The same three people win forever. A cumulative score over a whole organization is decided within a few weeks, usually by tenure and by which team happens to work on the fastest-moving service. After that the ranking is static, and a static ranking is not a game. It is a notice board.

Invisible work scores zero. The mentoring, the incident nobody heard about because someone caught it on Sunday, the design document that stopped a bad project. None of it emits an event. A system that rewards only what is instrumented tells everyone what the organization can see, which is not the same as what it values, and people update on the first one.

The rewards are worthless and everyone knows it. A badge that everyone gets is not a reward. A badge nobody can get is not one either. Getting this distribution right is a real design problem, and most implementations do not treat it as one.

The two cases where it works

Both exceptions share a property: the game element carries information, rather than being a wrapper around a number.

One: when it is recognition rather than competition

A specific, named acknowledgement that a specific thing happened is not the same object as a score, even though both are often called gamification. “Caught it alone on a Sunday, fixed it, and mentioned it to no one” is a sentence about a person. A rank of seventh is not.

A collection behaves differently from a points total. Give the reward a name, a rarity and a line saying what it was for, and two people holding the same one are not competing: they have both done the thing. And the motivating part of any collection is not what is in it. It is the gap, which does not reset on the first of the month the way a ranking does.

Two: when the randomness is honest

A guaranteed reward per unit of work is a piece-rate, and people respond to piece-rates by producing more, smaller units. A chance of a reward behaves differently. It cannot be farmed efficiently, because the marginal return on gaming it is low and obviously so, and it keeps the good outcomes feeling like events rather than entitlements.

The condition is that the randomness has to be genuine and understood. A draw that quietly favours the people already ahead is worse than no draw at all, and gets found out, since engineers are unusually good at noticing when a distribution is not what it claims to be.

What to check before you roll anything out

• Would this still be worth having if you deleted the ranking? If the answer is no, you have built a scoreboard and should expect a scoreboard’s lifespan.
• Can somebody who does excellent invisible work get anything? If every reward requires a merged pull request, you have told half the organization the game is not for them.
• What is the cheapest way to cheat it, and what does that behaviour look like? Work it out in advance, because somebody will, and if the cheat is also mildly harmful you have a real problem.
• Does anything ever get taken away? If not, the distribution flattens over time and the whole thing decays into participation trophies.
• Who is this for? If the honest answer is that leadership wanted visibility, say so and build the visibility. Do not dress it as a reward programme; people can tell, and the disguise is what makes them cynical.

The uncomfortable version

A lot of what gets sold as gamification is a measurement programme with a friendly interface. That is not automatically bad: measurement is often exactly what an organization needs, but pretending it is a reward is what generates the backlash. If people work out that the fun thing was the delivery mechanism for the ranking, you have lost both.

The version that survives is the one where the two are genuinely separable: the aggregates that answer a leader’s question, and the collection that belongs to the person who did the work, feeding off the same events but serving different people. Neither is pretending to be the other.

Related: what recognition that works looks like, designing a leaderboard that does not produce the behaviour you were avoiding, why recognition schemes go flat and what to do instead, and how the card and pack system actually works.