Team Generator

Dividing a group of people into teams sounds trivial: shuffle the names, slice into N piles. The mathematics is straightforward but the social mechanics aren't. Office team-building, classroom group projects, sports five-a-side, kindergarten breakout groups, hackathon team formation, family game night — the same algorithm covers all of these, but the right defaults differ. This tool chooses unbiased random assignment as the universal default because it minimises the social cost of being assigned to a less-preferred group: nobody chose you, the algorithm did.

By count vs by size

"Team count" is the right mode when you want a fixed number of groups regardless of attendance — e.g. "always 4 teams for the inter-department challenge". The tool distributes evenly with leftover players going to the first teams (Team 1 gets the extra if the list isn't divisible). "Team size" is right when you want consistent team sizes — e.g. "5-a-side football, however many we have". The last team might be smaller than the others if the list isn't a clean multiple.

Why this uses Fisher-Yates + crypto.getRandomValues

Fisher-Yates is the only correct way to shuffle an array — it's been the standard algorithm since 1938 (originally published by Fisher and Yates for a randomisation table). The common JavaScript shortcut array.sort(() => Math.random() - 0.5) is biased and broken — V8's sort doesn't promise stable comparison semantics for non-deterministic comparators, so you end up with non-uniform results. Combining Fisher-Yates with crypto.getRandomValues means every possible team assignment is genuinely equally likely. For an office of 30 people split into 6 teams of 5, that's ~10^25 possible assignments. Math.random()-based shuffles can only reach a tiny fraction of that.

ASEAN team-formation patterns

How groups form teams varies regionally. Singapore offices tend to randomise to avoid the cliquey "always with the same colleagues" dynamic. Malaysian schools often divide by classroom seniority (P1 vs P2 vs P3), but random within seniority is also common. Indonesian university group projects tend to self-select — the tool's "by count" mode is useful when faculty want to break those patterns. Filipino workplace team-building events often use a "draw lots" tradition (literally drawing slips of paper); a digital tool with copy-to-clipboard replicates that with a public log everyone can see at once. Thai corporate retreats frequently combine random assignment with a "team naming" round — the tool covers the assignment; the naming is on you.

When NOT to use random teams

Random assignment is wrong for skill-balanced sports (the strong team will dominate), for projects that require specific role coverage (front-end + back-end + design), and for situations where social-comfort matters more than equal play time (a 4-year-old who only wants their best friend in the team). For those, a manual draft or skill-balanced sort beats random. For everything else — and there's a lot of "everything else" — random is the right default precisely because it's not negotiable.

For best results, run the generator at the start of the activity and announce the teams immediately. Delayed reveals invite negotiation ("can I swap with…") which defeats the purpose. The copy-to-clipboard output is plain text on purpose — it lands cleanly in any chat channel and stays scrollable as a reference throughout the session.