Tracing the Invisible Dependency
Section X · CROSS-CUTTING PLAYBOOKS: ALEXANDER TO BEZOS · Alexander to Bezos
The Mechanism
For any asset you value, trace the dependency chain: what maintains it, what funds the maintenance, what protects the funding, what ensures the protection. The chain is typically four or five links long. If you cannot name every link, you do not understand the asset's vulnerability.
The Story
Canterbury's sewers were excellent infrastructure. They failed because maintenance schedules depended on administrators who depended on tax revenue that depended on military enforcement that departed. Four links. Any one could break. Most operators invest in the visible asset and neglect the invisible chain that sustains it. The symptom: nobody worries about the person whose departure would cause the most damage, because nobody has traced the chain far enough to see it.
Application Scenarios
Key person risk analysis, run on the person nobody would write a press release about.
Most organizations conduct key person risk analysis on their CEO, CTO, and top sales rep. The Canterbury Chain exercise targets a different population: the person whose departure would cause the most operational damage per dollar of compensation. Start with your most important capability. Trace backward: what maintains it? Who maintains the maintenance? What funds that person's role? What protects that funding? Write down what happens on Day 1, Day 7, Day 30, and Day 90 if the person at the weakest link departs. If Day 30 looks like Canterbury (cascading failures reaching capabilities that seemed unrelated to the departed employee) you have found a single point of failure dressed up as a junior employee. The specific output of this exercise should be a one-page document listing three to five people whose departure would cause damage disproportionate to their visibility, paired with a specific mitigation for each: cross-training, documentation, a backup hire, or a structural redesign that removes the single point of failure.
Infrastructure investment and the invisible maintenance layer.
Most organizations invest in the strongest links of the chain (the visible capability, the flagship product, the star employee) and neglect the weakest (the systems administrator who keeps the servers running, the office manager who onboards every new hire, the mid-level engineer who is the only person who understands the legacy codebase). The Canterbury Chain reveals that the weakest link determines the chain's survival, not the strongest. The specific audit: for each critical business capability, trace the dependency chain four links deep. Your product depends on your engineering team. Your engineering team depends on your DevOps infrastructure. Your DevOps infrastructure depends on a single contractor who set it up three years ago and whose contract renewal is handled by someone in procurement who does not know the contractor is critical. Four links. Any one can break. If you cannot name every link for your three most important capabilities, you do not understand your vulnerability, and you are investing in the castle while the sewer system crumbles.
Critical Warning
Most operators discover the fragile chain only when it breaks. The Canterbury Chain exercise discovers it before, which is the difference between repair and prevention, and prevention costs a fraction of what repair costs.