Boeing 737 MAX — when known anti-patterns coupled
Most incidents in the ledger expose one or two recurring failure modes. The MAX binds nearly all of the most transferable ones into a single, recent system: a commercial constraint became an architectural constraint; hidden automation acted on one bad sensor; the operator was made the fail-safe without being told what had been delegated; compliance fragments obscured the whole; and the first response looked harder at the operator than at the design. A card could name those failures. It could not show how they reinforced one another.
The MAX was not produced because modern engineers suddenly forgot how to build safe aircraft. It was produced because commercial constraints shaped the architecture, the architecture created new risk, and the safety case transferred that risk to operators who were neither informed nor equipped to carry it.
Its recency matters, but not because recent failures are intrinsically more important. It matters because this happened with modern sensors, software, simulation, regulation, and decades of accumulated safety knowledge. Technology had advanced. The organisational problem had not.
1 · The commercial constraint became an architectural constraint
When Airbus launched the more fuel-efficient A320neo, Boeing concluded it did not have time to answer with a clean-sheet aircraft. It chose another derivative of the low-slung 737. The larger engines had to sit farther forward and higher on the wing; in parts of the high-angle-of-attack flight envelope, the changed aerodynamics produced a stronger pitch-up tendency. MCAS was introduced to move the stabilizer nose-down so the MAX would retain the handling characteristics expected of the 737 family.[1]
That is not, by itself, a scandal. Commercial requirements always shape engineering. The consequential requirement was the bundle around it: answer Airbus quickly, preserve a common type, let airlines mix NG and MAX operations, and avoid expensive simulator transition training. Boeing marketed that continuity before the FAA had made its final training determination, and contracts created financial exposure if the promised training level was not achieved.[1]
The evidence does not show an executive ordering an engineer to make MCAS depend on one sensor. It shows something more familiar: commercial pressure narrowed the acceptable solution space. Inside that space, choices that protected schedule, commonality, and training assumptions repeatedly won. The commercial strategy was upstream of the design risk without being a complete explanation for every design decision.
2 · The deputized control point
MCAS was not merely a warning. It was deputized to act: under qualifying conditions in manual flight, it could command the horizontal stabilizer without a pilot asking it to. That gave an automated control path authority over a safety-critical actuator. Yet most line pilots were not told MCAS existed, it had no dedicated annunciation, and the flight manuals and transition training did not give crews a mental model of the new authority.[2][6]
The ambiguity was structural. Pilots remained responsible for the aircraft, but a system they could not directly observe could act against their inputs. If it failed, responsibility snapped back to the pilots: diagnose the symptoms, counter-trim, recognise a runaway stabilizer, use the cutout switches, and recover. Control had been delegated to the machine; risk had been delegated back to the human.
None of these delegations is inherently unsafe. Automation can reduce workload; operators can be valid recovery layers; regulators must draw on industry expertise. The unsafe combination is delegated authority without equivalent observability, independent challenge, or a clear owner of the end-to-end risk.
3 · Two sensors on the aircraft; one sensor in the decision
The MAX carried two angle-of-attack (AOAAngle of Attack — the angle between the wing and the oncoming airflow) sensors, but the original MCAS logic used the one associated with the active flight-control computer on that flight. It did not vote the two readings or reject an outlier before commanding trim. A single plausible-but-wrong input could therefore cross the automation boundary with full confidence.[2]
This dependency had the same shape as Aeroperú 603, Birgenair 301, and Qantas 72: bad sensor data entered automation, the machine acted as if the data were true, and the operators saw consequences rather than a clean diagnosis. On the accident flights, erroneous AOA did not present as one tidy “MCAS failed” alert. It could produce a continuous stick shaker, airspeed and altitude disagreements, alerts, and uncommanded trim at once. The crew had to infer that these apparently separate symptoms shared one poisoned source.
The sensor failure was therefore only the trigger. The design risk was the authority granted to an unvalidated input, the absence of a useful dependency view, and a cockpit that exposed the cascade without exposing the causal graph.
4 · The mitigation that became part of the risk
Boeing's safety case did not assume MCAS could never fail. It assumed a trained 737 pilot would recognise unintended stabilizer movement quickly, counter it with electric trim, and use the established runaway-stabilizer procedure and cutout switches. Assessments commonly credited a response in roughly four seconds. Yet Boeing also had simulator evidence that a response beyond ten seconds could become catastrophic; that result did not reach the FAA, customers, or pilots in a way that changed the operational design.[1][3]
The model pictured a recognisable failure followed by an orderly response. The real crews entered a high-workload, low-altitude environment with contradictory indications and no knowledge of MCAS. The original logic could activate repeatedly after pilot counter-trim, steadily returning the aircraft toward nose-down stabilizer. The NTSB found that actual crew responses were inconsistent with the assumptions used in certification and that the effects of multiple alerts had not been adequately considered.[3]
Lion Air 610 and Ethiopian 302 were not identical operational sequences, and the official participants later disagreed over how fully the Ethiopian report analysed crew performance. They did agree on the design's central role: erroneous AOA activated MCAS, and the resulting trim commands contributed to the loss of control.[4][5]
5 · How it passed: compliance fragments without a system view
The MAX did not simply sneak around a rule that plainly prohibited it. The international Joint Authorities Technical Review found that Boeing and the FAA followed the applicable framework when treating the MAX as a derivative rather than requiring a new type certificate. It also found that those rules left substantial room for interpretation—and that the certification process missed the integrated risk.[2]
MCAS evolved during development, gaining authority and operating in a wider part of the flight envelope, while key certification deliverables did not remain fully aligned. Its description was fragmented across documents; it was not evaluated as a complete, integrated function including the flight crew; FAA specialists had inadequate awareness of its architecture, inputs, and authority. A high proportion of findings had been delegated to Boeing's Organization Designation Authorization unit, where reviewers were also reported to face undue pressure.[2]
Each slice could look acceptable inside its own boundary: a derivative aircraft, an augmentation inside an existing trim system, a hazardous failure recoverable by trained pilots, a delegated finding completed through an authorised process. The aircraft-level interaction was the thing no single slice owned.
6 · After the first crash: reinforce the procedure, keep the system in service
Eight days after Lion Air 610, Boeing issued an operations bulletin describing uncommanded nose-down trim from erroneous AOA and directing crews to existing procedures. The FAA followed with an emergency directive. Neither named MCAS. Boeing defended the adequacy of the manual and emphasised the maintenance and crew actions in the accident sequence; the FAA continued to permit the fleet to fly while relying on pilot intervention and a future software change.[1][4]
That response addressed a symptom path without giving operators the missing system model. It resembled a familiar weak incident response: reinforce the emergency procedure and leave the automated control active. The House investigation later concluded that Boeing and the FAA were quick to focus on the Lion Air pilots and slow to acknowledge the danger created by MCAS's design authority.[1]
After Ethiopian 302 crashed less than five months later, regulators grounded the fleet. Boeing subsequently acknowledged erroneous MCAS activation as a common link and accepted responsibility for removing that risk, while still describing the update as making an already safe aircraft safer.[7] The wording matters: a mature post-mortem cannot redesign the system while preserving the claim that the old design needed no fundamental correction.
7 · The fix was a new safety model, not one software patch
The return-to-service design compared both AOA inputs and inhibited the affected flight-control functions when they disagreed; limited MCAS to one activation for a high-AOA event; constrained its total authority; ensured pilot electric trim opposed it; and added a functioning AOA-disagree indication. The FAA also required revised flight-manual procedures, simulator training, an AOA sensor-system test, an operational-readiness flight, and a separate stabilizer-trim wire-routing change.[8]
The important fix was layered: validate the input, bound the automation, preserve human authority, expose the dependency failure, train the operator, and verify each aircraft. Telling pilots to react faster was no longer the primary control.
8 · One aircraft, the ledger's repeated anti-patterns
| KNOWN PATTERN | HOW IT REAPPEARED IN THE MAX |
|---|---|
| Automation authority | MCAS could move a primary flight-control surface against the crew without a dedicated indication of what was acting. |
| One corrupt input | A single active AOA sensor could trigger a high-authority response without comparison to the other sensor. |
| Mixed signals | One bad dependency surfaced through stick shaker, unreliable air data, alerts, and trim rather than one causal diagnosis. |
| No fail-safe | The design relied on rapid, correct pilot intervention after the automated barrier had already failed. |
| “Compliant” is not safe | Component-level findings and derivative rules did not produce an integrated aircraft-and-crew safety assessment. |
| Risk transfer | Commercial and architectural risk moved downstream to pilots, who were made responsible for an undocumented failure mode. |
| Blame gradient | The first response foregrounded crew and maintenance performance before fully confronting the automation's authority. |
| Commercial pressure | Schedule, commonality, training cost, and competitive positioning constrained design and certification choices. |
9 · Why known anti-patterns stay invisible
Nothing here was conceptually new. Aviation already understood sensor failure, runaway trim, human startle, automation surprise, fail-safe design, independent oversight, and the danger of schedule pressure. The blind spot was holistic: the anti-patterns were managed as separate concerns even as the system coupled them.
Known anti-patterns remain dangerous not because organisations forget each one. They remain dangerous because each arrives under a different owner, in a different document, with a locally reasonable justification. The catastrophe exists in the joins.
The deepest MAX lesson for reliability and risk is therefore not “never automate” or even “never let commerce shape design.” It is this: whenever authority is delegated, map the dependency, expose the action, bound its power, rehearse its failure, and name who owns the whole path. If the operator is the last barrier, they must know they have been deputized too.
The commercial-pressure findings are attributed to the House investigation. The accident reports and participating agencies agree on MCAS's central contribution but differ on parts of the operational and crew-performance analysis; those differences are retained rather than flattened.