Random team generator

The two ways to divide a group

Those two options in the dropdown are not the same question, and picking the wrong one is the most common source of confusion here.

Number of teams is what you want when the number of groups is fixed by circumstance — four tables in the room, three project slots, two sides of a pitch. You say “three teams” and everyone gets distributed across them. With twelve people you get 4/4/4; with thirteen you get 5/4/4, because the remainder has to land somewhere and we spread it one person at a time rather than dumping it all on the first team.

People per team is what you want when the group size is fixed by the activity — pairs for an exercise, groups of five for a board game, triples for peer review. You say “four per team” and we make as many full teams of four as the roster allows. If the roster does not divide evenly, the last team is smaller, and you can see immediately whether that leftover group of one is a problem you need to solve by hand.

What “fair” means here, and what it doesn't

This tool distributes people randomly, which is not the same as distributing them evenly by ability. It has no idea who your strongest player is, and it will cheerfully put the four best people on one team. That is the correct behaviour for a random split, and it is worth saying out loud because “random teams” and “balanced teams” get used interchangeably and are opposites in one important respect.

If you want balance by skill, the usual approach is to sort people into tiers yourself, then run this tool once per tier and deal the results out across the teams. Two minutes of work, and it keeps the randomness where it belongs — inside each tier — while guaranteeing every team gets one strong player.

What random splitting is genuinely good at is removing the social cost. Schoolyard captain-picking is efficient and quietly brutal; the last person chosen remembers it. A shuffle takes the decision away from everyone in the room, which means nobody has to defend it and nobody was rejected. In a workplace the same logic applies to who reviews whose work: random assignment removes the suspicion that pairings were arranged.

Notes on using it

• Run it in front of people. If the split matters socially, generate it while everyone is watching. A result that appears after a private consultation invites the question of whether it was really random.
• Accept the first result. Regenerating until you like the teams is the most common way a random split quietly stops being random. If you are going to override it, override it openly and say why.
• Copy before you close. Nothing is stored, so copy the result into your notes or chat if you will need it in ten minutes.
• Absences. Remove people who did not show up before generating, rather than reassigning afterwards — otherwise the sizes stop matching what the tool told you.

Can I keep two people together, or apart?

Not directly, and that is deliberate: once a tool starts honouring constraints, the result stops being a random split and becomes a puzzle solution, which is a different thing that should not be labelled random. For one or two hard constraints, the practical method is to set those people aside, generate teams for everyone else, then place them where you need them — and tell the group you did.

Why did I get fewer teams than I asked for?

Because there were not enough people to fill them. If you ask for eight teams from five people, three teams would be empty, so we drop them rather than showing blanks. Asking for more teams than people is almost always a typo in the number field.