Picking random teams without starting a fight

"Random" is not what people actually want

The first thing to notice is that nobody actually wants a uniformly random partition of their group. If they did, they would be fine with a coin flip deciding whether to put all five of the strong players on one team. They want randomness within constraints: same-sized teams, no obvious imbalance, friends mostly mixed up, and nobody isolated.

That sentence packs at least four different requirements, and they sometimes contradict each other. Same-sized teams are easy. Balance is harder. Mixing up friend clusters is harder still. And "nobody isolated" is a soft constraint that you cannot encode without subjective judgement. What a good team picker does is let you choose which of these to prioritise for a given event, instead of pretending they are all the same problem.

Equal-sized vs equal-skill — pick one

The classic "shuffle and deal" approach gives you equal-sized teams. It guarantees that no team has more than one extra player compared to any other. That is the right algorithm if your group is fundamentally homogeneous — random adults at a company offsite, or a class of children where ability is not the point of the exercise. Use the Team / Group Divider for this case. It does a Fisher-Yates shuffle, then deals the result round-robin into as many teams as you asked for.

But if you are running anything competitive — a tournament bracket, a coding challenge, a sports practice — equal-sized teams are not enough. You will end up with one team that has all three captains and another that has none. For that case you want the Balanced Team Generator instead. It treats each person as having a tag (skill level, position, role) and distributes those tags evenly across teams before filling in the rest. The result is still random, but it is random conditional on the balance constraint, which is a very different distribution.

For really high-stakes balance — pickup basketball with a wide skill range, an e-sports scrim, a draft-style league — you want the Weighted Team Generator . Each player gets a numeric weight (1 for novice, 5 for expert), and the algorithm does a snake draft: highest-weighted player goes first, then the next two are assigned to opposite teams, and so on, switching direction each round. The result is as close to equal total skill as you can get without spending an afternoon doing constraint satisfaction.

Locked groups: the "Alice and Bob have to be together" problem

At every event, there are at least two people who must be on the same team. They carpooled, they are a married couple, they share equipment, they are the only two who speak the same language. The naive answer is "redo the draw until they end up together," which works statistically for small groups and gets exponentially worse as group size grows.

The cleaner answer is to treat them as a single unit during the shuffle, then expand them back into individuals at the end. Most of our tools (the Team Divider, Breakout Room Assigner, and Seating Chart) support this through a parentheses syntax: (Alice, Bob) on one line means "treat as one entry, drop them into the same team together." It means a team of four with a locked pair really has three independent slots plus the pair — the algorithm respects that without you having to retry.

The flip side — "Alice and Bob must not be on the same team" — is rarer in team drawing than it is in Secret Santa, but it does come up. (Two coaches running a practice, ex-partners at a friend's wedding, two students who cannot stop talking.) For now the standard solution is to put one of them on a small fixed team first, then let the picker fill in the rest from the remaining list.

Variable team sizes

Sometimes you want teams of variable size on purpose — a workshop where you want groups of three to five, a discussion event where small groups work better but you do not want to over-prescribe. For that case there is the Variable-Size Group Splitter . You give it a minimum and maximum, and it splits the list into groups that fall inside that range. The number of groups falls out of the math — fewer big groups, or more small ones, depending on the totals.

The trick with variable-size groups is what to do with the leftovers. If you have 23 people and you want groups of 4–6, you might get five fours and a three, or four fives and a three, or four fives and a four. The algorithm picks one randomly, because picking deterministically would feel unfair to whichever ends up in the smaller group every time.

Across sessions: avoiding the same pairs

For workshops, regular meetings, or classes that meet repeatedly, you usually want people to not end up with the same teammates every week. This is the "team rotation" problem, and it is harder than it looks. With ten people you can shuffle for a long time without ever repeating, but with five you will run out of unique groupings inside a month.

The pragmatic approach we use is to keep a per-device history of past pairings (stored in your browser, nowhere else), and ask the algorithm to prefer groupings that have happened less often. It is not a hard guarantee — for very small groups, repeats become unavoidable — but it consistently produces fresher combinations than pure random. If your event spans more than a single afternoon, this is the difference between people complaining "I always get the same group" and people actually meeting somebody new.

A short decision tree

If you remember nothing else from this post: ask whether you need equal sizes (use the Team Divider) or equal skill (use the Balancer or the Weighted Team Generator). If you have people who must stay together, write them as (Alice, Bob). If your group size is uncertain, use the Variable-Size Splitter and trust the leftover handling. And if you are running this event every week, turn on no-repeat mode so people actually meet somebody new each session.

Everything else — colours for the teams, captains, naming the teams — is human glue, not algorithm. Spend your time on that, and let the randomiser do the boring part.