NASA is a bedrock of innovation. In one place, some of our greatest engineers build technology that can take us to unexplored worlds. However, NASA isn’t immune to problems, and we can learn from its failures. On September 23, 1999, the Mars Climate Orbiter burned to pieces. It had exemplary talent, and the hardware was getting the right inputs. Why on earth did it burn up? The Orbiter’s team that designed the navigation system used the metric system (newtons) to calculate force. Although, the engineers that built the spacecraft built it with the English system (pounds). There was no conversion; therefore, the Orbiter missed orbit by ~90 miles or ~144 kilometers. It’s too bad. The Orbiter would have been part of a communications relay on Mars for further missions.
How does that have anything to do with digital transformation? The problems that NASA experienced with the Orbiter are similar to those companies that are going through transformation efforts and scaling out data platforms are sharing today. I’ve seen several challenges identical to the Orbiter and have taken similar lessons from them. Here are five that jumped out to me while reading about the Orbiter.
- Test Your Governance Framework
If you’re like me, you ask, “how could that happen?” It wasn’t that NASA didn’t have a governance framework. They have a very robust one. It was a function of the framework that didn’t work as intended. Lockheed Martin was the contractor brought in to do the navigation work. They simply used a different unit of measurement. The lesson here is that if you have a framework to catch problems, ensure it’s working from time to time. The TSA does this where the baggage scanner will artificially flag something and force attention optimization on complex cognitive workloads. Their system ensures that the process is working by introducing fake data, measuring agent success, and ensuring the operations continue to work.
You Have 2. Communicate
“What we’ve got here is a failure to communicate.” - Cool Hand Luke.
It’s evident that regardless of the systems, there wasn’t a communication channel between the engineers. I’ve seen this too. The people building the technology in a company are isolated from the people using the technology. Guess what happens. You end up with similar results. Agile approaches seek to remove some of these barriers and get the builders working with the users. Or, in a scaled framework getting the teams communicating rather than going through a single mastermind. Communication is a key capability for any team looking to transform how their organization.
- Know The Collaboration Blind spots
Large complex projects and initiatives require collaboration. We know that. If you want to send a rocket to the moon, one person isn’t going to accomplish that. Some studies tell us what happens when collaboration isn’t working. Lisa Kwan of HBR writes about the blind spots created by the need for people to seek security in their work. When leaders ask for collaboration, sometimes, if the goals are not shared, there can be issues with how groups perceive each other. Her belief is that when groups grow concerned about security, they go defensive and guard their territory to reduce the threat. I’m not sure that’s what happened between NASA and Lockheed Martin. Still, it triggered my thoughts to ensure that I have true collaboration and not teams in a defensive stance.
4. No Code is Perfect
I’ve had engineers and developers that like to tell people their code is crap, and they could do it better. Let’s call that perfect engineer “Ace” for this discussion. Perhaps Ace could do better, and in the proper context, I love the work of trying to make things better. I have a basic rule: working was better than perfect if the code met the requirements. Also, I was not too fond of the environment it fostered when people belittled others’ abilities. It’s hard to get people to separate from the code they wrote and themselves when peers give feedback, especially unexpectedly. My biggest challenge was that Ace had extreme blind spots in thinking their code was infallible and liked to tell others how bad theirs was. Ace was also cognitively rigid. Once Ace locked into an idea, that was it. But Ace was coached and became a leader. As leaders, QA’s, and reviewers, you know that all code has bugs. No code is perfect, so your best defense is to test. Ace can help write great software, but you have to assume that it will not be perfect even with all the talk. Leaders need to know that code is about getting close to perfect, but you have to roll with some imperfections to have a chance to hit your goals.
- Learn from Mistakes
Here’s an easy one. NASA does learn from its mistakes. They also don’t stop trying. They plan, build, execute, and then try to understand. I love the retrospective concepts in Scrum. Suppose you don’t have a formal committee or review of projects. In that case, you should consider having retros on your digital initiatives. At a minimum, you can keep learning about how to evolve and become a better organization. Digital transformations don’t happen overnight, so you will likely have many retros on your journey.
References
In Depth | Mars Climate Orbiter – NASA Solar System Exploration
Why Trying to Make People Collaborate Freaks Them Out (hbr.org)
How to Build Digital Dexterity Into Your Workforce (hbr.org)