The real single point of failure on the 737 MAX wasn't the sensor — it was the organizational structure that made raising concerns career-limiting.
Somewhere in a Boeing conference room, a clock was counting down. Not to a launch party. Not to a safety review. To a production deadline.
The business executive overseeing the MAX program had installed countdown clocks tied to major production milestones — one counting down to powering on the first airplane in the factory, another to the scheduled first test flight — placed in the same rooms where technological and business performance reviews took place. The message those clocks sent to every engineer in the building was not subtle.
That detail, drawn from the Harvard Law School corporate governance case study of the disaster, is worth sitting with. Because it is the kind of organizational signal that no post-mortem report can fully capture. It doesn't show up in code reviews or system audits. It shows up in what people choose not to say in meetings.
The Boeing 737 MAX disaster — 346 people dead across two crashes in October 2018 and March 2019 — is the most thoroughly documented case of a software system failing not because of what engineers didn't know, but because of what they knew and couldn't get anyone above them to act on. And yet the lesson most teams take from it is still, almost always, framed as a technical one: add redundancy, improve testing, don't trust a single sensor. Correct. Also completely beside the point.
The Engineers Saw It Coming
The crashes were precipitated by a failure of an Angle of Attack sensor and the activation of the Maneuvering Characteristics Augmentation System — a flight control system designed to compensate for changes in the size and placement of the engines on the MAX. The existence of that software was not disclosed to pilots until after the first crash.
That concealment is the lede. But the more damning fact is what happened years before either plane went down.
In December 2015, a Boeing engineer in the division that designed MCAS asked directly: "Are we vulnerable to single angle-of-attack sensor failures with the MCAS implementation?" That question sat in an internal email. It didn't result in a design change. The plane had two AOA sensors mounted on its nose. Boeing had designed an automated safety system that entrusted its decision-making to just one of them — a type known to fail — while Airbus typically relied on three.
A former Boeing engineer who worked on the MAX told the Seattle Times: "A single point of failure is an absolute no-no. That is just a huge system engineering oversight. To just have missed it, I can't imagine how."
Here's the thing: they didn't miss it. Internal Boeing memos and emails show engineers asking specifically about the system being triggered by a single sensor, about the consequences of a faulty sensor, and about whether pilots would react in time if MCAS activated erroneously. The questions were documented. The answers were not acted on. That is not an engineering failure. That is a management failure wearing an engineering costume.
The Incentive Was Explicit
To understand why those questions went nowhere, you have to understand what Boeing had decided the MAX was and was not allowed to be.
The goal of adding MCAS was to preserve the feel of previous 737s so pilots wouldn't need costly simulator training. That single commercial constraint — avoiding the training cost that would have accompanied a genuine new-type aircraft certification — shaped every downstream technical decision. At a meeting documented in a June 2013 email, Boeing officials agreed to diminish focus on MCAS as anything novel "in order to avoid increased costs, and greater certification and training impact."
That meeting was six years before the second crash. The decision to bury MCAS wasn't an oversight. It was a strategy.
Boeing had at one point planned to inform pilots about MCAS in their flight manuals, then reversed course and removed virtually every reference to it from pilot operating and training materials. As if it never existed. As a result, 80% of the 737 MAX planes shipped without a functioning warning system that would have notified pilots of faulty sensor data.
Full disclosure of MCAS would have invited regulatory scrutiny that might require new pilot type-rating — which would have made the MAX substantially less attractive to airlines that had already ordered it expecting a simple transition from the older 737. Competitive pressure, urgent delivery timelines, and a permissive regulatory relationship all pointed in the same direction: make the problem smaller, not solve it.
When the Culture Determines What's Audible
Despite Boeing being the acquiring company in the 1997 McDonnell Douglas merger, the deal brought significant organizational and cultural change. McDonnell Douglas had emphasized financial performance; Boeing had prioritized engineering quality. With former McDonnell Douglas executives assuming key leadership roles, Boeing's internal focus shifted: engineering quality continued to be valued, but it was now run through a stricter filter of financial discipline.
That shift is visible everywhere in the MAX program's paper trail. Some Boeing pilots, engineers, and other employees did raise safety concerns about the 737 MAX, but those concerns were either inadequately addressed or dismissed by Boeing and never reached the FAA. After the Lion Air crash — 189 people dead — internal discussions at Boeing and FAA reviews revealed concerns about MCAS, but Boeing did not issue a software fix or recommend grounding the aircraft. Instead, the company issued guidance suggesting pilots could manage the issue by following standard runaway trim procedures. Which is one way to handle a system flaw: tell the people operating the system to work around it and hope for the best.
After the first crash, the information needed to prevent another was already available. The failure mode was known. The design vulnerability had been exposed. Five months later, Ethiopian Airlines Flight 302 crashed in almost identical circumstances, killing all 157 people on board.
A former Boeing supervisor on the 737 MAX final assembly line had raised serious safety issues with senior management in June 2018, four months before the Lion Air crash. He specifically cited "schedule pressure" and wrote: "Frankly right now all my internal warning bells are going off. And for the first time in my life, I'm sorry to say that I'm hesitant about putting my family on a Boeing airplane." He recommended shutting down the production line. He was not listened to.
The counterargument worth taking seriously is that Boeing is an extreme case — a safety-critical aerospace program under immense competitive pressure, with specific regulatory dynamics that don't translate cleanly to a software team shipping a SaaS product. Fair enough. Most engineering managers will never face stakes even remotely comparable. But the organizational mechanics — the suppression of signals, the redefinition of known risks as manageable ones, the incentive structures that determine what gets escalated and what gets quietly filed — are not unique to aviation. They show up in nearly every major software incident where the postmortem eventually uncovers an email chain proving someone raised the concern months earlier.
Information from 57 whistleblowers who came forward during the Senate investigation revealed common themes: insufficient training, improper certification, and management undermining of frontline inspectors — trends often accompanied by retaliation against those who reported safety violations. Fifty-seven people. That's not a few dissenters. That's a system that had fully learned to eat its own warning signals.
The Real Lesson, Which Is Not About Sensors
At least some people at Boeing knew MCAS was dangerous because one sensor constituted a single point of potentially catastrophic failure. The technology did not design itself or fail by itself — and that is why the 737 MAX debacle was primarily a failure of management.
That framing is correct. But it still locates the failure in specific management decisions rather than in the organizational conditions that made those decisions rational from a career-preservation standpoint. The engineers who asked the right questions early were not overruled in some dramatic boardroom confrontation. Their questions just… didn't travel. Engineers flagged concerns about MCAS, and those warnings were diluted or ignored by leadership — not through any single act of suppression, but through an organization that had quietly stopped making bad news easy to deliver.
That's how most catastrophic failures actually work. Not through villainy — though Boeing's internal documents contain their share of that — but through an organizational design that makes bad information expensive to surface and comfortable to ignore. The countdown clocks in the conference rooms were not just about production. They were a statement about which problems were worth solving under which timeframe. Engineers read that message accurately.
The actionable thing — the thing you can bring to your next sprint planning or your next architecture review — is not "add a second sensor." It is this: ask yourself what a junior engineer on your team would have to lose by telling you that the system you're about to ship has a flaw you haven't fully characterized. If the answer is anything more than a few minutes of discomfort, your organization has already built the same countdown clock. It's just hanging somewhere you haven't noticed yet.
The 737 MAX disasters represent a systemic failure in software-based system design, verification, and certification — not a coding error per se, but a breakdown in safety culture, requirements engineering, and independent verification of software behavior under fault conditions. Every one of those breakdowns has a human decision behind it. And behind each of those decisions was an incentive structure that made it easier to classify a problem as acceptable than to stop the clock.
Boeing eventually fixed MCAS. The redesigned system now ingests data from both AOA sensors and only activates if both agree on a high angle-of-attack reading. A single sensor failure can no longer trigger it. The technical fix took months. The organizational conditions that made the original design acceptable took decades to build. There is no patch for that.
Sources
- Boeing 737 MAX
- The Boeing 737 MAX: Lessons for Engineering Ethics - PMC
- chairs defazio larsen send letter to colleagues about the committees boeing 737 max investigation&download=1
- Lack of redundancies on Boeing 737 MAX system baffles some involved in developing the jet
- U.S. House probe of 737 MAX finds ‘disturbing pattern’ of Boeing failures and ‘grossly insufficient’ FAA oversight
- Four Lessons from the Boeing 737 MAX 8 Crashes
- October 30, 2019
- Boeing's 737 MAX: A Failure of Management, Not Just ...
Top comments (0)