The "Bus Factor"
Imagine your team's most critical service — the one that processes payments, or authenticates every user. Now imagine the one engineer who truly understands its internals wins the lottery tomorrow and never comes back. Can your team keep that service running? Can they debug a production incident at 2 AM?
If the answer is "probably not," you have a bus factor of one — a single point of failure in human form. The term comes from the morbid question: "How many people on this team could get hit by a bus before the team can no longer function?" A bus factor of one means the team is one departure away from crisis.
This is not a hypothetical risk. Engineers leave for new jobs, take parental leave, get sick, or get promoted into roles where they're no longer hands-on. Knowledge hoarding — even unintentional — is a systemic risk.
Spreading the Knowledge
You must actively work to get knowledge out of individuals' heads and into the collective team consciousness. Three powerful techniques:
1. Pair Programming
Pairing is not just for two juniors trying to figure out a bug. It is the fastest form of real-time knowledge transfer.
- Senior/Junior Pairing: The senior teaches habits, debugging techniques, and system knowledge implicitly, through doing. The junior asks "why," forcing the senior to articulate knowledge they've never had to explain before. This benefits both parties.
- Senior/Senior Pairing: Rapidly spreads deep domain knowledge across siloed experts. If one senior owns the auth service and another owns the billing service, pairing them on a cross-cutting feature transfers architectural context that would take months of documentation to replicate.
2. Tech Talks (Lunch & Learns)
A scalable way to share specific knowledge. An engineer prepares a 30–60 minute presentation on a topic they know well — a specific service's architecture, a new library, a post-mortem analysis, or a design decision and its trade-offs. Benefits:
- Documents knowledge in a reusable format (record the session)
- Gives the presenter public speaking practice
- Creates a culture where sharing knowledge is valued and visible
3. Runbooks and Architecture Decision Records (ADRs)
Documentation that lives in the repository alongside the code. A runbook describes how to operate a system — how to restart it, how to diagnose common failures, what the on-call escalation path is. An ADR (Architecture Decision Record) captures why a technical decision was made, not just what was decided. Both are forms of asynchronous knowledge transfer that work even when the original author is unavailable.
# ADR-042: Use PostgreSQL instead of DynamoDB for the Orders service
## Status: Accepted
## Context
The Orders service requires complex multi-table joins for reporting queries.
DynamoDB's single-table design would require significant application-level
join logic and multiple round trips.
## Decision
Use PostgreSQL. The team has existing expertise, and the query patterns
favor relational structure.
## Consequences
- Positive: Simpler query logic, familiar tooling
- Negative: Requires managing a stateful service; scaling beyond ~10k RPS
will require read replicas or sharding
This ADR means that two years from now, when a new engineer asks "why are we using Postgres instead of DynamoDB?", the answer is documented and the reasoning is preserved — even if everyone who made the original decision has moved on.