Overview
Anonymity is the condition for honest signal. If your team doesn't trust it, you won't get candid responses. This guide covers how Relay's anonymity actually works and what to say when people are sceptical.
Why the question comes up
People have been burned before. An 'anonymous' survey where the manager referenced results in the next all-hands. A feedback system where responses were confidential to HR but used in a performance review. A pulse check where someone's phrasing made it obvious who'd said what.
Those experiences are common enough that scepticism about anonymity is a rational default, not a paranoid edge case. When you introduce Relay, you're asking people to trust a process that's been designed to earn that trust. But they don't know that yet. You have to tell them.
The teams that generate the most honest signal are the ones where a manager took ten minutes at the start to explain how the anonymity actually works. Not to sell Relay. To tell the truth about the design.
What anonymity actually means in Relay
Relay is designed so that individual responses cannot be identified, even by us. When someone answers the check-in, their response is aggregated before any manager or administrator sees it. There is no individual attribution layer that's hidden or 'viewable by admins.' The aggregation is the only version that exists.
There is a minimum threshold before results appear. If fewer than a certain number of people in a team respond in a given week, no results are shown. This protects small teams or weeks with low response rates: if three people are in a team and two respond, showing the score would make the third person's position obvious by omission. The threshold means that doesn't happen.
Comments are anonymous too. There is no metadata attached to them. Relay does flag comments that contain identifying information, like a name or a direct reference to a specific incident, and asks the respondent to review before submitting. That's not surveillance. It's protection: the system is preventing someone from accidentally compromising their own anonymity.
How to explain it in plain language
You don't need to explain the architecture in detail. Most people need to know two things: who can see what, and whether their response can be traced back to them.
Something like: 'When you answer the weekly check-in, your response goes into an aggregate. I see a score and themes from the comments. I don't see who said what. Relay is designed so that nobody can, including Relay. If not enough people in the team respond in a given week, I don't see any results at all.' That's the whole explanation.
If your team is sceptical, the most useful thing you can do is show them. Pull up Relay in a team meeting and walk through what you see as a manager. A team that watches you navigate the dashboard and sees no names, no individual responses, and no attribution usually becomes less sceptical. Seeing the interface is more convincing than a verbal reassurance.
What if they're still not sure
Some teams carry a higher level of distrust. They've worked in environments where anonymity was offered and then quietly violated. That distrust doesn't resolve in one conversation.
The answer is consistency over time. Close the loop in a way that never suggests you know who said what. Don't follow up on a comment in a way that could narrow it down. Don't share scores in formats where individuals might feel pressure. Every week you handle the results carefully is a week of trust earned.
You can also acknowledge the scepticism directly: 'I know it's hard to trust a new system. The best evidence I can offer is how I respond to the results over the next few weeks. Judge it then.' That's honest. It's also the only thing that actually works.
Anonymity isn't a feature you set up once. It's a promise you keep week after week through how you respond to what you hear. The design protects it architecturally. The rest is how you behave with the results.