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:

• Blame the person lowest on the hierarchy involved in the respective project.
• Then ask: is it fair to blame them? Were they sufficiently informed and supported?
• If the answer is “no,” then blame their boss.
• Then ask if that is fair.
• Keep on repeating this process until eventually the answer is “yes, it is fair to blame this person; they should have done more.”

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.

​You’ve likely seen this in action: people arguing about who was responsible for what, conflicting versions of the same plan, parts that don’t fit together, or teams who only discover they’re on different timelines after it’s too late. The best outcome when things like this happens is that you end up behind schedule. The worst thing is that the engineering goal is never achieved – or only partially achieved after blowing out the budget and the schedule.
This happens when engineering teams do not have shared situational awareness. Situational awareness is one of the core attributes of any successful team. And if you don’t have it, then, no matter how skilled the engineers in the team are, they will not be succeed.
This issue of lacking shared situational awareness is even more prevalent when you are members of your team are from different backgrounds. This is because each member will contextualise differently based on their background.
Therefore, as a global engineer, it is vital that you know how to create shared situational awareness.
Here are three simple but powerful ways engineers and engineering teams can build and maintain shared situational awareness – whether you’re working on software, spacecraft, or subways.

1. Get in the Same Room
It sounds simple, because it is. The first and most powerful step is to get everyone physically in the same location. In the Agile Manifesto, one of the key principles is: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
This idea has roots far older than Agile. In the Toyota Production System, it was formalized as Obeya (literally "big room"). The Obeya is a space where all the key stakeholders on a project – engineers, managers, planners – work together in close proximity. The room is visual, physical, and intentional. Everyone can see what’s happening. Everyone hears what’s being decided. No one is out of the loop.
Whether you set up a formal Obeya or simply commit to spending regular time together in the same place, you’ll notice an almost immediate increase in coordination, clarity, and energy. This will come from people talking to each other about what they are doing, and incidentally identifying differences in understanding to be corrected.

2. Use a Document of Absolute Truth
This isn’t some mythical or complicated concept – it’s a simple principle: everyone knows that no work is considered done until it’s recorded in one place.
This document – or digital repository – becomes the single source of truth for the team. It might be a master CAD model, a shared file tree, a wiki, or a visual project board. What matters is that everyone knows where it is, how to use it, and what it means.
When everyone refers to the same source, two things happen:

• Everyone has the same understanding of what the project needs to achieve.
• Everyone can see how their work affects, and is affected by, others.

These two things together make a core of shared situational awareness.

3. Schedule Regular Updates
Even with a shared room and a document of absolute truth, teams can still drift. People get absorbed in their own tasks. Decisions then get made in isolation. Then, eventually, you have conflicts within the team.
That’s why you need structured, regular updates. These aren’t just check-ins for the sake of it. They’re touchpoints that give everyone:

• A consistent, shared message
• A chance to ask clarifying questions
• A reset button on assumptions

It’s not enough to assume shared awareness will persist once achieved. It must be maintained. And that’s what the updates are for.

Final Thought: do you already do this or do you need it
Think now if you are someone who needs to put extra effort into ensuring shared situational awareness. Or maybe even needs someone else to do that for you because you always charge off working on your own tasks without thinking about others. Talk to my AI engineering coach Ingeny if you would like some ideas on how to deal with this.
Also, think about “documents of absolute truth” that you have come across. You might not have realised it at the time, but thinking back now, you can understand how they kept everyone on the same page. If you think of one, then share it in the comments – I like learning about techniques that people use.