The Human Load-Bearing Wall: Auditing Custom Software for Single-Person Dependence

Most software risk discussions begin with vendors, budgets, and contracts. Those are legitimate concerns, but they can obscure a more immediate exposure: the custom system that runs on the accumulated knowledge of one or two people. When that person resigns, takes leave, or simply moves to another team, the organization discovers that the software was never fully owned at the organizational level. It was owned personally.

The bus factor is a compact way to describe that exposure. In engineering terms, it is the number of people who would need to be unavailable before a system can no longer be operated, maintained, or recovered in a reasonable way. A bus factor of one is not a moral failing. It is a design and management condition that can be measured, prioritized, and reduced.

Begin With Operating Scenarios, Not an Org Chart

A bus-factor audit should not start by listing employees and asking who knows the most. It should start with the work the system must perform. Identify the critical operating scenarios that matter to the business: deploying a production release, restoring from backup, rotating credentials, onboarding a major customer, running month-end batch processes, diagnosing a failed integration, and responding to a security incident. For each scenario, ask a simple question: who can complete this without assistance, using only available documentation and access?

The answers usually fall into three categories. Some scenarios have several capable responders. Some have one primary owner and a nominal backup who has never actually performed the task. Others have no clear owner at all. That third category is often invisible until an incident occurs.

The audit should record evidence, not impressions. A person who says they could probably restore the database is not the same as a person who has restored it in a test environment within the last year. The output is a single-point knowledge register: scenario, current coverage, documented procedure, last tested date, and business impact if the scenario cannot be performed.

Trace the Decision History

Custom software contains two kinds of knowledge. The first is operational: how to build, deploy, monitor, and recover the system. The second is architectural: why the system is shaped the way it is. The second kind is easier to lose and harder to reconstruct.

A decision history audit asks where the rationale for significant choices lives. Why was a particular database selected? Why does a nightly job run in a specific sequence? Why is one integration handled synchronously and another through a queue? Why was a vendor-specific configuration chosen over a standard alternative? If the answer exists only in one person's memory, the organization has a decision-history gap.

The evidence may take several forms: architecture decision records, design documents, ticket discussions, commit messages, incident reviews, or diagrams with annotations. The goal is not to produce a perfect archive. It is to identify decisions that would be expensive, risky, or impossible to reverse without the original context. Those decisions deserve a written record and a second person who understands the trade-offs.

Test Documentation Against Reality

Documentation is often treated as a binary: it exists or it does not. A bus-factor audit should treat it as a question of usability. A runbook that has not been followed by anyone other than its author is a hypothesis. A diagram that omits the identity provider and the message broker is a partial truth. A wiki page that references a retired server is a liability.

The most useful test is a controlled rehearsal. Ask an engineer who is not the usual owner to follow the documentation for a critical scenario in a non-production environment. Record where they hesitate, what they must ask, and which steps assume tacit knowledge. Those friction points are the real documentation gaps. They are also inexpensive to fix compared with the cost of discovering them during an outage.

This rehearsal should cover access as well as instructions. A procedure is not usable if the backup responder cannot obtain credentials, reach the console, or approve a change without the primary owner. Administrative access is part of the operating knowledge, and it should be reviewed with the same rigor as the code.

Quantify Without Pretending Precision

Leaders need a way to compare exposures, but a bus-factor audit should resist false precision. A simple scoring model is usually sufficient: business criticality, current coverage, and estimated recovery time if the primary owner is unavailable. Each scenario can be rated high, medium, or low. The resulting matrix will not predict the future, but it will show where resilience is concentrated and where it is thin.

The most important number is not an overall score. It is the count of critical scenarios with fewer than two capable, tested responders. That number is concrete, trackable, and understandable outside engineering. It can be reported alongside other operational risks without implying that a single departure will definitely cause an outage. The point is to reduce the chance that it becomes one.

Remediate Without Doubling Headcount

A bus-factor audit often raises an understandable fear: the answer will be to hire more engineers. In many cases, that is not the first or best remedy. The more effective approach is to redesign how knowledge is held and transferred within the existing team.

Start with the highest-impact scenarios. Pair the primary owner with a second engineer for a structured handover, not a single meeting. Have the second engineer perform the task while the primary owner observes and corrects. Convert the corrections into documentation. Repeat until the second person can complete the scenario without prompting.

Create a decision journal for architecture choices that are costly to reverse. It does not need to be elaborate. A short record of context, options considered, decision, and consequences is enough to preserve the reasoning that code alone cannot convey. Review those records during onboarding and during major changes.

Rotate operational responsibilities where practical. An on-call rotation with only one real participant is not a rotation. Even a modest schedule that requires a backup engineer to handle selected incidents builds familiarity and exposes gaps in access and documentation. Automate repetitive operational tasks where that reduces dependence on individual memory, but do not automate a process that no one understands; document it first.

Finally, treat vendor dependencies as part of the same audit. A third-party platform can be reliable and still leave the organization dependent on one person who knows how it is configured and integrated. The bus-factor question applies across internal and external boundaries.

Make Resilience a Recurring Control

A bus-factor audit is not a one-time exercise. It should be repeated after significant departures, major architecture changes, and at a regular interval such as annually. The findings belong in the operational risk register, with owners and target dates. Progress can be tracked through a small set of measures: the number of critical scenarios with two tested responders, the percentage of runbooks rehearsed in the last twelve months, and the number of high-impact decisions with a written record.

Custom software engineered with precision must include operational continuity, not only functional correctness. The human load-bearing wall is easy to overlook because it does not appear in a budget line or an architecture diagram. A disciplined audit makes it visible, and visibility is the first step toward a system that can survive a single departure without becoming a single point of failure.