The work most worth noticing is the work least likely to be seen.

Why recognition programmes go quiet

Recognition needs three things in order. Somebody has to notice. They have to care enough to say something. And they have to do it, in a particular place, while busy with something else. Almost every programme targets the second and third. Nearly all the loss happens in the first.

Think about anyone senior’s week. A support lead defuses two accounts that were about to churn. A finance analyst catches an error before it reaches a board pack. An engineer reviews eleven changes and unblocks two people in a thread that scrolls away by lunch. A month later nobody outside their immediate orbit could recount any of it. Nobody withheld anything. The events never entered anyone’s field of view.

What actually helps

Make the noticing automatic. A large share of good work already leaves a record somewhere: a ticket resolved, a deal closed, a renewal saved, a change shipped, an incident handled at 2am. If a system turns those into acknowledgement without anyone having to act, you have removed the constraint that kills the channel.

Make it specific, and make it an object.“Great work this week” is politeness with a name attached. What lands is what was done and why it mattered, and something that persists, because a message scrolls away in an afternoon.

Keep peer recognition, and cap it. Automated acknowledgement cannot see the conversation where somebody talked a colleague through a hard bug. Uncapped peer points become a currency and get traded; a daily cap solves most of it.

Never rank gratitude

The most damaging thing you can do to peer recognition is sort it. The moment thanks has a ranking it becomes a resource to accumulate, and the accumulation is more visible than the thanks. Keep a running total on someone’s own profile if you like. Do not build a leaderboard out of it. The people who most deserve the credit are usually the worst at collecting it.

What to reward, and how often

The instinct is to reward the big things: the launch, the quarter, the save. Those are already visible; they get mentioned at the all-hands whether or not you build anything. The work that needs a system is the steady, unglamorous kind: the review nobody asked for, the runbook written before it was needed, the customer talked down on a Friday afternoon.

Frequency matters more than size. Something small and frequent keeps a habit alive; something large and rare becomes a lottery people stop thinking about. And a reward should be specific enough to be quotable. If the person receiving it cannot repeat what it was for, it was a notification rather than recognition.

Be deliberate about the shape, too. 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, and the good outcomes stay events rather than entitlements.

Rolling it out without it dying

1. Start with what already leaves a record. Anything that requires a human to remember will decay to whoever is most conscientious.
2. Make sure someone whose work is structurally invisible can receive something. If every reward requires a merged change, you have told half the company the game is not for them.
3. Work out the cheapest way to game it before you launch, because somebody will. If the cheat is also mildly harmful, redesign.
4. Keep a peer channel alongside the automatic one, and cap it daily.
5. Never rank the peer channel. Not once, not as an experiment.

What good looks like after six months

Not a busier channel. A quieter one carrying a higher proportion of genuine messages, sitting beside an automatic record that catches what nobody would have posted about. The measure worth watching is whether the distribution widened, whether people whose work is structurally invisible are getting acknowledged at all. If the same six names still dominate, the system is still measuring visibility.