# The Titanic didn't sink for just one reason URL: https://rootly.com/blog/the-titanic-didnt-sink-for-just-one-reason Author: Steve Mynett Published: 2026-10-21 Updated: 2026-10-21 > Why Root Cause Analysis and the Five Whys stop short, told through the Titanic disaster, and what a contributing-factors approach to incidents reveals. I'm obsessed with learning things that cause me to see the world differently. The kind of things that, once you see them, you can't unsee. As a software engineer, I had been taught and believed to look for the root cause of a failure. Fixing that issue would make our systems safer and eliminate the possibility of the same failure happening again. Then I was introduced to the concept of a narrative-based approach to understanding how incidents happened. We *want* multiple diverse perspectives highlighting many distinct observations. That's where we can learn and understand how this incident happened. Systems are complex and messy; as are humans. When things go wrong, just as when they go right, there are countless contributing factors, perspectives and details to dig into. Reducing this to one root cause needlessly simplifies what we can understand. In this article, I'm going to explore the shift happening in software engineering from Root Cause Analysis to a Contributing Factors way of thinking, using the story of the Titanic as a backdrop. If you've been on this journey and already see incidents through contributing factors, come along to learn more about one of history's most notorious maritime disasters. However if Root Cause Analysis is still part of your lexicon, let's see if I can change how you see incidents. ## How did we become obsessed with root cause? Root Cause Analysis (RCA) has its roots in industrial manufacturing in the early 20th century, when manufacturers were developing ways to understand and prevent failures. In the 1920s, Walter Shewhart developed methods to distinguish between variation inherent in a manufacturing process and variation caused by identifiable disturbances. Building on this work, W. Edwards Deming emphasized understanding and improving the systems responsible for defects rather than simply correcting individual failures. Following the Second World War, Toyota developed its own approach to manufacturing under the leadership of Taiichi Ohno, drawing on ideas about quality, process improvement, and waste reduction. With its famous Kaizen mindset, Toyota looked at problems as opportunities to improve and understand manufacturing, rather than a simple correction of error. The Five Whys technique, traditionally attributed to Sakichi Toyoda (1867–1930), became a central part of Toyota's problem-solving approach and was documented by Taiichi Ohno in *Toyota Production System: Beyond Large-Scale Production*, first published in Japanese in 1978. > "The basis of Toyota's scientific approach is to ask why five times whenever we find a problem. By repeating 'why' five times, the nature of the problem as well as its solution becomes clear." > > — Taiichi Ohno In 1988, John Krafcik introduced the term "Lean Production" to describe the manufacturing practices pioneered by Toyota. The concept gained international attention following the publication of *The Machine That Changed the World* in 1990, bringing Toyota's approach to a much broader audience. Lean principles subsequently found their way into software engineering. In 2003, Mary and Tom Poppendieck published *Lean Software Development: An Agile Toolkit*, adapting manufacturing concepts such as waste reduction, continuous improvement and process efficiency to software development. In 2008, Eric Ries wrote "5 Why's" on his Startup Lessons Learned website crediting Taiichi Ohno and using it to examine a hypothetical website outage. Ries revisited the technique in a 2012 Harvard Business Review video of the same name advocating that software companies use manufacturing-style root cause investigations to address problems. Manufacturing-inspired approaches such as Root Cause Analysis and Five Whys became part of software engineering's approach to investigating failures. But complex systems don't necessarily fail in predictable ways, and reducing this complexity to a single root cause leaves so much of what we could learn and understand unexplored. ## The Titanic: Five Whys, one root cause The Titanic, famously dubbed the "unsinkable" ship, embarked on its first trip from Southampton towards New York City on April 10, 1912. Just a few days into the journey, late on April 14th, it struck an iceberg and sank in the early hours of April 15th. This massive disaster left more than 1,500 people dead out of the roughly 2,224 on board, becoming one of the most infamous maritime tragedies in peacetime history. What follows is a hypothetical Root Cause investigation using 5 Why's into the sinking of the Titanic: 1. **Why did the Titanic sink?** It collided with an iceberg, damaging the hull and allowing water to enter the ship. 2. **Why did the Titanic collide with an iceberg?** It was travelling at high speed in an area where ice had been reported, leaving little time to react when an iceberg was spotted. 3. **Why was the Titanic travelling so fast?** The captain maintained a high speed despite receiving warnings about ice in the area. 4. **Why did the captain maintain a high speed despite the warnings?** Prevailing maritime practices considered maintaining speed acceptable in clear weather, provided lookouts were watching for hazards. 5. **Why did maritime practices allow ships to maintain high speeds in potentially dangerous conditions?** Established operating procedures relied heavily on the judgment and experience of ship officers rather than requiring speed reductions in response to ice warnings. **This leads us to a root cause:** Inadequate operating procedures for responding to ice warnings. Given this understanding, what fixes can we adopt to ensure this doesn't happen again? - Establish mandatory speed reductions when entering areas with reported ice. - Update navigation procedures. - Train officers on the new requirements. - Introduce checks to verify compliance. This looks like a successful investigation. We've identified a problem, established a root cause, and proposed four corrective actions. We can now write up the report, assign owners for these items, and confidently tell everyone that we've made things safer. But what have we actually learned? We've learned something about why the Titanic collided with an iceberg. We've learned almost nothing about why the ship sank, why there weren't enough lifeboats, why so many lifeboats launched half-empty, or why more than 1,500 people died. Our investigation isn't necessarily wrong. It is however incomplete. Once we've identified the root cause and identified corrective actions, we've given ourselves a reason to stop looking. ## Why do we love a simple explanation? If Root Cause Analysis obscures complexity, why do we use it and why is it so popular? I think part of the answer is that finding a cause gives us something we desperately want when things go wrong: certainty. We can point to a problem, say we've fixed it, and feel confident that we're safer. > "To trace something unfamiliar back to something familiar is at once a relief, a comfort and a satisfaction, while it also produces a feeling of power. The unfamiliar involves danger, anxiety and care – the fundamental instinct is to get rid of these painful circumstances." > > — Friedrich Nietzsche, *Twilight of the Idols*, "The Four Great Errors" When I tell my CTO right after we resolve an incident that the database won't fail again because we've added a test for an untested condition, it makes me look competent as an engineering leader. My CTO can quickly then tell the board that we've fixed the problem. Everyone feels more confident that we're safer. And quite frankly, if I don't come back quickly with concrete problems, gaps, and quick solutions, I risk looking like I don't know what I'm doing. Organizations benefit from this too. RCA gives us a straightforward explanation that's easy to communicate, often within hours of an incident. We can turn it into a Correction of Error document, share it internally or externally, and move on. We've given everyone a reason to feel better about what happened. Whether we've actually learned enough to prevent the next incident is another question. ## What happens when we look beyond the root cause? Much of how I think about incident investigations today comes from the Howie Guide to Post-Incident Investigations, originally published by Dr. Laura Maguire, Nora Jones, and Vanessa Huerta Granda in collaboration with the Jeli team (later acquired by PagerDuty). It's one of the most influential things I've read about incident investigation, and I strongly recommend reading it. One of its central ideas is the difference between fixing problems and learning from incidents. We're often quick to identify something that went wrong, assign an action item, and consider the investigation complete. But there's so much more to learn about how an incident unfolded, especially from the people who experienced it and the decisions they made with the information available to them. The Howie Guide encourages investigators to be curious about those unexplored parts. There's a lot to learn from how people understood the situation as it developed, particularly when they were working with incomplete or conflicting information. Of course, the Howie Guide didn't exist in 1912, but the Titanic investigations offer an interesting comparison. Two formal inquiries began almost immediately after the sinking: U.S. Senate Titanic Inquiry led by Senator William Alden Smith, and the British Wreck Commissioner's Inquiry led by Lord Mersey. Together, they heard testimony from 179 witness appearances, reconstructed the sequence of events, and published detailed findings and recommendations. Their investigations went well beyond the collision with the iceberg, gathering perspectives from passengers, crew, and technical experts while examining the ship's construction, evacuation, and rescue. Their work revealed failures that had little to do with the initial collision but had enormous consequences for how many people survived. Three things about their approach jump out to me: 1. **The investigations looked far beyond the iceberg.** The British inquiry examined 26 questions covering the ship's construction, operation, crew, equipment, rescue, and safety regulations. 2. **They collected an extraordinary range of perspectives.** Passengers, crew members, technical experts, and others contributed different accounts and observations about what happened. 3. **Their recommendations addressed multiple layers of the system.** They went beyond preventing collisions to examine survivability, evacuation, rescue, regulations, and organizational practices. Rather than stopping at why the Titanic hit an iceberg, the investigations examined the much broader question of how the disaster happened and why so many people died. ## What really contributed to the Titanic disaster? There wasn't one thing that went wrong on the Titanic. There were multiple conditions that influenced the collision, the sinking, and the extraordinary loss of life. To understand what happened, we need to ask three different questions. ### How did the Titanic collide with an iceberg? - **Poor visibility:** A moonless night and unusually calm seas made icebergs more difficult to spot. - **Unusual ice conditions:** Significant iceberg presence along North Atlantic shipping routes increased the risk. - **Maintaining speed despite ice warnings:** The Titanic continued at approximately 22 knots despite warnings of ice ahead, reflecting prevailing maritime practices that permitted maintaining speed in clear weather. ### How did the Titanic sink? - **Hull damage:** The collision allowed water to enter multiple watertight compartments. - **Compartment design:** The watertight bulkheads did not extend high enough to prevent water from progressively flooding adjacent compartments. - **Limits of the ship's design:** The Titanic was designed to survive certain combinations of flooded compartments, but the damage exceeded this design. ### How did more than 1,500 people die? - **Insufficient lifeboats:** Capacity for only 1,178 of the roughly 2,200 people aboard. - **Underfilled lifeboats:** Several launched well below capacity. - **Inadequate training:** No full lifeboat drill before the disaster for crew or passengers. - **Outdated regulations:** Lifeboat requirements were based on ship tonnage rather than passenger capacity. - **Passenger confusion:** Uncertainty about the seriousness of the situation and reluctance to evacuate. - **Language barriers:** Communication difficulties among passengers and crew. - **Failed communications:** The nearby Californian's wireless operator was off duty and did not receive Titanic's distress messages. - **Segmentation between passenger classes:** Physical separation and restricted movement complicated evacuation. ## The illusion of understanding So let me ask you this: Given what you know, would you rather ride an ocean liner that has been improved by understanding the Root Cause of the Titanic, or one that has been improved by understanding all the diverse perspectives and contributing factors? As John Allspaw said about Five Why's and Root Cause Analysis: > "This is a construction that ignores a huge amount of complexity in an event, and it's the complexity that we want to explore if we have any hope of learning." The next time you're investigating an incident, ask yourself what you might be missing. Who haven't you talked to? What else could have contributed to what happened? And most importantly, have you stopped looking because you've found an answer?