Add to Slack Picture the quarterly engagement survey arriving in Slack on a Tuesday. Your name is on every response that goes back. The question reads “How supported did you feel by your manager this quarter?”
You think about it for thirty seconds and pick a 4 out of 5. You meant to pick 3, but a 3 with your name on it would be a conversation, and you have a 1:1 with that manager on Thursday and you do not want the conversation. So you pick 4. The result lands on the dashboard. The manager reads it. Everyone agrees the team is healthy.
That is the question anonymity is for. It is also the thing anonymity costs. Once you turn it on, you cannot follow up on the response that worries you, because you do not know who sent it. The setting is a trade, every time.
When to turn it on
The decision usually breaks along three lines.
Turn it on when the question touches on a manager, a process, or a colleague by name. These are the questions where the gap between what people actually think and what they say with their name attached is biggest. You want the gap closed.
Turn it on when you are running a quarterly health-check or a culture survey, especially on a small or tight-knit team. The team that gives each other Christmas cards is not going to volunteer the manager feedback you need to read. Anonymity is what unlocks the floor of the range, not just the top.
Turn it on when past surveys on the same topic returned suspiciously positive answers. The most reliable sign you have a candour problem is that your last survey looked great and nothing changed. The next one is the place to fix it.
When to leave it off
The most common mistake is reaching for anonymity by default. It is a deliberate trade, not a free upgrade.
Leave it off when you need to act on individual responses. “Who wants the standing desk?” is a logistics question, not a feedback question. Same for offsite-date polls, lunch options, and any survey whose follow-up step is mailing one person something.
Leave it off when the question is operational rather than evaluative. “Which two days work for the offsite?” gives you nothing extra by hiding names. You still need to know who is available.
Leave it off when your team is small enough that anonymity is theatre. Below three respondents, Surveys hides results entirely (a k-anonymity guardrail to stop people from being identified by elimination). On a team of five, an anonymous survey with three responses leaves two suspects for any answer. The promise of anonymity is real but thin.
The toggle locks at publish
Once you publish an anonymous survey, the anonymity setting is locked. You cannot turn it off after responses arrive. This is deliberate. People who answered under the promise of anonymity should keep that promise, and walking it back retroactively would erode trust faster than not making the promise in the first place.
If you accidentally published with the wrong setting, the workaround is to end that survey, create a new one with the right setting, and re-invite the same audience. Painful, but cleaner than the alternative.
What anonymity actually means in the database
When you publish an anonymous survey, no name or user reference is attached to any response. The dashboard shows aggregate counts only. The per-respondent CSV export is unavailable, and the channel members the survey reached are not used to identify respondents (channels and DMs both honour the anonymity flag).
There is no halfway. Either every respondent is anonymous to you, or none of them are. That clarity is the point.
A rule of thumb
If the survey is evaluative and the team is more than ten people, turn anonymity on. If the survey is operational and you need to act on individual responses, leave it off. Almost every survey we run for our own team falls cleanly into one of those two buckets.
When you cannot tell which bucket a survey is in, the question is probably stacking two things into one. Split it.