In which indispensability turns out to be a prison.
When the Star Player Leaves
The Day Jamie Disappeared
Jamie could fix almost anything, not because she was mythical or uniquely brilliant, but because she knew where the bodies were buried. She knew why Customer X was billed differently than everyone else, which vendor payments could slip a week without consequence, and which would trigger a chain of escalating emails that quickly turned procedural friction into a relationship problem. She could glance at a report and tell the difference between noise and signal, between something that looked wrong but wasn't and something that looked fine but hid a crack.
The company called it "tribal knowledge." In practice, it was Jamie knowledge.
She'd been there since the early days, when everything ran on duct tape and good intentions and no one had yet decided which workarounds were temporary and which were structural. Over time she absorbed every exception, every workaround, every "just this once" decision that quietly hardened into permanent process. None of it felt dramatic in the moment. It was simply the accumulation of context.
Then she went to Bali for three weeks.
The first few days passed without incident. By day three, a billing dispute surfaced that no one could untangle because the original reasoning behind the structure hadn't been written down. By day seven, the monthly reconciliation stalled, not because it was especially complex, but because no one else knew which sequence of small checks made it reliable. Old Slack threads were reopened and read like artifacts. Decisions made years earlier had to be reconstructed from fragments of conversations between people who no longer worked there.
Jamie had documented everything. That wasn't the problem.
Her notes were precise, but they were written from inside the system. They preserved the steps without preserving the reasoning. A line like "Run monthly billing sweep but check for Edge Case 3 first" is technically documentation. It isn't transfer. The document didn't explain what Edge Case 3 was, how to recognize it, or what tradeoff it represented. Jamie knew. Jamie was in Bali.
What disappeared wasn't information. It was legibility under pressure. The system had always been clear to one person. It became opaque the moment that person stepped away.
The Quiet Collapse
Organizations built around individuals rarely fail in a single, visible moment. They slow down instead, and the slowdown spreads quietly enough that no one can point to the day it began.
A task that once took fifteen minutes begins to take two hours because context has to be rediscovered each time. A workflow that once ran cleanly now requires nudges and reminders because the person who held the edge cases in their head isn't there to anticipate them. Decisions queue behind availability, and then behind accumulated fatigue, and eventually behind a general reluctance to ask again.
Nothing feels urgent at first. Revenue still posts. The dashboard still updates. The calendar remains full.
The same pattern shows up in customer relationships. A single account manager can hold together complicated dynamics across technical and business stakeholders because she understands the invisible sequence of habits that stabilize the relationship. She knows when a complaint is routine and when it's a signal. She knows when to push for expansion and when to let a quarter pass quietly.
When she leaves, there's no dramatic failure. There's no catastrophic mistake. Accounts that "should have" renewed begin to churn months later. The product is unchanged. The pricing is unchanged. What disappears is the set of small, repeated decisions that kept the relationship steady. Those decisions were never formalized. They lived in one person's judgment.
The dashboards register the outcome long after the cause has faded from memory.
Heroes Carry Hidden Weight
High performers attract dependency, not because anyone plans it that way, but because routing complexity toward competence is efficient in the short term.
They solve edge cases. They absorb ambiguity. They become the default escalation point because it's faster than building a shared frame. Over time, coordination debt settles around them. Documentation grows thinner because "they'll remember." Decisions get postponed because "they'll be back Monday." A process that could've been made legible remains implicit because it continues to function.
Indispensability rarely arrives as a declaration. It emerges gradually, through a sequence of reasonable choices made under time pressure.
From the outside it looks like trust. From the inside it feels like other people's uncertainty accumulating on your calendar. Real vacations require preparation plans, role changes become negotiations, and delegation exposes how little of the system actually exists outside your head.
When the person eventually leaves, the loss gets diagnosed as a talent gap. More often, it's a design gap that predated the departure. The system adapted around a human instead of formalizing what that human was compensating for.
Defaults and Drift
Not all fragility is concentrated in a single person. Sometimes it hides in code, in process, in assumptions no one remembers making.
In one case, a payment system that had processed transactions without issue for eighteen months began rejecting everything at 3 AM. Customers could browse. They could fill carts. Checkout failed. Revenue dropped to zero. The cause wasn't an architectural flaw but a single line of code that had been commented out during a deployment six weeks earlier. The change seemed harmless. The system continued to function.
Until it didn't.
Most breakdowns follow that pattern. They aren't sudden collapses so much as the final expression of accumulated drift. An assumption left unchallenged. An exception left unexplained. A temporary workaround that quietly became permanent.
Systems drift by default because no system is ever static. Roles blur as teams grow. Ownership softens when priorities shift. Edge cases accumulate faster than anyone revisits the original intent. The most dangerous period is often when everything appears stable, because "still works" is easy to mistake for "working well." Success masks erosion.
By the time the phone rings, the drift has already done its work.
What Endures
Durable systems survive individual departure because they were never designed around individual memory. They're legible to outsiders, repairable without heroics, and transparent enough that their state can be inspected without summoning the one person who understands them.
They tend to share a few characteristics:
| Marker | Description |
|---|---|
| Clear ownership | Responsibility is attached to names, not abstractions. The owner knows they own it, and the cadence of review is explicit. |
| Graceful degradation | When a dependency fails, the system preserves options. Orders queue instead of disappearing. A broken feature falls back to something predictable. Failure doesn't cascade. |
| Visible state | The system can be inspected without summoning the one person who understands it. Documentation, dashboards, and runbooks match lived reality. |
None of these traits require elegance. They require legibility.
The real test is absence. Remove the key person for a week and introduce a minor anomaly on an ordinary Tuesday. Observe whether the system adapts or stalls. If it stalls, it depended on a person more than it admitted.
Designing for absence means preserving reasoning, not just steps. A runbook that references "Edge Case 3" preserves sequence. A runbook that explains what Edge Case 3 is, how to recognize it, and what tradeoff it encodes preserves judgment. That difference determines whether the next person moves forward or begins reconstructing intent from fragments.
Defaults should handle the majority of cases without requiring interpretation from a specific individual. Judgment remains necessary, but it should be reserved for the minority of situations that genuinely require discretion. When every case requires discretion, the system's already collapsed into personality.
Decision context has to travel with decisions. Two paragraphs that capture what was considered, what was chosen, and what would trigger a reversal often prevent hours of excavation later. Ownership should be revisited before it becomes ambiguous. Assumptions should be re-tested as the team grows. Processes that fit ten people rarely fit fifty without modification.
Drift is constant. Roles blur. Exceptions accumulate. The gap between "how this works" and "why this works" widens quietly over time. Maintenance rarely produces visible wins. It prevents visible failures.
All of it depends on culture. If surfacing brittleness carries personal risk, brittleness will be concealed until it manifests as an outage. Blameless doesn't mean consequence-free; it means beginning with structure rather than personality. What allowed this class of failure to occur is a more durable question than who last touched the system.
Sarah left six months after stabilizing a chaotic function.
Her departure didn't trigger a crisis. Reports ran. Decisions remained legible. New hires understood the system without translation. Her name faded from conversation. The work didn't.
The system kept moving.
Footnotes
What looks like individual indispensability is often a series of reasonable tradeoffs made under time pressure. The organization needs someone to hold context. The person is good at holding it. Over time the structure adapts around that convenience.
The habits that help tend to be unglamorous: runbooks that define how to recognize and contain a failure; decision notes that preserve the reasoning around a choice; ownership reviews that confirm someone knows they own a thing; pre-mortems that articulate failure modes before a change ships; post-mortems that capture the missed signal rather than just the fix. None eliminate failure. They make recovery faster and repetition less likely.
| Published | 1 June 2025 (9 months ago) |
|---|---|
| Reading time | 8 min |
| Tags | systems thinking, trust, system decay |
| Views | – |
Reply
I’d welcome your thoughts on this essay. Send me a note →
