Knowledge Redundancy Through Pairing and Pair Switching
No single owner of any system — pair, rotate pairs, and your org becomes fault-tolerant.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 90%
Deliberately engineer multiple owners for every system by having people work in pairs and switch pairs on a regular cadence. This removes 'towers of knowledge' — the single owner chained to a system — which makes the org fault-tolerant to departures, frees people to join new teams, and doubles as learning and fulfillment. Helfand frames it as building safety nets before you need them.
Origin
Helfand cites Richard Sheridan, chief storyteller and co-founder of Menlo Innovations in Ann Arbor, Michigan, whom she interviewed for Dynamic Reteaming. Menlo has all team members — not just software engineers — work in pairs and switch pairs at a regular cadence, starting from the interview itself. Helfand contrasts it with her first startup (Expert City), which had single owners of systems and suffered when they left.
Core principles
- 01A single owner of a system is a single point of failure for both the system and the person.
- 02Redundancy must be built before the departure, the layoff, or the opportunity arrives.
- 03Pair switching is simultaneously a resilience mechanism and a fulfillment mechanism.
- 04Knowledge redundancy is what makes every other reteaming pattern cheap to execute.
How to run it
- 1
Identify your towers of knowledge
Find every system with exactly one person who understands it. These are your single owners — chained to that system, and the reason a departure becomes a setback.
- 2
Pair on the work — all roles, not just engineers
Have people work in pairs. At Menlo Innovations this extends to team members beyond software engineers, and the pairing starts at the interview, so there is parity between how you hire and how you work.
- 3
Switch pairs on a regular cadence
Rotate the pairs at a set rhythm so knowledge diffuses across the team rather than pooling. Combine with practices like test-driven development so the system stays safe as ownership spreads.
Pro tip This matters most on critical systems — Helfand notes AppFolio was processing large volumes of rent payments, where safety and security were non-negotiable.
Watch out Do not confuse pair switching with haphazardly moving people between teams every two weeks with no say — that's the switching anti-pattern.
- 4
Cash the redundancy when opportunity or loss arrives
With multiple owners in place, someone can fade off a system to join an isolated new-product team without a two-year tail of knowledge transfer — and if someone leaves the company, they don't leave with all the information in their head.
In the wild
At Expert City (her first startup) there were single owners of systems, and when those people left it became a challenge and a setback. Many of the same engineers went on to AppFolio, where — sharing a founder — they deliberately did things differently: pairing, switching pairs, and test-driven development, with outside help to establish the practices.
→ AppFolio built redundancy and safety into critical systems processing large volumes of rent payments, and people could move between teams without stranding knowledge.
Richard Sheridan's company was built from the ground up so that team members work in pairs and switch pairs at a regular cadence, with pairing present from the interview onward.
→ Knowledge redundancy is a structural property of the company rather than a practice someone has to champion.
Common mistakes
Waiting for a departure to discover the tower
Redundancy has to exist before the person leaves. Once they've resigned, the knowledge transfer is a rushed, lossy scramble — and the person may still be fielding questions about the system for years afterward.
Confusing forced rotation with pair switching
Moving people around with no agency creates resentment, not resilience. The switching has to be a cadence people participate in and benefit from.
Is it for you?
Best for
Engineering leaders in a company with critical systems and key-person risk, who want to be able to reteam cheaply and survive attrition.
Not ideal for
Deeply specialized work where genuinely no second person can hold the context, or very small teams where everyone already touches everything.
From the transcript
“have multiple owners of a system so not only one person is that Tower of knowledge that owns that one system”
“switching also helps build that knowledge redundancy in your company a little more fault tolerance”
“so if someone leaves they don't leave with that all the information in their head”
From the episode
The art and wisdom of changing teams
Heidi Helfand (author of Dynamic Reteaming)