Two Undesirable Aircraft States. Two Very Different Outcomes.
A good friend of mine was operating into Sydney, turning onto the ILS final, 17 miles out, 3,000 feet. Shortly after intercepting, the autopilot unexpectedly pitches the nose down as the aircraft captures a false lobe of the glideslope. Both pilots pick it up immediately — neither one waiting for the other to say something first. The flying pilot disconnects the autopilot, establishes a gentle climb back to 3,000 feet, and re-engages for an uneventful approach. Total time from surprise to sorted: a few seconds.
A crew in the simulator, on a recurrent scenario-based evaluation, has just taken off and is accelerating. Instead of the nose gently lowering for acceleration, it begins pitching up through 20-plus degrees, with speed still increasing. The crew start talking about a possible airspeed unreliable event, comparing ASIs and other instruments. After several seconds of discussion, they agree that's what it is, and the flying pilot calls for the memory items. While the flying pilot waits for the monitoring pilot to read them out before taking any action, the stick shaker fires. The aircraft stalls at 2,000 feet, nose at 25 degrees up, autopilot still engaged.
Same category of problem — an aircraft doing something it shouldn't, with the automation driving it there. One crew handled it in real life without a script. The other crew, fully briefed on what was coming because they'd been in the simulator for days and everyone already knew the scenario, let it develop into a stall.
I didn't pull these two events from a manual. The Sydney event happened to my friend, and the simulator event is something I see time and again in the box as a check and training instructor, running the same recurrent exercise cycle after cycle. Different crews, different nationalities, same result, often enough that it stopped surprising me a long time ago.
Why does it keep happening?
Resilience isnt built by rehearsing the expected
One of the hardest things to build in evidence-based training is genuine resilience — the ability to recognise an undesirable state, recover from it, and get back to normal operations. Within days of a recurrent cycle starting, the script is common knowledge across the pilot group. Everyone knows what's coming and roughly when.
Resilience doesn't come from knowing the script. It comes from a well-structured problem-solving and decision-making process, drilled often enough in the simulator that it reproduces itself automatically when something unscripted actually happens — like a false lobe capture on a real approach into Sydney.
Look at what my friend's crew did. The autopilot was doing something wrong. They disconnected it, set a pitch attitude that gave them a sensible flight path, and re-engaged when it made sense to. No analysis paralysis. No waiting for someone to read a checklist first.
Why didn't the simulator crew do the same thing? The first step when the automation is putting the aircraft somewhere you don't want it to be is to disconnect it and establish a known safe state — in this case, something like 10 to 15 degrees pitch and a handful of power straight after takeoff. Aviate, navigate, communicate. What I see far too often in the simulator, sitting behind crews running this exact exercise, is pilots analysing a situation they are already expecting, before taking any action at all — often waiting until the memory items are actually called out before doing anything with the flight controls.
The first step was never supposed to be working out whether this is an automation problem or an airspeed unreliable event. The first step is getting rid of the automation that clearly isn't doing what you asked it to, and putting the aircraft in a safe state. Only after that do you run your assessment and then call for and action the memory items. If the autopilot is pitching the nose up or down dramatically, revert to manual flight and set a pitch and rough power setting that keeps you safe for the next few seconds. If you don't know those basic pitch and power numbers for the phase of flight you're in, you were never going to be ready for a false lobe capture or an autopilot mode failure on climb-out, script or no script.
To be clear, this isn't me telling pilots to ignore the memory item pitch and power figures. It means get the aircraft out of the undesirable state first, then refine those figures once the startle effect has passed.
And in my experience, this is exactly why it happens more, not less, when crews know an event is coming. Because they know it's about to happen, they skip the thing they'd do instinctively in real life — stopping the autopilot from doing something wrong — and instead wait for the "official" response to start. You don't need a memory item to tell you to fly the aircraft.
Some of the responsibility sits with how these recurrent scripts get written by the training teams putting them together. A scenario that's too tightly scripted — where candidates are waiting for an exact event at an exact moment — doesn't train resilience. It trains the opposite. Good scenario design carries a genuine element of uncertainty in what happens and when, without becoming so complex it's unmanageable for the instructor running it. I write scenarios of my own for Line Oriented Evaluations on upgrade training, so I know firsthand it's a thankless task getting that balance right, but I've come to see it as fundamental to whether CBTA/EBT training actually does what it's meant to.
The four levels of knowledge, and the checklist nobody fully understood
The second issue I see time and again with this exercise is a lack of real understanding of the checklist itself. This comes back to the four levels of knowledge.
Can the crew remember the checklist? Usually yes — most crews can recite the memory items. But do they know the rest of it?
Do they understand the checklist? On the B777, for example, do they understand why the procedure calls for disconnecting the primary flight computers if the aircraft becomes difficult to trim? If they don't understand that step, or don't even know it exists, will they ever reach it if they're fighting for control and haven't had the spare capacity to open the checklist? A crew who genuinely understands the system may need to disconnect the PFCs while still struggling with control, well before the checklist formally gets them there.
Can they apply the checklist, by reference or from memory, while actually flying the aircraft — which is the critical part?
And can they correlate it when the situation doesn't fit the checklist cleanly? Airspeed unreliable with a dual engine failure in a volcanic ash encounter is a real example. There's no value in trying to set 4 degrees and 70% N1 as a memory item when you have no engines. That scenario requires correlating into an airspeed-unreliable descent profile instead — zero pitch and idle — and that figure isn't in the memory items at all. That's level four knowledge: the ability to adapt a known procedure to a situation the procedure wasn't written for.
Team resilience beats the captain who wants to do it all
There's another difference between these two events that I think matters as much as anything above, and it's about the team, not the individual.
My friend's crew worked the Sydney event together. Both pilots caught the automation misbehaving, and the flying pilot acted while the other pilot supported and monitored, ready to back him up if needed. Neither one sat back waiting to be told what to do, and neither one tried to run the whole event solo. That's team resilience — a crew that functions as a unit under surprise, each pilot doing their job and trusting the other to do theirs, which is what let the recovery happen in seconds rather than minutes.
Compare that with what I see far too often in the simulator: a captain trying to fly the aircraft, direct the checklist, and manage the whole situation at once, as if handing anything to the first officer is a sign of weakness rather than good airmanship. Handing control to the first officer at the right moment, or simply letting them run the checklist while the captain flies and keeps the big picture, almost always produces a better outcome than one person trying to do everything. A crew that trusts and uses each other is more resilient than any single pilot, however experienced, trying to be the hero. Add to that crews getting so absorbed in the complexity of the checklist that they lose sight of the basics — just flying the aircraft — and you get a checklist run without real comprehension, by a crew that never divided the load in the first place.
Bringing it back to Sydney
That's really the whole comparison in one line. My friend's crew hadn't rehearsed a false lobe capture. They didn't need to. They flew the aircraft first, assessed second, worked as a team throughout, and let the procedure catch up once the aircraft was safe. The simulator crew had rehearsed their scenario for days, knew almost exactly what was coming, and still let it become a stall — because they responded like a crew managing a training event, not a crew managing an aircraft, or each other.
I've watched this exact pattern play out often enough across enough different crews that I no longer think of it as a one-off performance issue. It's a training issue, and it's the reason I built Elevate Flight Leadership's courses around resilience, both individual and team-based, the four levels of knowledge rather than stopping at recall, and a structured decision-making process that holds up whether the event is expected or not.