Recognition that lands: why the shout-out channel goes quiet
The problem was never that people are ungrateful. It is that the work most worth acknowledging is the work least likely to be seen.
The shout-out channel has a shape you can set your watch by. Enthusiastic for a month, mostly the same six names. Then a fortnight where the only posts are from managers who have been reminded. Then it becomes the place where birthdays are announced.
This is usually diagnosed as a culture problem, and treated with a campaign asking people to post more. That works for about three weeks, for the same reason a reminder to drink more water works for about three weeks.
The actual constraint
Recognition has three requirements, in order. Somebody has to notice that a thing happened. They have to care enough to say something. And they have to do it, in a specific place, at a moment when they are almost certainly busy with something else.
Every recognition programme in existence targets the second and third of those. Almost none address the first, which is where nearly all of the loss occurs.
Think about what a senior engineer actually does in a week. They review eleven pull requests. They unblock two people in a thread that scrolls away by lunchtime. They notice a query that is going to be a problem in March and quietly fix it. They talk somebody out of a rewrite. Of those, the only one anybody outside their immediate orbit could recount a month later is possibly the rewrite, and only because there was an argument.
Nobody withheld recognition here. The events simply never entered anyone’s field of view. You cannot fix an attention problem with a prompt to be more grateful.
Three failure modes of the kudos channel
It rewards visibility, not contribution. The people thanked most are the ones whose work is inherently public, the ones who demo, who ship user-facing features, who present at all-hands. The person who made the deploy pipeline reliable gets thanked once, by the one colleague who understood what changed.
It has a social cost. Posting a public thank-you is a small act of self-exposure. Some people find that trivial and some find it excruciating, and the distribution of who posts is therefore a measure of comfort with public speech rather than a measure of who noticed something good.
It decays into politeness. Once a channel is established, not posting starts to look like an omission, so people post low-content thanks to avoid seeming ungracious. The signal-to-noise collapses and the genuine messages stop standing out, which is exactly when the people who valued it most stop reading.
What actually helps
Make the noticing automatic
A large fraction of good work already emits a record. A review approval is an event. A merge is an event. An incident resolved at 2am has a timestamp on it. None of that requires a human to observe and remember. If a system can turn those into acknowledgement without anyone having to act, you have removed the constraint that kills the channel.
Done well, the person who reviewed eleven pull requests has eleven things to show for it and nobody had to remember on a Friday. That is a much lower bar than it sounds, and almost nothing clears it, because every tool in this space is built to be posted into rather than to notice.
Make it specific, and make it an object
“Great work this week” is not recognition; it is politeness with a name attached. What lands is specific: what was done, and why it mattered. A named card, Zero Downtime, with “the users never knew, that was the whole achievement” under it, carries more than a generic message, because it says the thing you did has a name and it is a known kind of good.
It also persists. A message scrolls away in an afternoon. Something you hold does not, and being able to look back over a year of it is a materially different experience from remembering that people were nice to you at some point.
Keep peer recognition, and cap it
Automated acknowledgement cannot see everything. That is the whole argument of the first half of this post. The conversation where somebody talked a colleague through a hard debugging session emits no event, and it should still be possible to mark it.
The thing to get right is the economics. Uncapped peer points become a currency, and currencies get traded: reciprocal thanks, teams boosting their own, the slow inflation that makes the whole thing meaningless. A daily cap on how much one person can give solves most of it. Cap what goes out and what comes back separately, too: plus three then minus one nets the same as plus two, and only one of those is somebody working the system.
Never rank it
The single most damaging thing you can do to peer recognition is put it on a leaderboard. The moment gratitude has a ranking, it becomes a resource to accumulate, and the accumulation is more visible than the gratitude. Keep a running total if you like; it is useful on a person’s own profile, and it reads as a nice thing that happened. Sort everyone by it and you have built a popularity contest with a scoreboard, and the people who most deserve the thanks are usually the worst at collecting it.
What good looks like after six months
Not a busier channel. A quieter one, carrying a higher proportion of genuine messages, sitting alongside an automatic record that catches the work nobody would have posted about.
The measure worth watching is not volume. It is whether the distribution has widened, whether people whose work is structurally invisible are now getting acknowledged at all. If the same six names still dominate, the system is still measuring visibility, and no amount of encouragement will change that.
Related: the guide to employee recognition, why points and badges usually make this worse, measuring a team without it becoming surveillance, and what a card actually is.