Designing Systems That Survive Us

Last weekend my father died. If he were reading this, he would probably complain that I’m making the situation more philosophical than necessary. He had a fairly practical view of mortality, and I tend to agree with him. We were both Darwinists. Mortality is not mystical, not poetic, and certainly not a cosmic message. It is a biological certainty. Organisms stop functioning. Processes end. The difficult part of death is rarely the person who dies, but the people and systems that remain. During the past week someone shared a phrase with me from Jewish tradition: “May his memory be a blessing.” I like the phrase because it is less sentimental than it first appears. It carries a practical instruction: remember, carry forward, and make what remains useful. That idea has a surprising parallel in how organizations think about resilience.

The overlooked single point of failure

Security professionals spend a great deal of time modeling adversaries. Business continuity planning focuses on disasters, outages, and infrastructure failures. Entire teams exist to ensure that systems continue operating when hardware fails or networks go down. Yet one of the most common single points of failure in organizations is neither technical nor malicious. It is human absence. A key architect becomes unavailable. A senior administrator leaves unexpectedly. A supplier disappears. Someone simply stops answering the phone. In each case, the disruption rarely comes from the absence itself but from the knowledge that disappears with the person. When that happens, something subtle but important is lost: undocumented reasoning, architectural intent, operational shortcuts that only one person understood, and decisions that were never written down because “everyone involved already knew.” In organizations, the second death often occurs when knowledge dies with the person who held it.

Fragile memory inside organizations

Many operational risks that appear technical are actually forms of fragile memory. An undocumented process is fragile memory. Credentials known to only one administrator are fragile memory. A system that only a single engineer fully understands is fragile memory. What sometimes looks like expertise or efficiency can, in reality, be a concentration of operational risk. Organizations usually discover this only when the person holding that knowledge is suddenly unavailable. In theory most teams understand this. In practice documentation gets postponed, processes remain informal, and knowledge stays concentrated simply because everyone involved is busy keeping things running. Until the day that someone is not there.

What resilience actually means

Resilience is often discussed in technical terms. Infrastructure teams design distributed systems so that the failure of a single server does not bring down an entire service. Data is replicated across locations, and critical systems are built with redundancy so that operations can continue when individual components fail. These principles are well understood in engineering. Organizations, however, do not always apply the same thinking to knowledge. When operational understanding lives entirely in one person’s head, the organization inherits the same fragility as a system built around a single server with no backup. The failure may not happen often, but when it does the consequences can be disproportionate. Resilient systems assume that components will eventually stop working. Organizations should probably make the same assumption about people. Not because people are unreliable, but because absence is inevitable.

Designing for absence

Designing resilient organizations therefore requires more than technical redundancy. It requires treating knowledge as part of the operational infrastructure. This means documenting decisions and processes even when everyone currently involved understands them. It means distributing operational knowledge across teams instead of concentrating it in a single expert. It means ensuring that credentials, systems, and procedures remain accessible even when one individual is unavailable. None of these practices are particularly glamorous. Most of them are administrative rather than technical. Yet they are often the difference between systems that continue functioning and systems that stall when key people disappear. Resilience, in this sense, is not about preventing loss. That is impossible in both biology and organizations. Resilience is about ensuring the system continues when loss inevitably occurs.

Memory as infrastructure

“May his memory be a blessing” is often understood as a reflection on remembrance. It can also be interpreted as a practical principle. Carry forward what mattered. Make knowledge usable. Ensure that what someone built does not disappear simply because they are no longer present to explain it. Organizations that treat institutional knowledge as infrastructure tend to weather disruption far better than those that rely on individuals alone. Their systems continue functioning because the understanding behind those systems has been shared, documented, and distributed.

A practical conclusion

My father would probably tell me to stop philosophizing and get back to work. He would not be entirely wrong. None of us are permanent. But the systems we build can outlast us if they are designed properly. Spend time with the people who matter. And design your systems for absence. It is not hypothetical.