The Setups That Make Knowledge Circulate: Rotation, Game Days and Guilds

Role rotation, shared on-call, game days, guilds, InnerSource, onboarding: the organizational setups that keep knowledge from concentrating and make it circulate across the whole team.

In the guide to collaboration modes, we saw how to pass knowledge on in real time (the tacit) and in writing (the explicit). But a team can master all these practices and still watch its knowledge concentrate in a few people. The reason is structural: without a setup that forces it, knowledge follows the natural slope of specialization. This article deals with the organizational layer — not how we work together, but how we arrange things so that knowledge circulates by default.

I. Why practices aren’t enough  

Pair programming, ADRs, shadowing: all of this works, but it stays optional. The day pressure rises, you cut whatever isn’t mandatory — and you hand the urgent subject to the person who already knows it, because it’s the fastest. With every such decision, rational on its own, knowledge concentrates a little more.

That’s the limit of practices left to goodwill: they assume you’ll take the time to transfer, every day — when the immediate incentive always pushes the other way. Organizational setups flip this logic: they make the circulation of knowledge the default behavior, not an effort to consent to.

II. Role rotation  

The principle is simple: no one stays indefinitely the sole owner of a domain. You rotate people across components, subjects, and responsibilities.

Its effect on the bus factor is direct and measurable. A system that only one person knows has a bus factor of 1; getting three people to work on it over a quarter raises it to 3, with no dedicated training session — the transfer happens through real work.

A few forms of rotation:

• Rotation across components: everyone works, in turn, on parts of the system they don’t yet master.
• Rotation of responsibilities: the role of lead reviewer, or point of contact for a domain, rotates instead of freezing on one person.
• Supported rotation: you don’t throw someone alone onto an unknown system — rotation leans on pairing or shadowing to cushion the ramp-up.

The price is real: someone on a new domain moves more slowly at first. It’s an investment — the cost of insurance against the expert’s departure.

III. Shared on-call  

On-call is a special case of rotation, and the most powerful vehicle of operational knowledge transfer there is. The reason: No documentation, no training session imprints the knowledge of a system as durably as the obligation to repair it at three in the morning, under the pressure of a very real outage.

When on-call rotates across the whole team rather than weighing on a single person, several things happen:

• everyone discovers the system’s real failure modes, not its theoretical version;
• documentation gaps reveal themselves immediately — you write the missing runbooks, because you needed them;
• operational knowledge stops being one person’s preserve.

It’s the foundation of the “you build it, you run it” principle: those who build a service operate it. Nothing motivates making a system understandable like the prospect of being woken up by its outages yourself.

On-call concentrated on one person isn’t just a human risk: it’s the guarantee that operational knowledge will never circulate.

IV. Game days  

Waiting for a real incident to pass on operational knowledge means learning in the worst conditions. The game day flips the logic: you trigger the outage deliberately, as a team, in a controlled setting.

The principle, inherited from chaos engineering: you inject a failure (kill a service, saturate a queue, simulate the loss of a database) and the team reacts as if it were a real incident. You observe, you document, you fix.

What a game day transfers:

• the incident-response reflexes, exercised outside of real pressure;
• the shared knowledge of the system’s weak points;
• the validation of runbooks — a game day mercilessly exposes wrong or stale procedures;
• the team’s confidence in its ability to respond.

Its decisive advantage over a real incident: it’s planned, safe, and repeatable. You can put the least experienced people front and center, something you’d never dare in the middle of a crisis.

V. Guilds and communities of practice  

The previous setups make knowledge circulate within a team. Guilds make it circulate between teams.

A guild (or community of practice) brings together, around a cross-cutting domain — security, data, front end, quality — people from different teams. There they share their practices, harmonize their conventions, and spread what one has learned and the others don’t yet know.

Without them, each team reinvents the same solutions in its corner, and a useful discovery stays a prisoner of the team that made it. The guild is the channel that keeps silos from closing at the scale of the organization.

For it to stay alive, a few conditions: a real domain (not a pretext for a meeting), a regular but light cadence, and above all subjects that come from the members, not imposed from above.

VI. InnerSource  

InnerSource applies open source methods inside the company. Concretely: anyone can read and contribute to any internal repository, and each repository has maintainers who review and integrate contributions.

The effect on knowledge circulation is structural: code stops being the exclusive property of a team. A developer who needs a change in a neighboring service can propose it themselves, have it reviewed, and learn it along the way — instead of filing a ticket and waiting.

Silos fall by design: knowledge of a component is no longer locked inside the team that owns it, it becomes accessible to anyone who takes the time to contribute.

VII. The onboarding buddy  

The arrival of a new person is a pivotal moment: it’s when the team’s knowledge is transferred most intensely — or lost. The “figure it out, ask whoever you like” approach almost always fails, because the newcomer knows neither what to ask nor whom.

The onboarding buddy fixes this: a named point of contact accompanies the recruit through their first weeks. Their role isn’t to explain everything, but to be the contact who unblocks, points the way, and makes “silly questions” legitimate.

Good onboarding is also a revealer: the places where the newcomer gets stuck are exactly those where documentation is missing or where knowledge exists only in one head. Having them follow a real incident, comment on code with a veteran, contribute from the first week: that’s how you turn an arrival into a transfer.

VIII. How to combine them  

These setups reinforce each other:

• rotation and shared on-call spread knowledge within the team;
• game days exercise that knowledge without waiting for the outage;
• guilds and InnerSource make it cross the boundaries between teams;
• onboarding injects it at every new arrival.

What they have in common is decisive: they don’t rest on individual goodwill, but on an organization that makes the circulation of knowledge automatic. That’s what sets them apart from everyday practices — and what makes them robust when pressure rises.

Conclusion  

The best transfer practices aren’t enough if the organization itself pushes knowledge to concentrate. The setups in this article change the slope: rotation and on-call spread it through lived experience, game days train without risk, guilds and InnerSource break the silos, onboarding turns every arrival into an occasion to transfer.

It’s in this spirit that, in our team, we study Reinventing Organizations by Frederic Laloux to put some of these ideas into practice. The book describes organizations built on self-management and distributed authority — and it sheds light on a simple intuition: when decision and responsibility stop being concentrated, knowledge stops concentrating too. The setups in this article are its concrete translation, at the scale of an engineering team.

Remember the essential: you don’t transfer durably through goodwill, you transfer by design. A team that wants to survive the departure of its experts doesn’t count on everyone’s discipline — it arranges the world so that knowledge circulates whether people mean to or not.

Useful links  

• Google SRE Book — Being On-Call
  The reference chapter on on-call: healthy rotation, sustainable load, and its role in the operational mastery of a system.

• AWS — Chaos engineering on AWS
  An introduction to game days and controlled fault injection to test the resilience of a system and its team.

• InnerSource Commons
  Resources, patterns, and field experience for applying open source methods inside an organization.

• Spotify Engineering Culture (guilds and chapters)
  The original presentation of the guilds/chapters/squads model, often cited as a reference on communities of practice.

• Reinventing Organizations — official site (Frederic Laloux)
  The author’s site: an overview of the book, the “teal” organization concept, self-management, and free resources.