Most organizations form teams the same way every time. A manager looks at a project, thinks about who has the right skills and availability, and assembles a group based on some combination of expertise, past performance, and who works well together. It's a sensible approach, and it produces a predictable outcome: the same clusters of people working together repeatedly, developing shared shorthand and efficient workflows but also shared blind spots, unchallenged assumptions, and an increasingly narrow view of how problems should be solved.
The alternative sounds reckless at first: randomize the teams. Not for every project, and not without guardrails, but deliberately and periodically, assign people to cross-functional groups using a random process rather than managerial selection. The idea has roots in research on organizational networks that consistently shows the same thing — the most innovative and resilient organizations are the ones with dense lateral connections, where information flows across departments rather than only within them. Random team assignments force those lateral connections into existence.
The mechanism is straightforward. When you work closely with someone from a different department, you learn what they know, how they think, and what problems they're dealing with. That knowledge doesn't disappear when the project ends. It becomes part of your mental model of the organization, and it changes how you approach future work. The engineer who spent three weeks on a team with someone from customer support now has a visceral understanding of what users complain about, not because they read a report but because they sat next to someone who fields those calls. The marketing person who worked alongside a data analyst now knows what kinds of questions the data can and can't answer, which changes the questions they ask going forward.
There's also a subtler benefit related to status and hierarchy. In self-selected or manager-selected teams, the same high-performers tend to cluster together, creating an informal A-team and leaving everyone else feeling like they're on the B-team. Random assignment flattens this. When the grouping is visibly random — when everyone can see that a team generator made the decision, not a manager playing favorites — there's no status signal in the assignment. People show up without preconceptions about who the "star" of the group is, which creates space for quieter contributors to step up and for dominant personalities to listen more.
The objection people raise immediately is that random teams will sometimes be poorly balanced — you'll end up with a group that's all junior people, or all from the same department, or missing a critical skill set. This is true, and it's why pure randomization without any constraints is a bad idea. The practical approach is constrained randomization: define the requirements (at least one person from engineering, no more than two from the same team, a mix of seniority levels) and then randomize within those constraints. The result is teams that are diverse and unpredictable in composition but still functional.
Companies that have experimented with this approach — particularly in hackathons, innovation sprints, and onboarding cohorts — report a consistent pattern. The first random team feels awkward. People miss the efficiency of working with familiar colleagues and spend more time negotiating norms and communication styles. By the second or third rotation, something shifts. People start building relationships they wouldn't have formed otherwise. Knowledge starts flowing through channels that didn't exist before. And the organization becomes harder to disrupt by the departure of any single person, because expertise and context are distributed more broadly rather than concentrated in a few tightly-knit clusters.
The point isn't that random teams are always better than deliberate ones. It's that the default of always choosing deliberately has costs that are invisible until you introduce some randomness and see what changes. Sometimes the most productive thing a manager can do is step back from the org chart and let a random process do the mixing.