What NASA's $327 Million Mistake Can Teach Your Agency About Systems

In this week's email newsletter, we are sharing the story of what happened to the Mars Climate Orbiter in 1999. One team sent navigation data in US customary units. Another read it in metric. The spacecraft burned up over Mars. $327 million gone.

But we promised to go deeper here, and we meant it.

After the mission was lost, NASA did something worth appreciating: they assembled a formal Mishap Investigation Board, sat down with the engineers and navigators involved, and published a full report on exactly what went wrong. Not to assign blame, but to understand it. If you are a space nerd or just genuinely curious, you can read the full report here.‍

What they found wasn't one mistake. The investigation identified eight contributing causes in total. We are focusing on the five most relevant to how agencies operate, because each one has a name, and if you run a team, you have probably lived at least one of them.

📺 Watch: The Breaking Point, the official NASA documentary on NASA+ that covers exactly this story.

‍

1. The document existed. Nobody checked if it was being followed.

NASA had a Software Interface Specification, a document that clearly required all navigation data to be delivered in metric units. Lockheed Martin's software was delivering it in US customary units. The document said one thing. The software did another. Nobody was required to verify the two were aligned.

This is the most common systems failure inside agencies and the quietest. A process gets written down, added to a folder, shared in onboarding, and then never touched again. The assumption is that because it exists, it works. A process document without a verification step is just a wish.

In ClickUp terms, this is the difference between having an SOP and building the SOP into the workflow itself, where it can't be skipped, where completion is visible, where someone is accountable for signing off.

🔗 Related Read: SOPs vs. Workflows
‍

2. Two people noticed something was wrong. There was nowhere to send the concern.

Throughout the spring and summer of 1999, navigators on the team noticed the data wasn't adding up. They raised the concern. Informally. The investigation report notes the discrepancies were "noted but only informally reported" and were never resolved.

NASA actually had a formal reporting system for exactly this kind of situation. It was called the Incident, Surprise, Anomaly process. Most of the team either didn't know it existed or didn't feel empowered to use it.

Inside agencies this shows up when someone on the team senses something is off, with a client, a deliverable, a process, but has no clear path to surface it. If the only option is an uncomfortable conversation with a manager, most concerns stay quiet. A good system makes raising issues easy and expected, not just theoretically possible.

3. Critical knowledge never transferred when the team changed.

When the Mars Climate Orbiter passed from the team that built it to the team that would fly it to Mars, almost nobody made that transition with it. The operations navigators inherited a spacecraft they had never been involved in building, with assumptions they had never been asked to question.

They assumed it behaved like the previous Mars Global Surveyor. It didn't. Nobody told them. Nobody documented the differences.

This is the handoff problem. And in agency life, it is one of the most expensive problems there is. A client account changes hands and the new person inherits the relationship without the context. A team member leaves and takes years of institutional knowledge with them. A process that worked beautifully for one project gets applied to the next one without anyone stopping to ask whether it still fits.

The fix isn't hoping people will communicate better. It's building handoffs that require the transfer of specific documented knowledge before the transition is considered complete.

📕 Related Read: How to Write Standard Operating Procedures (SOPs)
‍

4. The team was understaffed and nobody was checking their work.

At the time of the Mars Climate Orbiter's final approach, the navigation team was essentially two people. Managing a mission critical event. While also supporting two other simultaneous missions. There was no independent peer review of their trajectory analysis. Nobody outside the team was looking at their calculations.

The investigation board found this to be a direct contributing cause. Not because the navigators were incompetent. But because even the most talented people make mistakes under pressure without a second pair of eyes.

Most agencies will recognize this one immediately. The senior person who is across everything but accountable to no one. The founder who reviews their own work because there is no process for anyone else to catch errors. The account manager handling six clients with no structured oversight of their deliverables. Peer review doesn't have to be formal or time-consuming. It just has to exist.
‍

5. When something went wrong, nobody had a plan for it.

In the final hour before orbital insertion, the navigation team realized the spacecraft was heading too close to Mars. A contingency maneuver had been on the schedule the whole time. It could have corrected the trajectory. They didn't execute it.

Not because they didn't want to, but because nobody had defined when to use it. No agreed criteria, no training, no designated decision maker. With the clock running, the team defaulted to the original plan and hoped for the best.

Most teams build processes for how things are supposed to go. The harder and more useful work is building processes for what happens when they don't. Who makes the call when a client relationship breaks down? What happens when a key deliverable is missed? Those questions need answers before the moment of crisis, not during it.

📖 Related read: What Is A Contingency Plan And How Do You Create One? via Forbes
‍
‍

What the investigation board actually concluded

After months of review, the board landed on something worth sitting with: the problem was never the error itself. It was that nothing in NASA's system was built to catch it before it became irreversible. Talented people, sound technology, but a structure that had no way to surface what was going wrong or stop it in time.

Every one of the five points above is a systems problem wearing a people costume. The navigators weren't careless. They were doing their jobs inside an environment that made certain kinds of failure almost inevitable, not because anyone chose that, but because the right checks were never built.

The dropped balls, the client escalations, the good person who quietly burns out and leaves. These things rarely happen because someone wasn't trying hard enough. They happen because the infrastructure holding the work together was never quite built to hold it.

That's the work we love doing at stackset. If any of this felt familiar, we'd love to talk.