Tough and Competent
What Software Developers Can Learn from Gene Kranz
Eugene (Gene) Kranz is an American former aerospace engineer, fighter pilot and NASA flight director. Most people will know him as the character portrayed by Ed Harris in the 1995 film Apollo 13. During the Apollo 13 mission, Kranz was the lead flight director, working from Mission Control in Houston, Texas. Approximately 180,000 nautical miles from Earth, just minutes after a successful television broadcast from the Apollo 13 craft, a routine stirring of oxygen tanks caused an explosion which set off a dramatic series of events. Fighting against ridiculous odds, Kranz lead the efforts which saw the crew land safely back to earth. Oh and he also was one of the men behind the first Moon landing.
You may wonder what this has to do with software engineering, but as you delve into the story of how Kranz handled the dramatic situations that unfolded during Apollo 13 and Apollo 1, there are definite parallels to be drawn. I’ll maybe have a follow up post about Kranz and Apollo 13 but for now, I want to concentrate on his words following the doomed Apollo 1 program.
Apollo 1 Disaster
Originally scheduled to launch in February 1967, the Apollo 1 mission was to be the first crewed mission of the Apollo program to take the first humans to the Moon. The mission was never completed. In January ’67 a “plugs out” test was carried out. This was to test the ability of the spacecraft to operate on internal power only.
The three astronauts, Chaffee, White and Grissom took their place inside the command module during the testing. While running through their checklist, they noticed a fire had broken out. Frantic transmissions were heard over the space of just a few seconds as the men tried to escape. White tried to open the command module, but internal pressure made it impossible. The men were unable to escape and all three sadly perished in the command module.
Subsequent investigation identified several factors which caused both the fire and the astronauts’ deaths.
- The hatch cover could not be quickly removed at high pressure
- An extensive distribution of combustible materials in the cabin
- Inadequate emergency preparedness
- Pure oxygen atmosphere at higher than atmospheric pressure
Mistakes had been made, and on top of that, there were inadequate processes in place to prevent these mistakes. Take for example the combustible materials. During a review a few months before, the astronauts raised their concerns about the amount of combustible materials. These were then ordered to be removed, but the removal was not overseen. It was evident that the astronauts concerns were not properly address as it was noted that during the retrieval efforts, the large amounts of melted nylon fused the astronauts to the cabin interior. It is disputed whether they were removed and then replaced in the months in between or had never been removed at all.
So where does Kranz come in?
Monday morning, just three days after the accident, Kranz called a meeting of all his staff in Mission Control. In that moment in the aftermath of an event in which three colleagues died in such a horrific way, he stood in front of his staff and he delivered a powerful speech, now referred to as the Kranz Dictum. At some point, we’ve all probably been at the end of some sort of bollocking due to mistakes, but it is difficult to imagine the mix of tension and grief in the room when he delivered these words.
Even though (mostly) we are not in the life and death situation that Kranz is referring to, the idea behind his words can be applied directly to day to day work as a software developer.
The Kranz Dictum
Spaceflight will never tolerate carelessness, incapacity, and neglect. Somewhere, somehow, we screwed up. It could have been in design, build, or test. Whatever it was, we should have caught it. We were too gung ho about the schedule and we locked out all of the problems we saw each day in our work. Every element of the program was in trouble and so were we. The simulators were not working, Mission Control was behind in virtually every area, and the flight and test procedures changed daily. Nothing we did had any shelf life. Not one of us stood up and said, “Dammit, stop!” I don’t know what Thompson’s committee will find as the cause, but I know what I find. We are the cause! We were not ready! We did not do our job. We were rolling the dice, hoping that things would come together by launch day, when in our hearts we knew it would take a miracle. We were pushing the schedule and betting that the Cape would slip before we did.
From this day forward, Flight Control will be known by two words: “Tough” and “Competent”. Tough means we are forever accountable for what we do or what we fail to do. We will never again compromise our responsibilities. Every time we walk into Mission Control we will know what we stand for. Competent means we will never take anything for granted. We will never be found short in our knowledge and in our skills. Mission Control will be perfect. When you leave this meeting today you will go to your office and the first thing you will do there is to write “Tough and Competent” on your blackboards. It will never be erased. Each day when you enter the room these words will remind you of the price paid by Grissom, White, and Chaffee. These words are the price of admission to the ranks of Mission Control.
There are a couple of key things that stand out to me from this.
- “We were too gung ho about the schedule and we locked out all of the problems we saw each day in our work.”
We’ve seen this many times. Projects that are focused on delivering to a dictated time, rather than delivering a high quality product. In these circumstances you see corners being cut and the abuse of the term MVP to allow allow delivery and the receipt of kudos. - “Not one of us stood up and said Dammit, Stop! We are the cause, we were not ready! We did not do our job!”
Everyone needs to hold themselves accountable, regardless of grade or experience. If you believe things are just not right, it is your responsibility to stand up and call it out. The lack of voicing concerns contributed to the disaster here. This is the kind of thing you notice during any post-mortem of project failures, or problems — someone saying they thought there might have been an issue with that but they didn’t want to say anything, or thought someone else knew better. - “It could have been in design, build or test. Whatever it was, we should have caught it.”
You need to make sure you have robust processes in place to be able to catch problems and an environment that supports questioning and probing decisions and designs.
I want to briefly jump back to the review meeting that identified the high level of combustible materials. I see this very much like a code review. Here, action was to be taken based on review, but then it seems the required actions did not happen and there was no oversight or process in place to check it. Are your team’s review processes solid enough? Problems identified during review, how do you ensure the corrective action has been taken?
If you want to know more about Kranz
I do recommend doing a bit of reading into Kranz and his stories because they are fascinating, and a lot can be learned from them. If you think about it, he was a key player in the disaster of Apollo 1, the brilliance of Apollo 11, and the impossibility of Apollo 13.
- Saving Apollo 13, a podcast by Brady Heywood. This is an excellent podcast in which Sean Brady tells the story of the Apollo 13 mission. I had not seen the film and knew little about the mission, and I knew nothing of Gene Kranz. Sean is a Forensic Engineer, and the content of the podcast is really well delivered and with the perfect level of detail.
- Failure Is Not an Option, Gene Kranz. A book by the man himself detailing his time in Mission Control from Mercury to Apollo 13 and more.
- Kranz Dictum, Gene Kranz. Watch Gene recite the same speech decades later. Kranz Dictum Youtube
