Every team makes dozens of small allocation decisions a week: who presents, who takes the notes, who goes to the conference, who covers the weekend. Individually they are too small to matter. Repeated a hundred times, they accumulate into someone’s perception of how the place treats them.
That is the actual problem randomisation addresses. Not “picking a winner” — distributing a recurring decision so it stops being read as judgement.
Here is where it works, in rough order of usefulness, and where it does not.
The Strong Cases
1. Divided resources. The training budget, the good desk, the parking spot, the extra screen. This is the strongest case of all, because scarce resources allocated by preference generate visible resentment, and a draw ends the question. Use Lucky Draw.
2. On-call and rota gaps. Nobody volunteers for Sunday. Drawing removes the recurring suspicion that the same person is always the one who “happens” to be available. Expect the log to be lumpy — that is independence, not a broken process.
3. Committee and review-panel seats. A selection committee that people believe was curated will be questioned on every decision it makes, whatever the merits. Randomise the seats, not the candidates.
4. Meeting and sprint order. Who presents first. Who gets the first slot back from leave. Small, but the rotation argument recurs forever otherwise.
5. Demo or pitch order. Related to the above, and it works because everyone is going to go eventually.
6. Task and chore rotation. Cleaning, on-call support, the meeting nobody wants to chair. Task Matcher pairs people with tasks and reports anything unassigned rather than silently dropping it.
7. Which lunch, which after-work activity. Genuinely useful: it converts a fifteen-minute debate into a two-second outcome, which is the only way those decisions get made at all.
8. Pairings for mentoring or shadowing. Randomise within skill bands rather than across the whole team — see below, this one has a failure mode.
9. Spot awards and peer recognition. Drawing from a nominated pool works, provided the nomination step is genuine. Randomising a pool nobody qualified for is a different thing.
10. Project team formation. Strongest when the project is genuinely cross-functional and nobody has a reason to prefer anyone’s company.
Where It Goes Wrong
Anything with a skill requirement. Randomising a task that needs a certification guarantees you will sometimes assign it to the wrong person. Randomise everything around the requirement, not the requirement itself.
Anything long-term or irreversible. A project team for a whole quarter, a permanent committee seat, a promotion decision. “The draw said so” is not an acceptable reason for anything a person will still be living with in six months.
Anything where you cannot repair the result. If the draw produces something operationally broken — two people who cannot work together on a two-week task, the only person who knows the client assigned to a client call — you have created a problem to avoid embarrassment.
Weighted draws dressed up as fair. If a draw was weighted by role or performance, it is not random selection in the sense people assume. That is fine, and defensible, but only if you published the weights before drawing. The Weighted Raffle makes the weighting explicit precisely so this can be said out loud.
Group Formation Has a Failure Mode Worth Knowing
Random project teams sound like a cure for cliques. They are also the single most common way random selection gets discredited in an office, because a purely random split of a team with uneven skills produces one unworkable group.
The mechanic is straightforward: one exceptional person lands in one group, and every task that group touches becomes predictable. Everyone sees it immediately, and the conclusion drawn is that randomisation is naive.
The fix is to randomise within skill bands rather than across the whole team. Seat the two people you know are strongest into separate groups first, then draw the rest. Group Maker handles the draw; the band logic is yours.
Practices That Decide Whether It Lands
Run draws where people can see them. Screen-share, or do it in the room. A random process nobody witnessed is indistinguishable from a biased one, so the witness is what makes the difference real rather than asserted.
Show the list, not just the result. The participant list on screen is the evidence that everyone eligible was in the pool. A screenshot showing only the winner proves nothing about how they were chosen.
Apply it consistently. Random selection used when convenient and judgement used when it suits you is worse than never adopting it, because people learn that the draw is a performance. This is the single most important habit.
Announce what you will randomise. “The conference attendee will be drawn from everyone who has not been this year” is a sentence that removes an entire category of complaint.
Keep the record. A dated note with the list and the result prevents more arguments than any process change, and it takes thirty seconds.
A Note on Tooling
The relevant claims about the mechanism are short. Draws use the browser’s cryptographic random source rather than Math.random(), which is deterministic and can in principle be anticipated — the fairness page explains why that matters and what rejection sampling adds. Groups can be exported as CSV or XLSX, printed, or copied as text. Nothing requires an account, and there are no daily limits on draws.
What matters more than the tooling is whether the process was announced in advance and applied consistently. A fair draw with an unexplained rule is still experienced as unfair, and an unfair-looking draw with a well-explained rule usually is not.
Start With One
Pick the resource that causes the most argument this quarter. The training budget, the desk, the weekend cover. Randomise it once, publicly, and see whether the topic stops coming up.
It usually does within a month, and it frees attention for the decisions where judgement is actually the right tool.