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 (source), and replacing a senior engineer runs 6 to 9 months of their salary before you count lost context (SHRM).
We are Mobile Reality, 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 Flaree, and we run our own ~100-person distributed team on it. It is an employee recognition and engagement platform aimed squarely at the 50 to 400 band. A few things we deliberately got right, because they were the things that annoyed us elsewhere:
Slack-native, web-first. Recognition (a "Flaree") is one message inside Slack, and there is a full web app for everything else. No mandatory separate portal to nag people into.
Peer-to-peer by default. Anyone can recognize anyone. The interesting signal, sideways appreciation between engineers, is the default path, not an afterthought.
An API and webhooks, plus Zapier. This is the part engineers actually care about. One of our G2 reviewers, a PM, wired up JIRA automation so recognition fires on ticket events. If you can hit a webhook, you can automate it.
An engagement dashboard that flags disengagement early. Participation and trend data over time, so a manager sees a team going quiet before it turns into a resignation, not after. That was the whole point: turn recognition from a vibe into a measurable habit.
We kept a permanent free tier (Free Forever, includes Slack) because the Slack-channel crowd should be able to graduate without a sales call, and a 90-day full-feature trial with no credit card for teams that want to pilot the analytics. Paid is a flat few dollars per user per month; the current numbers live on the pricing page 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 G2 we sit at 4.6/5, all from teams in the mid-size band we built for. The recurring theme in the reviews is that it fits into the daily workflow instead of adding a chore, which, for an engineering audience, is the only review that matters.
Takeaways, tool-agnostic
Even if you never touch our product, the pattern holds:
- Put recognition where the work already is (Slack, the PR, the terminal), not in a portal.
- Make it peer-to-peer so you capture the sideways appreciation that manager-only tools miss.
- Instrument it. If you cannot see participation trending down, you cannot act before someone leaves.
- Do not over-gamify. Optional and self-aware, never surveillance.
If you want to see how we approached it, the tool is Flaree, 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.
Top comments (0)