The morale problem nobody puts in the sprint board
Distributed engineering teams have a blind spot. You can see build times, PR throughput, incident counts, and cycle time on a dashboard. You cannot see the senior engineer who quietly stopped caring three sprints before they resigned.
Recognition is the usual answer, and most teams do it badly. It lives in a Slack channel that goes quiet after two weeks, or in a once-a-quarter manager shoutout that everyone forgets by Monday. For engineers specifically, that gap is expensive: O.C. Tanner found 79% of people who quit cite lack of appreciation as a reason (, a distributed software house. We hit this exact wall on our own team, tried the off-the-shelf options, and eventually built the tool we wanted. This post is the honest version: what recognition tooling should do for an engineering org, what we learned, and where our own product fits. Disclosure up front so you can weight it accordingly: the tool at the end is ours.
What "recognition tooling" should actually do for engineers
Skip the HR-brochure framing. For an engineering team, a recognition tool is worth installing only if it clears a few bars:
It has to live where the work lives. Engineers are in Slack, in the terminal, in the PR. A recognition tool that requires opening a separate SaaS portal is dead on arrival. If it is not one message away, nobody uses it.
It has to be peer-to-peer, not top-down. The most meaningful recognition on an engineering team comes sideways: the person who unblocked your deploy at 6pm, the reviewer who caught the race condition. Manager-only recognition misses 90% of what actually happens.
It has to produce a signal, not just warm feelings. The reason to instrument recognition at all is the same reason you instrument anything: so you can see a trend before it becomes an incident. A recognition channel with no analytics is a nicer version of nothing.
It cannot be gimmicky in a way that engineers reject. Points and leaderboards are fine when they are self-aware and optional. They become poison the moment they feel like a performance-review surveillance layer.
What we tried first
Before building anything, we ran the obvious playbook.
A dedicated Slack channel. Free, zero setup, and it worked for about a month. Then it decayed into the same three extroverts posting and everyone else lurking. No history you could query, no way to tell if participation was actually broad or just loud.
A points bot bolted onto Slack. Better engagement for a while, but the tools we tried were built for generic office teams. The card catalog was cheesy, there was no real analytics layer, and pricing assumed a 5,000-person enterprise, not a lean team in the 50 to 400 band where most software shops actually sit.
The gap was consistent: either free-and-shapeless, or paid-and-bloated-for-enterprise. Nothing sat in the middle and treated a mid-size distributed team as the primary user.
What we ended up building
So we built , and there is a full web app for everything else. No mandatory separate portal to nag people into.
, plus rather than here, since I would rather you check the source than trust a blog post.
Does it move the needle?
Honestly, recognition tooling is not magic and I am not going to pretend it is. The research is real though: Gallup finds teams with regular recognition see meaningfully higher engagement, and Bersin/Deloitte tied strong recognition cultures to 31% lower voluntary turnover. Our own internal target is 60%+ monthly participation, which is the number we watch because participation breadth is what separates a real culture signal from three loud people in a channel.
On , and there is a longer writeup of running our own team on it in the case study. Happy to answer questions in the comments about the engineering side of building it.
SOCIAL SHARE CARD GENERATOR