If your most critical engineer left tomorrow, how long would it take to recover? The answer tells you how resilient your organization actually is.<\/p>\n\n\n\n
I’ve seen this play out. A key person leaves and suddenly everyone realizes how much was only in their head. The scramble that follows is painful and expensive.<\/p>\n\n\n\n
One question I ask myself regularly: who’s my backup? Not one person who handles everything when I’m out. That’s overwhelming for them and fragile for the organization. Instead, I think about who can pick up different parts of what I do. The load gets distributed, and no single person becomes a bottleneck.<\/p>\n\n\n\n
“What happens if someone gets hit by a bus?” It’s a morbid way to frame it. In our office we joke about “what if they won the lottery?” as the friendlier version. Either way, the question matters. Every team has at least one person whose departure would cause serious disruption. They’re the only one who understands a critical system, or they hold all the client relationships, or they’re the glue that keeps everything running.<\/p>\n\n\n\n
The bus policy isn’t about expecting disaster. It’s about building an organization that can absorb unexpected losses without falling apart.<\/p>\n\n\n\n
Start by mapping out who knows what. For every critical system, process, or relationship, ask:<\/p>\n\n\n\n
If the answer to “who else could step in” is “nobody,” you’ve found a single point of failure. And if the answer is only one name, you’ve just moved the single point of failure one step away. Look for ways to spread knowledge across multiple people.<\/p>\n\n\n\n
Most organizations have documentation. Most of it is outdated, incomplete, or impossible to find when you need it.<\/p>\n\n\n\n
Effective documentation isn’t about writing everything down. It’s about capturing the information that would take the longest to reconstruct: why decisions were made (not just what was decided), the gotchas and edge cases that aren’t obvious, who to call when something breaks, and the stuff that’s “in someone’s head.”<\/p>\n\n\n\n
A good test: could someone new to the team use this documentation to solve a real problem? If not, the documentation needs work.<\/p>\n\n\n\n