How to Split People Into Random Teams

Why not captains

Picking captains and letting them choose is the oldest method and the worst one. It produces a public ranking of the group by perceived value, and the person picked last remembers it for a long time.

It is also slow, and it does not even produce better teams — captains pick friends, not balance.

Random assignment removes all of that. Nobody is chosen, nobody is left, and the answer to "why am I on this team" is "the shuffle put you there", which is not a judgement about anyone.

Dealing beats chopping

There are two ways to turn a shuffled list into teams, and they are not equivalent.

Chopping takes the first quarter of the list as team one, the next quarter as team two, and so on. Simple, and it goes wrong with awkward numbers — 22 people into 4 teams by naive chopping can produce 6, 6, 6, 4.

Dealing hands out names one at a time around the teams, like cards. 22 people into 4 teams gives 6, 6, 5, 5, and sizes can never differ by more than one.

The random team generator deals. It shuffles the full list first with a Fisher–Yates shuffle driven by crypto.getRandomValues(), then deals round-robin — so the order is random *and* the sizes come out even.

Choosing the group size

The number matters more than people expect:

• Pairs — everyone talks; nowhere to hide. Best for practice and discussion, worst for anything needing several perspectives.
• Threes — the most robust size for group work. Big enough for different ideas, small enough that nobody can disappear.
• Fours — good for tasks with distinct roles. Also splits neatly into two pairs.
• Fives and six — needs a task big enough to justify it, otherwise two people do everything.
• More than six — expect passengers unless the task genuinely requires that many.

Set Split by to *People per team* when the size matters more than the count, and *Number of teams* when you have four tables or three breakout rooms.

Leftovers

Groups rarely divide evenly, and how you handle the remainder is a real decision.

By number of teams, dealing handles it automatically — the extra people go to the first teams and sizes stay within one.

By people per team, the last group takes the remainder. 17 people in groups of 5 gives three fives and a two. A group of two where everyone else is in five is often a problem, so either move a couple of people by hand, or switch to *Number of teams* with 4 and get 5, 4, 4, 4 instead.

For an odd number in pairs, the usual fix is one group of three rather than leaving someone alone.

When to override the shuffle

The generator only sees names. It knows nothing about ability, language, friendships, conflicts or who cannot work with whom — and for a lot of real groups those things matter.

The approach that works is random first, then one or two corrections:

1. Generate the split.
2. Scan it for the specific problems you know about.
3. Swap the minimum number of people to fix them.
4. Do not explain each swap; announce the teams.

That keeps most of the fairness while avoiding the two or three arrangements you know will not work. Trying to balance everything by hand from scratch takes ten times as long and produces teams that look chosen — which brings back the objection random assignment was solving.

One thing not to do: regenerate repeatedly until you get an arrangement you like. That is hand-picking with extra steps, and if anyone notices how many times you pressed the button, it looks exactly like what it is.