Why Spacecraft Explode, and Managers Hide the Evidence In 1999, NASA lost two Mars missions. The technical causes were clear. The organisational causes were not — at least that's what I thought.  If they are not made to think otherwise, the boss will assume others below are at fault The Mars Climate Orbiter was destroyed when one team used metric units and another used imperial. The Mars Polar Lander likely failed because its software misinterpreted the deployment of landing gear as touchdown, cutting the engines too early.
Not long after these events, I was lucky enough to attend a presentation by Chris Johnson, who had been asked to investigate the disasters. He specialised in safety — how to prevent incidents, basically. His job was not to understand the technical causes (they were known); his job was to explore the organisational aspects that allowed the causes to exist in the first place. His presentation included a number of interesting elements. For example, he was told by some government departments that they had evidence the lander was on the surface — but they could not tell him what their evidence was (that was classified). Another example was that he studied the code in the system and found that the power management software kept resetting the emergency beacon — so even if the lander had survived, it would never have been able to let anyone know. There were many examples within his investigation that would help demonstrate key principles of engineering expertise — or, at least, what can happen when they are not applied. However, the one element I found most interesting in his presentation was Tier Analysis. Tier Analysis is a tool used to find the root cause of failures from the perspective of the organisation. It checks that each level of the organisation has done what it should to prevent the respective failure. In his presentation, Chris Johnson said it was basically like this:
In the presentation, Chris Johnson noted that Tier Analysis had proven popular with many organisations. However, as they used it, they found that often there was a lot of blame placed on middle and senior managers. Those managers didn’t really care for being blamed — so they decided to stop using Tier Analysis. And that is why I can say: it probably is the boss’ fault. What does this mean for Global Engineers? You can probably see how the application of Tier Analysis — and managers choosing not to use it — demonstrates the importance of well-functioning engineering teams. Shared situational awareness efforts, dedicated to ensuring all team members understand what is trying to be done and how, would mean more people could spot gaps in plans and point them out before it’s too late. So if you are the boss, be mindful of ensuring those under you have all the information they need. If you are not the boss, then consider taking on the role of documenting everything and sharing it with others (including your bosses), so that potential issues can be spotted before they become disasters. What would you do differently? Have you ever been in a project where things went wrong — but the real problem was further up the chain? Would a better flow of information, or clearer expectations, have helped? Drop your experiences or thoughts in the comments — I’d love to hear how you’ve seen this play out in your own engineering career.
0 Comments
|
AuthorClint Steele is an expert in how engineering skills are influenced by your background and how you can enhance them once you understand yourself. He has written a book on the - The Global Engineer - and this blog delves further into the topic. Archives
June 2025
Categories
All
|
RSS Feed