Can’t speak for you, but for me, life is starting to return to its pre-pandemic normal. Finally. Now we’re to the point of getting out and about, and, in the last few weeks, re-uniting with great friends who go back to the 70’s and even the 60’s. That’s a lot of years, and a lot of stories.
Oh, the stories. Which is the fun of it.
In my case, this happened on trips to New York and Florida, which involved walking through airports, boarding airplanes, renting cars, dialing up Uber, and the adventure of hailing cabs in mid-town Manhattan. Just like in the good old days, except for the part about wearing a mask, and breaking out ID and a vax card to get into restaurants in the City.
OK, so this Covid thing is still not yet entirely in the rear-view mirror. But hopefully we’re close.
So, one week, I’m in a rental car in South Florida, driving through the Everglades on Alligator Alley. The next week, I’m a passenger in an Airbus, on final approach to LaGuardia peering down at the Manhattan skyline. You’re probably thinking, “What do reptiles have in common with skyscrapers?”
If you happen to be a student of aviation history – crashes in particular – you might have an inkling. Consider two events, separated by 1,287 miles – and four decades.
Late in the afternoon of January 15, 2009, during climb out from LaGuardia Airport, an Airbus 320 lost power to both engines after striking a flock of geese. Two minutes later, the pilot and co-pilot successfully managed a dead stick landing, right in the middle of the Hudson River. Everyone – the crew of five and 150 passengers – survived the ditching and were rescued. You’ve probably heard the story and might have even seen the movie.
But there was a second story that you haven’t heard. Took place late in the evening of December 29, 1972. On final approach into Miami Airport, a Lockheed 1011 Tristar crashed into the Everglades. Five crew members and 96 passengers did not survive.
You’re wondering, “What’s the point served by bringing these events up, here and now? What do two airline crashes have to do with what I do for a living?”
Two fair questions, both with one simple answer. In both cases, up in the cockpit, the crew was doing something that you and your followers do on a regular basis: troubleshooting problems. Yes, their’s involved equipment traveling at more than 200 miles per hour, at 2,000 feet of elevation, but there are days when that’s how troubleshooting can feel to you.
One case a smashing success, the other a terrible failure; in both cases, important lessons to be learned.
Two Forms of Troubleshooting
Troubleshooting is one of those industrial terms of art everyone uses, because they assume everyone else knows exactly what it means. I am not a big fan of assumptions, so let’s spell this thing out. So, what is troubleshooting?
Let’s start with what it is not. Everybody knows when there’s a flat tire on the car, you change the tire. So, that’s not it. It’s when the car won’t start that troubleshooting does. Troubleshooting involves figuring out the cause of a problem, in real time. It’s not a root cause investigation, done with the luxury of time.
Still, there can be situations where the cause of the problem is known and understood, but how to solve the problem isn’t. Apollo 13 was the best example of this type of troubleshooting: three astronauts headed to the Moon, trapped in a space capsule that’s lost pressure – and oxygen – because of an explosion on board. How do you solve that problem, in real time?
As you well know, a team of brilliant space scientists did, and did so using what was on board, before the oxygen supply was depleted. Amazing stuff.
Which is pretty much what Captain Chesley Sullenberger and First Officer Jeffrey Skiles did. There wasn’t enough time to circle a powerless airplane around and land back at LaGuardia, or to make it to the nearest airstrip in Teterboro, New Jersey. From takeoff to touch down on the Hudson took less than three minutes.
I once met one of the passengers in a class I was teaching. I couldn’t help but ask, “Were you scared?”
“There wasn’t time” she replied.
Up on the flight deck the pilots had to first recognize what happened, get out the flight manual to look up the procedure to restart the engines, and when that didn’t work, figure out Plan B.
In the middle of that, Captain Sullenberger flipped the switch to start the plane’s Auxiliary Power Unit. That wasn’t a step listed in the SOP, but it surely helped the totally disabled aircraft make it over the top of the George Washington Bridge.
An amazing feat of troubleshooting, type two.
By comparison, the crew of three on the L1011 on final to Miami was engaged in the classic form troubleshooting: We know we have a problem. What’s the cause?
The problem was with the landing gear: the green indicator light on the flight instruments did not illuminate when the landing gear was lowered. Is that a problem? Heck yes! Darn well better find out why before touching down.
So, the crew of three – back in those days, there was a navigator on the flight crew – started troubleshooting. Was the gear down, or not? On that aircraft, there was a way to climb down inside the cockpit and perform a visual inspection. That was done while on final approach, the aircraft descending, and the auto pilot disengaged.
The flight crew was so engrossed with the troubleshooting process nobody heard the low altitude alarm sounding. A brand-new aircraft crashed into the Everglades eighteen miles short of the runway.
With not a thing wrong with the landing gear: the bulb had simply burned out.
Lessons To Be Learned
Regular readers will know that, in my view, unless someone takes the time to understand what went wrong, there are no “lessons learned”. Moreover, unless what’s learned is put into practice, there is no benefit of learning. Managing safety performance is not an academic subject.
For openers, the Miracle on the Hudson serves as a basis from which to learn from success. Be honest: when was the last time you did a root cause analysis of a smashing success? More likely there was a celebration.
So, learn from experience, good and bad.
Next up: no matter how robust and sophisticated the technology might be, it can still fail. When that happens, it falls to humans to do the troubleshooting, one type or the other.
Yes, you know that. So, please consider the first derivative of this lesson: as technology improves and failure becomes more and more infrequent, people have less experience dealing with failure. It’s the Law of Untended Consequences: no good deed goes unpunished.
The 150 passengers on the Airbus should thank their lucky stars Captain Sullenberger was at the controls that afternoon. He was in his late 50’s. He’d been flying planes since he was sixteen. Apparently he’d even flown gliders. In his graduation class at the Air Force Academy, he was the best at flying. To successfully land a commercial aircraft with no power on a river, given less than two minutes to prepare, every bit of that experience was called for.
Consider how our brains operate when dealing with the challenge of troubleshooting a tough problem. On the one hand, we are capable of devising ingenious solutions – Apollo 13 – and engaging in out of the box thinking – turning on the APU. Things like that are a core competency of we humans.
The problem is, we are also perfectly capable of focusing on the problem to the exclusion of everything else that is going on. It’s known as Lock on/Lock out. Proven fatal to firefighters in the heat of the battle, recognizing the problem, the profession devised a scheme: appoint someone to stand back and take in the big picture.
Aka, maintain perspective!
Eye on the Prize!
It’s the matter of perspective that leads to the final lesson. No matter what the problem to understand or solve, there’s always the one thing that matters most.
Seeing to it that everyone goes home alive and well at the end of the day.
Everything else is just business.
Paul Balmert
February 2022
English 
Portuguese 
Spanish 
Russian 
French 
Italian