Sharing Knowledge in a Tech Team: A Guide to Collaboration Modes

Pair programming, mob, shadowing, ADRs, on-call rotation… An overview of the ways knowledge travels within a team, and how to choose the right one based on the nature of the knowledge you need to pass on.

In “When the last expert disappears,” we saw why a team’s memory is an invisible form of technical debt. What remains is how to fix it. Pair programming, mob, shadowing, code review, ADRs, on-call rotation: there is no shortage of practices, and that is precisely the problem — you don’t know which one to pick. This guide maps them out and gives a simple rule for deciding.

I. Two kinds of knowledge: tacit and explicit  

Before choosing a practice, you need to know what you are passing on. All team knowledge falls into two families, and they don’t obey the same laws.

• Explicit knowledge — what can be written down. An architecture decision, a restore procedure, a regulatory constraint, the reason behind a parameter. It travels very well in writing, and writing has a decisive advantage: it survives departures and can be read at any hour.
• Tacit knowledge — what cannot be written down. The diagnostic reflex, the intuition, the mental map of hidden dependencies, the judgment built over ten years of incidents. That one travels only through contact: by watching someone do it, and by doing it under someone else’s eye.

From this follows the rule that structures this whole guide:

Tacit knowledge requires synchronous contact. Explicit knowledge travels asynchronously.

The classic mistake is trying to solve everything with documentation. A wiki will never capture an intuition — and conversely, pulling five people together to pass on a procedure that a manual could carry is a waste.

II. Synchronous modes: passing on the tacit  

They come at a cost — several people on the same subject at the same time — and with a unique value: they are the only way to pass on what cannot be written down.

• Pair programming: two people, one keyboard. A driver, a navigator, and a regular rotation of roles. It’s the baseline mode, and the most flexible.
• Mob programming (or ensemble programming): the whole team on a single problem. Expensive on the surface, but unbeatable for getting everyone aligned on a critical subject.
• Shadowing: the apprentice observes the expert at work, then you swap — the apprentice does the work while the expert watches without stepping in. The most concrete handover there is.
• Swarming: the team converges spontaneously on a blocker. A cousin of the mob, but triggered by need rather than planned.

These modes also have formidably effective variants — ping-pong pairing, strong-style pairing, frequent rotation of pairs — which we cover in the article dedicated to synchronous modes.

III. Asynchronous modes: capturing the explicit  

They require neither the same place nor the same moment, and they produce a trace that survives departures. That is their strength.

• Code review: the most underrated vehicle of knowledge transfer — provided you explain the why in it, not just validate the what.
• ADRs (Architecture Decision Records): one record per decision, with the context, the alternatives ruled out, and the consequences. It’s the missing link that code never provides.
• Docs-as-code: documentation versioned alongside the code, in the same repository — therefore reviewed, kept up to date, and far less prone to decay than an isolated wiki.
• Runbooks: the tested incident procedure that replaces panic with sure-footed steps.
• Blameless postmortems: every incident becomes team knowledge rather than an individual scar.

The details of these practices — and how to write an ADR that will still be useful in three years — are the subject of the article on asynchronous modes.

IV. Organizational setups: making knowledge circulate  

The two previous categories concern the way you work. This one concerns the way you organize so that knowledge doesn’t concentrate.

• Rotating roles and on-call duty: nothing teaches better than an incident you lived through yourself. It’s the most powerful lever for moving a bus factor from 1 to 3.
• Game days: you simulate the outage before it happens, as a team, under real conditions.
• Guilds and communities of practice: people from several teams who share a domain (security, data, front end).
• InnerSource: anyone can contribute to any internal repository, with maintainers reviewing. Silos fall by design.
• The onboarding buddy: a named point of contact for the first few weeks, rather than a “ask anyone you like” that never works.

These setups are developed in the article devoted to organizational setups.

V. The recap: which mode for which knowledge?  

This table settles most of the hesitation: identify the nature of the knowledge first, and the mode almost imposes itself.

VI. Checking that it works  

Adopting practices guarantees nothing: you still have to measure whether the knowledge actually circulated. The most honest test is also the simplest — the muted expert exercise: the expert stays in the room but keeps quiet while the team solves a real problem. The gaps appear within minutes, with no risk and no drama.

It’s the only true audit of your bus factor, and it deserves its own article: testing your bus factor.

VII. Where to start  

Adopting everything at once is the surest way to sustain nothing. If you were to keep only three things, take this trio — it covers both kinds of knowledge at a modest cost:

1. On-call rotation — for the tacit, through lived experience.
2. ADRs — for the explicit, and the why that code never states.
3. Regular pairing — for everything that travels through contact.

And once a quarter, the muted expert exercise to check that the whole thing really holds.

Conclusion  

There is no mode superior to the others, only modes suited to the nature of the knowledge. The tacit travels through contact, the explicit through writing — and a robust team combines the two rather than betting on one.

The real indicator isn’t the number of practices adopted, but a simple question: if your best person left tomorrow, what would remain? As long as the answer worries you, there is still knowledge left to circulate.

Useful links  

• Agile Topics — Woody Zuill
  A blog with many references on agile ways of working, and an introduction to mob programming by the person who popularized the practice: principles, format, and observed benefits.

• Llewellyn’s Strong-Style Pairing
  The “strong-style” pairing rule: an idea must go through the other person’s hands — highly effective for passing on tacit knowledge.

• Google SRE Book — Incident response and postmortems
  The blameless postmortem culture, to turn every incident into shared knowledge.

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