Opinion: Here we go again, “pilot error”, really?

Emirates Boeing 777

It is with great interest that I read last week several reports regarding an Emirates Boeing 777-300ER flight from Dubai (DXB) to Washington Dulles (IAD) on December 20, 2021 that has been described as “almost crashing”. Naturally as an accident investigator I was drawn to these reports in an effort to understand the preliminary information that was being reported at this early stage. However, as many of you know, this information is notoriously unreliable and any further speculation regarding the cause of the incident is simply ridiculous. Yet, there it was in print, exhortations claiming “pilot error” and calling for their termination. There was even one report saying that all four pilots had already been terminated.

It appears that the crux of the incident is that the pilots of the incident flight failed to set the initial departure altitude of 4,000 ft. MSL in the MCP and instead it was left set at zero feet from the previous crew for their landing in Dubai earlier. On climb out when the autopilot was engaged, the aircraft started to rapidly descend. However, the crew was able to intervene prior to impact. After the incident, it is reported that Emirates sent the following memo to its pilot group

CREWS ARE REMINDED THAT THERE ARE NO FCOM NORMAL PROCEDURE REQUIREMENTS TO CHANGE THE MCP AFTER LANDING OR SHUTDOWN. THERE HAVE BEEN TIMES WHEN THE MCP “ALTITUDE WINDOW” HAS BEEN SET TO THE AIRPORT ELEVATION WHICH MAY CAUSE ISSUES ON THE SUBSEQUENT DEPARTURE. CREWS SHALL NOT SET AIRPORT ELEVATION ON THE MCP AFTER LANDING OR SHUT DOWN.

Well they were right, just as the memo says, setting the MCP to airport elevation can cause issues later for departing crews. That has been clearly demonstrated by this event. For an airline to send a reminding memo like this to its pilot group, this is not the only event of this type that has occurred. There would have been others. But yet, this trap is still occurring. This is another case of our industry slapping on the critical and pointless term “pilot error”. It tells us nothing of why something happened. It tells us nothing about the autoflight system design, the procedures the manufacture has crafted, in addition to those of the operator.

This very well might be another case of a poorly designed procedure for both landing and departing crews. We just do not know at this early phase. However, we have seen this many times in our industry and usually after killing enough people these procedure changes are finally implemented. Sad, but historically true. Why are these types of events still happening resulting in such a memo being sent to a highly trained and skilled pilot group? Apparently this is not the first time at this airline and I would bet that other operators have seen similar events as well. Why are we waiting for an accident to happen before these events are further investigated? Shouldn’t we be spending far more resources than we typically do investigating incidents that are so close to being an accident? Why not? They are freebies. We can get 99% of the information gleaned from an accident without suffering a hull loss and loss of life. Take advantage of that! Dig into it, uncover the layers of information, discover the second stories and make meaningful recommendations before there is a loss of life.

Firing the employees in the name of “pilot error” does absolutely nothing to enhance safety in complex socio-technical systems such as aviation. In fact, there is an overwhelming amount of evidence that it does the opposite. It drives safety reporting and event capturing underground. One example of how this would be harmful is in our event reporting systems like ASAP programs. Typically the reports received are around 65% sole-source reports. In other words, had the reporter not come forward and reported the event (confession if you like) your operation would have never known about it. Think about that, never would have known about the safety issue they are telling you about. Why would you want to suppress the flow of that valuable information?

Additionally, determining pilot error to be the “cause” of an event provides a dead-end for making any meaningful recommendations. How can you make any recommendations to prevent further events if “bad apples” were deemed the cause with a “pilot error” diagnosis? Once the bad apples are gone, you should be fine right? Hardly, the system with all of its interactions, imperfections, automation considerations, trade-offs and more remain completely unchanged. If you do not investigate the system as a whole, understanding the human-computer interface and all of the other facets of the system, your luck will eventually run out. Review numerous accidents that have occurred over the years and the signals that were present prior that were not recognized or even ignored because of our oblivious fascination with pointless terms such as “pilot error”.

In closing, I would like to remind everyone that our worldwide aviation system is as safe as it is because of the humans, not unsafe because of them. Computers will do whatever you tell them to do, regardless of the context, they are literal and brittle. They are simply not adaptable and are unreliably awful at communicating their intentions and when reaching the limits of their capabilities. A classy bumpy-transfer situation. We are the ones that can recognize when a situation is only slightly starting to change or mildly becoming suspicious of changes. Computers will push along blindfully and dutifully. We are also the ones that can recognize a rapidly changing situation and develop a new plan within seconds. We are the only system on the flight deck that has ever been able to be adaptive. And WE are the reason that aviation is the safest form of travel – we make it that way everyday all over the world.

By Dr. Shawn Pruchnicki

Dr. Shawn Pruchnicki Ph.D. ATP CFII is a former airline pilot. He is currently a Professor in the College of Engineering at the Ohio State University and is an internationally recognized expert in accident causation and automation design.