Lessons from the Air Canada Express Crash at LaGuardia

When something goes wrong in a complex system, the first instinct is often to ask: Who made the mistake?

That may be understandable, but it is rarely enough. In safety-critical environments such as aviation, pharmaceuticals, healthcare, medical devices, food manufacturing, or advanced manufacturing, serious failures are usually not caused by one person, one action, or one technical fault. They emerge from a wider environment: procedures, equipment, communication, training, workload, layout, assumptions, time pressure, culture, and decision-making systems.

A useful root cause question is therefore not simply:

“What failed?”

A better question is:

“What environment allowed this failure to happen?”

The March 2026 Air Canada Express accident at LaGuardia Airport provides a powerful example. According to the National Transportation Safety Board, Jazz Aviation flight 646, operating as Air Canada flight 8646 from Montréal to LaGuardia, collided with an aircraft rescue and firefighting vehicle while landing on Runway 4. The aircraft was substantially damaged, both pilots were fatally injured, and 39 people were transported to hospital. The NTSB has clearly stated that the information available is preliminary and subject to change, and the investigation remains ongoing.

That warning matters. We should not jump to a simplistic conclusion. The purpose of looking at this type of incident is not to assign blame, but to understand how complex systems can fail.

Root Cause Is Not Always the First Visible Cause

In many investigations, the most visible event becomes the assumed root cause. A person pressed the wrong button. A vehicle entered the wrong area. A document was not followed. A specification was missed. A batch record was incomplete. A machine alarm was ignored.

But these are often trigger events, not root causes.

In the LaGuardia case, a superficial interpretation might focus only on the immediate runway conflict between an aircraft and an emergency vehicle. But a deeper root cause investigation would ask broader questions:

What was happening at the airport at that moment?
What other emergency or operational demands were active?
How were air traffic control, emergency response, runway operations, and flight crew communications coordinated?
Were all relevant vehicles visible to surveillance systems?
Were procedures clear under time pressure?
Were staff managing multiple roles or competing priorities?
Were there weak signals before the event?

This is the difference between event thinking and systems thinking.

Event thinking asks: “What happened at the point of failure?”
Systems thinking asks: “How did the wider environment shape the decisions, behaviours, and conditions that led to failure?”

The Environment Is Part of the Process

A process does not operate in isolation. It operates inside an environment. That environment includes physical conditions, organisational pressures, information flows, technology, human workload, and competing goals.

In aviation, this may include runway layout, visibility, radio communication, controller workload, emergency response routes, aircraft position, vehicle tracking, surveillance systems, and time-critical decision-making.

In a pharmaceutical or manufacturing setting, the same principle applies. A deviation may appear to be caused by operator error, but the real contributing environment may include poor line clearance design, confusing batch records, similar-looking materials, production pressure, inadequate training, weak supervision, poorly designed electronic systems, or a culture where people are reluctant to stop the process.

A person may be the last link in the chain, but the chain is usually much longer.

Complex Situations Create Coupled Failures

The more complex the environment, the more likely it is that small weaknesses interact.

A single weakness may not cause a failure. But several weaknesses occurring together can create a serious incident. This is often described as an alignment of holes in the Swiss cheese model of accident causation.

In the LaGuardia accident, the NTSB preliminary information confirms the basic facts of the collision: a CRJ-900 aircraft landing on Runway 4 collided with an ARFF vehicle, with fatal and serious consequences. At this stage, the final causal findings are not yet available. However, the case clearly illustrates why investigators must examine the interaction between flight operations, ground vehicle movement, emergency response, runway control, technology, communication, and decision-making.

That is the key learning for root cause analysis: the failure is often in the interaction between parts of the system, not in one isolated part.

A procedure may be adequate under normal conditions but fragile under pressure.
A communication system may work when traffic is low but become vulnerable when multiple events occur.
A training programme may cover standard scenarios but not unusual combinations of events.
A risk assessment may identify hazards individually but fail to explore how hazards interact.

Why “Operator Error” Is Usually a Weak Root Cause

In regulated industries, “operator error” is one of the most overused and least useful conclusions. It may describe what happened, but it rarely explains why it happened.

A stronger investigation asks:

Was the task designed to be performed reliably?
Was the required information available at the right time?
Were there competing priorities?
Was the person trained for the actual conditions, not just the ideal procedure?
Were alarms, signs, displays, or instructions clear?
Had similar near misses occurred before?
Was the system relying too heavily on human vigilance?

This matters because poor root cause analysis leads to poor corrective action. If the conclusion is “operator error”, the corrective action is often “retrain the operator”. But if the real issue is system design, retraining may do little to prevent recurrence.

Training is useful, but it is often the weakest corrective action when used alone.

A Practical Model: Understand the Environment Before Naming the Root Cause

A practical root cause investigation should move through five levels of environmental understanding.

1. Define the Immediate Event

Start with the facts. What happened? When did it happen? Who or what was involved? What was the consequence?

In the LaGuardia case, the immediate event was a landing aircraft colliding with an emergency response vehicle on the runway. The NTSB reported that the aircraft was substantially damaged, both pilots were fatally injured, and multiple passengers, crew members, and vehicle occupants required hospital treatment.

In a manufacturing example, the immediate event might be a failed sterility test, a wrong label applied, a critical alarm missed, or a product released with incomplete documentation.

2. Map the Work as It Actually Happened

Do not rely only on the written procedure. Map the real sequence of events.

What did people see?
What decisions did they make?
What information was available?
What was assumed?
What was happening in parallel?
What was normal, abnormal, or ambiguous?

This is where many investigations fail. They compare what happened against the SOP, identify a gap, and stop. But root cause analysis requires understanding the actual working environment, not just the documented one.

3. Identify the Conditions That Shaped Behaviour

People do not act in a vacuum. Their actions are shaped by the system around them.

Important environmental conditions include workload, time pressure, staffing levels, communication channels, equipment design, visibility of information, physical layout, competing priorities, noise, fatigue, interruptions, and organisational culture.

In an airport environment, the coordination between aircraft, vehicles, controllers, and emergency response teams is highly time-sensitive. In a production environment, the same type of complexity can exist between operators, quality assurance, engineering, maintenance, supply chain, and production planning.

Root cause analysis must therefore ask: What made the action seem reasonable at the time?

That question changes the tone of an investigation. It moves the focus from blame to learning.

4. Look for Failed Barriers

Every high-risk process should have barriers that prevent a hazard becoming a failure. These may include physical barriers, electronic controls, alarms, independent checks, procedural controls, training, segregation, authorisation steps, or real-time monitoring.

The investigation should ask:

What barriers were expected to prevent this?
Which barriers worked?
Which barriers failed?
Which barriers were missing?
Were any barriers bypassed, unclear, unavailable, or too dependent on human memory?

In aviation, barriers may include runway clearance procedures, radio communication, surveillance systems, vehicle tracking, controller coordination, and pilot situational awareness. In life sciences, barriers may include validated systems, line clearance, barcode checks, QA review, equipment interlocks, environmental monitoring, batch record controls, and deviation escalation.

A root cause is often found where a critical barrier was absent, weak, or not robust under real operating conditions.

5. Test the Corrective Action Against the Environment

The final test of root cause analysis is not whether the report sounds convincing. It is whether the corrective action would still work in the real environment.

Would it work under pressure?
Would it work during shift handover?
Would it work with new staff?
Would it work when production is behind schedule?
Would it work when two abnormal events happen at the same time?
Would it work at night, during maintenance, or during emergency response?

If the corrective action depends mainly on people being more careful, it is probably weak.

Better corrective actions change the system. They make the right action easier, the wrong action harder, and the risk more visible.

Applying This Thinking in Life Science and Manufacturing

The same thinking applies directly to regulated industry.

Imagine a deviation where the wrong component is added to a batch. A weak investigation might conclude:

“Operator failed to follow procedure.”

A stronger investigation would examine the environment:

Were two components stored beside each other?
Were labels visually similar?
Was the weighing room busy?
Was the electronic system difficult to navigate?
Was the operator interrupted?
Was the second-person check meaningful or routine?
Was there pressure to complete the batch before the end of shift?
Had similar near misses occurred before?
Were barcode controls available but not used?

The root cause might not be lack of training. It might be poor material segregation, weak visual management, poor system usability, ineffective checking, or production pressure.

That distinction matters. If the wrong root cause is selected, the organisation may close the deviation but leave the risk in place.

The Real Purpose of Root Cause Analysis

The purpose of root cause analysis is not to write a report. It is to improve the system.

That means moving beyond the question:

“Who did not follow the process?”

And asking instead:

“Why did the process allow this outcome?”

The LaGuardia accident is a reminder that complex failures rarely come from one isolated cause. They emerge from the interaction of people, technology, procedures, information, environment, and organisational conditions. The final findings of the investigation will determine the specific causal and contributing factors, but the broader lesson is already clear: serious failures require system-level thinking, not superficial blame.

In regulated environments, this is especially important. Whether we are investigating an aviation accident, a pharmaceutical deviation, a medical device complaint, a food safety incident, or a manufacturing failure, the principle is the same.

To find the real root cause, we must understand the environment in which the failure occurred.

Only then can we design corrective actions that are practical, robust, and capable of preventing recurrence.