Insights / The single point of failure is usually a person
Redundancy is a design principle, not a spare part
A twin-engine aircraft is certified to take off, climb and land on one engine. Hydraulic and electrical systems are duplicated or triplicated. Two pilots sit in the cockpit, either of whom can fly the aircraft alone. None of this is because engineers expect failure on every flight. It is because the design rule is that no single failure may be sufficient to cause the loss. The rule is applied ruthlessly, and the search for the single point of failure is where most of the safety engineering effort goes.
Outside aviation the rule is rarely stated, and when it is, people think about servers and backups. The single point of failure that actually stops small operations is a person: the one who knows how the permits are filed, how the old machine sounds before it fails, how the roster gets built, which client needs the invoice formatted differently. The organization does not perceive this as a risk because the person is reliable. That is exactly the condition under which the risk is invisible.
Finding the single point of failure
The test is a question, asked honestly about each task the operation depends on: if this person were unreachable for three weeks starting tomorrow, what would stop? Not "who would be inconvenienced" but "what would not happen." Run it across the operation and a short list appears. It is usually shorter than expected, and the names on it are usually the people the organization is most grateful for, which is why nobody has asked.
The list tends to contain the same categories in every small operation:
- Regulatory knowledge: who files the permits, renewals and registrations, and knows which ones are due
- Tacit diagnosis: who can tell what is wrong with the equipment, the process or the client relationship by looking
- Access: who holds the passwords, the keys, the vendor relationships and the account logins
- Scheduling: who builds the roster or the job plan and knows the constraints nobody wrote down
- Judgment: who decides go or no-go, urgent or routine, accept or refuse, and on what basis
Three ways to add redundancy, from cheapest to most durable
| Approach | What it is | Cost | Weakness |
|---|---|---|---|
| Named backup | A second person who has actually done the task, not just been told about it | A few hours of shadowing per task | Two people can both leave; the backup's knowledge decays if unused |
| Written procedure | The steps and, more importantly, the decision criteria, written so a competent stranger could follow them | A day per critical task, plus upkeep | Procedures rot if nobody follows them; must be used to stay true |
| Encoded procedure | The rules built into the tool: the checklist app that knows the regulations, the roster that enforces the rest rule | Software, once | Only covers rules that can be stated; the judgment layer stays human |
These stack. Aviation uses all three: a second pilot, a manual, and automation that enforces limits. A small operation should start with the first, because it is immediate, and use the shadowing sessions to produce the second, because writing a procedure is easiest while watching someone do the task. The third comes when the procedure is stable enough to trust to software.
The uncomfortable part
Adding redundancy asks the expert to make themselves replaceable, and that is not a neutral request. The person who is the single point of failure often knows it, and their value to the organization has been tied to it. Sometimes the knowledge has been kept unwritten because unwritten knowledge is job security.
The airline answer is cultural and it is worth copying. A captain who could not be replaced by another captain would be a safety finding, not a hero. Being replaceable is the professional standard, and the expert's standing comes from how well they train the backup and how good the procedure they write is, not from being the only one who can do the job. Making that explicit, and rewarding it, is the leadership work that no procedure can do for you. It is also the only thing that lets the expert take a holiday without their phone.
Three places it shows up
Drone operations. The operation has one person who knows how the permits get filed and when the flight is legal. They leave, and the aircraft sit in their cases. The fix is a pre-flight process that encodes the regulations, so legality is checked by the system rather than remembered by a person. Running drone inspection as a system works through this case, and the operations control center article describes what the room looks like when no one person is the room.
Inspection. The senior inspector can tell a cosmetic crack from a structural one by eye. Nobody else can, so their judgment is the bottleneck and the quality varies on the days they are away. The fix is written criteria, like a severity and urgency scale with thresholds, that a junior inspector or a model can apply and the senior can review.
Scheduling. The manager builds the roster from memory. The rules are in their head. The fix is writing the rules down and sorting them into hard and soft, which airline rostering does as a matter of course, and then letting a tool such as an AI roster generator apply them.
The test that tells you it worked
Redundancy is real when the expert takes two weeks off and nothing on the list stops. Not "nothing broke," because a lucky fortnight proves nothing, but "every task on the list was done by someone else, following the procedure, and the expert did not get a call." Schedule that fortnight deliberately. Airlines do not wait for an engine to fail to find out whether the aircraft flies on one; they demonstrate it in certification. The demonstration is the only evidence that counts, and it is far cheaper than the alternative.