the 5-person rule: how small teams stay anonymous

if your team has fewer than 5 people answering a pulse survey, jollygig does not show you a result. not a partial result, not a "directional" result. a tile that says, plainly, that we don't have enough yet.

this is the kind of thing that sounds like a minor product detail and is actually load-bearing. the floor is what makes the rest of the anonymity story true. without it, "anonymous" is just a sticker.

why a floor exists at all

anonymity at the database is necessary but not sufficient. you can strip the user id off every response and still re-identify people through the shape of the aggregate.

imagine a team of three. two answered "fine, mostly," one answered "not great." the manager knows the team. they know who's on parental leave, who just got promoted, and who's been quiet in standups. with three responses, the aggregate is a thin wrapper around three individual answers. anonymity has been preserved technically and lost operationally.

a floor is the structural fix. it says: until enough people have answered that no single response is reverse-engineerable, the product shows nothing. the only honest tile is one that admits the data isn't ready.

why 5

5 isn't a magic number. it's a tradeoff between two failure modes.

set the floor too low and you let small teams reverse-engineer answers. a team of two with both responses in is not anonymity. a team of three is not anonymity either; it's a group dynamic with a label on top.

set the floor too high and you stop being useful to small teams. a 25-person minimum sounds rigorous on a procurement form and means most of your customers never see a result. it's also the implicit policy of every enterprise survey tool that markets itself to "teams of 100+" and quietly excludes everyone else.

5 is the smallest count where, in practice, a thoughtful manager looking at the result cannot confidently attribute any individual response. it's small enough that real teams of 6 to 12 can actually use the product. it's large enough that the aggregate isn't a fingerprint.

we'll keep iterating on it — there are scopes where 5 isn't enough, and we treat that as a product question, not a settled answer. but 5 is the default floor and it applies everywhere until we have a defensible reason for it not to.

what "no result" looks like

a lot of products quietly fall back to showing a partial result with a small caveat — usually a line of grey copy below it. that's worse than showing nothing. people read the number and ignore the caveat; it's how reading works.

so the product shows a tile that says, plainly: we don't have enough responses yet, here's how many we have, here's what changes when we cross the threshold. no number. no "directional" arrow. no implication of a trend. the absence of a result is itself the result.

this is, occasionally, frustrating. a manager wants to know what's going on. that's a fair instinct. but the deal we made with the team is that the result will not let anyone be picked out, and the deal is more important than the manager's curiosity in any given moment.

the floor applies to slices, not just teams

if a team has 30 members and a manager wants to slice by tenure band, each band is its own anonymity unit. a tenure band with 3 people in it does not get a result. neither does a role level with 4. neither does a location filter that narrows the population to 2.

you can imagine how seductive it would be to relax this. "the team has 30 people, surely we can slice." no. the moment the slice is small, the slice is the unit, and the unit needs the same floor.

this is also where most products get clever in a bad way. they let you slice and then show a blurred or rounded number, sometimes with a "low sample" badge. the badge is meant to indicate that the data is imprecise. it does not address the actual problem, which is that the slice can be re-identified.

the floor is enforced at the database, not in the ui

a policy in the ui is a policy. a constraint in the data layer is a property of the system. these are different things.

in jollygig, the floor is enforced by the queries that fetch results, not by the components that render them. you cannot ask the database for a sub-threshold result and have it come back. the only way to relax the floor is to change the query layer, which requires a code change, which requires a code review.

that's not security theater. it's a way of pushing decisions into places where they get deliberated, instead of into places where they get clicked through.

what we'd lose if we fudged it

every honest product has a few load-bearing constraints, and the cost of relaxing any one of them is the entire trust posture of the product.

if we showed a result at 4 responses, we'd save a few "still gathering" tiles for our smallest customers. we'd also tell every careful customer that the floor is negotiable, which means it isn't a floor.

we'd rather be slightly less useful to a team of six in week one than be the product that everyone has to assume might fudge things when their team is small. it's a cheap thing to give up.

if the floor matters to you, here's what to look for in any tool

not just ours. if you're evaluating pulse-survey tools and structural anonymity is something you actually care about, three questions are worth asking the vendor:

1. what's the minimum population size below which you don't show a result, and is it enforced at the data layer or only in the ui?
2. does that floor also apply to slices and breakdowns, not just whole-team views?
3. when the floor isn't met, what does the manager see — nothing, a partial result with a caveat, or a blurred number?

the answer pattern that should make you nervous is "no formal minimum, we leave that to admin discretion." admin discretion under sustained curiosity is a known failure mode.

if any of this is the kind of detail that makes you trust a tool more, you can try jollygig free for 30 days. the floor is in place from minute one.