When Failure Hides in Plain Sight: Why Redundancy Only Works If You Trust It
- mikemason100
- Feb 16
- 6 min read
Some failures arrive slowly. We see them coming. This gives us time to think, adapt, and recover. Others arrive suddenly, at precisely the wrong moment, compressing decision-making, overwhelming cognition, and leaving little margin for recovery.
This accident I'm about to discuss belongs firmly in the second category. A routine flight. A subtle technical failure. A moment of uncertainty. Coming together as a chain of events that destroyed a multi-million-dollar aircraft.
It wasn't because of recklessness nor because of incompetence. It was because a safety system designed to provide protection in a way that humans could reliably interpret, failed to do so.
This sort of thing matters. Not just for aviation, but for any organisation that relies on redundancy, backups, and safeguards to manage risk. Which is pretty much any business in some shape or form.
What Happened (In Simple Terms)
Shortly after takeoff, the aircraft experienced a failure of its Attitude Direction Indicator (ADI), the primary instrument displaying pitch and roll information. Crucially, the failure occurred without a clear warning or flag to indicate that the instrument had become unreliable.
In theory, this is where redundancy protects us. The aircraft was fitted with a Standby Attitude Indicator (SAI), designed to provide independent backup attitude information. But in practice, the pilot was unable to confidently rely on the standby instrument, as it appeared not to be aligned correctly.
Now the pilot was faced with a brutal cognitive problem: Which instrument do you trust when the primary appears wrong and the backup doesn’t inspire confidence? With conflicting or ambiguous information, workload increases, uncertainty grows, and decision-making degrades rapidly.
Within moments, control of the aircraft was lost, resulting in an accident that unfolded far faster than any meaningful recovery could occur. This is where the investigation becomes interesting and, in some ways, disappointing.
The Limits of Hindsight
The report identifies technical failure, confusion, and degraded situational awareness. All accurate an all true. But like many accident investigations, it stops short of asking the most powerful learning questions:
hy did this situation become unrecoverable so quickly? How do we stop others from being placed in the same impossible position?
Instead, the analysis appears to largely treat the failure as an unfortunate but isolated chain of events, rather than exploring the deeper system vulnerabilities that allowed such a rapid collapse in resilience.
There are two areas in particular where the learning potential remains largely untapped.
Lesson 1: Unflagged Failures Are a Trap — Not a Surprise
One of the most striking features of this accident is that the ADI failed without an obvious tell-tale to inform the pilot that the instrument was unreliable. This is really dangerous.
Humans are pattern-driven. If an instrument has worked perfectly for hundreds or thousands of flights, we implicitly trust it. When it begins to provide false information, without clearly telling us, it creates a uniquely hazardous situation.
The key learning question I'd like to consider isn’t that the instrument failed. It’s:
Has this type of failure happened before and if so, how widely is it understood?
In many aircraft fleets, subtle instrument failures are known, documented, and explicitly trained. In the aircraft I used to fly, a similar ADI failure mode was well understood. Crews practised it regularly in the simulator. We were taught what it looked like, how it felt, and, most importantly, how to recognise it instantly. That training built our Situation Awareness and dramatically reduced confusion.
Yet in this case, there appears to be no meaningful discussion about:
Whether similar unflagged ADI failures had occurred before
Whether they were known within the fleet
Whether crews routinely trained for them
If failures are known but not trained, we are effectively relying on luck. And luck, while occasionally useful, is not a strategy.
Business parallel: Many organisations have known system vulnerabilities: data glitches, software quirks, operational workarounds, that are “understood” but never formally trained or documented.
When they surface under pressure, teams don’t fail because they’re incompetent. They fail because they’re surprised. If your organisation is depending on tribal knowledge to manage known failure modes, it’s already carrying hidden risk.
Lesson 2: Redundancy Only Works If You Trust It
Redundancy is often treated as a silver bullet. Two systems are better than one. Three are better than two. But redundancy only protects you if:
The backup is genuinely independent
The backup is reliable
The human trusts it
In this accident, the standby attitude indicator, theoretically the safety net, did not inspire confidence. The pilot suspected that it may not have been correctly aligned, leaving them uncertain which instrument was telling the truth. This raises some uncomfortable but vital questions:
Is it normal for the SAI to be misaligned?
Is correct alignment consistently checked before every flight?
How robust are those checks?
If this is the only remaining reference in an emergency, why is its reliability not absolutely assured?
If your final layer of defence is uncertain, then in reality, you don’t have redundancy. You have the illusion of safety.
Business parallel: Many organisations build contingency plans, backup systems, disaster recovery processes, and escalation pathways. But few regularly test whether people trust them. If a crisis occurs and teams hesitate to activate a backup system because they don’t fully understand it, don’t trust it, or aren’t confident it works, then redundancy becomes dead weight. Redundancy only creates resilience when:
It is reliable
It is understood
It is practiced
It is trusted
Anything else is organisational theatre.
When Things Go Wrong at the Worst Possible Moment
This accident highlights a brutal truth: The most dangerous failures are the ones that occur when workload, uncertainty, and time pressure are all peaking. Humans do not struggle when problems are neat, slow, and well-defined. We struggle when:
Information is ambiguous
Cues are subtle
Time is compressed
Consequences escalate rapidly
This is precisely when cognitive overload sets in. In such environments, blaming “decision-making” is intellectually lazy. Decision quality is a product of:
System design
Training quality
Interface clarity
Expectation management
Cultural assumptions
If any of these degrade, decision-making degrades with them.
Why This Matters Beyond Aviation
Most business failures don’t result in wreckage, headlines, or formal investigations. But they follow the same pattern:
A small technical failure
Ambiguous signals
Conflicting information
Time pressure
Cognitive overload
Rapid escalation
And just like aviation, organisations often respond with:
“Why didn’t they notice?”
“Why didn’t they escalate?”
“Why didn’t they follow the process?”
These questions feel logical. They are also usually the wrong ones.
The more useful questions are:
How obvious was the problem before it became critical?
How trustworthy were the systems meant to protect them?
How much ambiguity did the environment create?
How well had teams been prepared for abnormal situations?
The Real Learning Opportunity
This accident might have been directly caused simply by instrument failure. However there are multiple other systemic, latent factors that lay dormant until they manifested at the wrong time.
Possible known failure modes to remain untrained
Redundancy to be uncertain
Critical backups to lack absolute trust
Ambiguity to exist where clarity is essential
The lesson is not “be better at instrument flying.” The lesson is:
Design systems that fail in ways humans can easily detect, interpret, and manage.
That means:
Clear failure flags
Robust backup alignment checks
Realistic simulator training
Regular exposure to rare but high-risk scenarios
In business terms:
Transparent dashboards
Obvious failure alerts
Reliable fallback processes
Practised crisis scenarios
Business Takeaways
Hidden failure modes are dangerous If a system can fail silently, it eventually will, and it will do so when it hurts most.
Redundancy without trust is useless If people hesitate to use backup systems, they are not safety nets, they are false comfort.
Train the rare, not just the routine The events that break organisations are rarely the ones they practise.
Design for cognition, not compliance People don’t fail because they don’t care. They fail because systems overload human limits.
Ambiguity kills speed — and speed saves lives (and businesses) The clearer your systems, the faster your teams can respond when it matters.
Final Thought: Were We Unlucky — Or Poorly Prepared?
Accidents like this often get written off as bad luck. But luck is simply the absence of preparation revealing itself at the wrong moment. If we want fewer catastrophic outcomes, we must design systems that anticipate human limitations, not judge them after the fact.
In both aviation and business, the most expensive failures aren’t caused by recklessness.
They’re caused by reasonable people doing reasonable things in poorly designed systems.
-----------------------------------------------------------------------------------------------------------------------------------------------------
Mike Mason and Sam Gladman are the co-founders of On Target, a leadership and team development company that brings elite fighter pilot expertise into the corporate world. With decades of combined experience in high-performance aviation, they specialise in translating critical skills such as communication, decision-making, and teamwork into practical tools for business. Through immersive training and cutting-edge simulation, Mike and Sam help teams build trust, improve performance, and thrive under pressure—just like the best flight crews in the world.
If you'd like to learn more about how On Target can help your team, contact Mike and Sam at info@ontargetteaming.com.
Comments