Random Team Generator

Why "random teams" often feel unfair — and how to fix it

Uniform randomness over names does not produce balanced teams. People notice this immediately and blame the tool. Three mistakes are doing the work:

• Ignoring skill variance. With 10 players of varying ability and 2 teams, a uniform shuffle can dump the top 3 on one side. Given 10 people with roughly normal skill (σ = 1), a 5v5 uniform split gives a mean-skill difference with standard deviation ≈ 0.63 — meaning a ~30% chance the gap exceeds 1σ. If you want balance, do stratified sampling: sort by skill, pair adjacent players, then randomize within each pair. This tool does not stratify; it shuffles names.
• Odd group sizes feel rigged. 11 people into 3 teams gives 4-4-3, and the 3-person team always feels cheated. A fix is to rotate which team gets the short count between rounds, or to deliberately announce the odd team first so it doesn't look like a late decision.
• Not re-rolling on taboo pairings. In office settings, two people who shouldn't be on the same team (direct manager/report, romantic partners, known conflict) violate an implicit constraint the generator doesn't know about. Add an exclusion list and re-shuffle until satisfied; with a correct Fisher-Yates implementation each permutation is equally likely, so conditioning on constraints doesn't break uniformity over the feasible set.

The algorithm itself is fine. This tool uses Fisher-Yates (Knuth shuffle), which runs in O(n) and produces uniformly distributed permutations if the random source is uniform — which Math.random() is close enough to be for any group smaller than ~2^26 people. Edge case to watch: the common buggy version of Fisher-Yates picks the swap index from [0, n) instead of [i, n) at each step. It still looks random to the eye but is measurably biased. If you copy shuffle code from the web for anything that matters, test the distribution with a chi-square on ~10,000 runs.