Gene Kranz - Failure Is Not an Option

The Liberty Bell 7 mission was perfect until the very end and then it turned to worms. Rookies and veterans alike were once again reminded: there are no free rides in a flight test.

A rumor soon circulated that Gus had panicked when a small amount of seawater entered the capsule. I thought that was baloney. Everything I had seen of Gus and the astronauts indicated that they had the “right stuff.” Grissom’s hatch was the first flown with an explosive primer. Shepard’s had had a mechanical design. Something must have screwed up in the new hatch.

I returned to Virginia from the Cape the next day, and Marta greeted me with a sigh of relief, and a holiday of hugs and kisses. “Thank God, you’re here,” she said. “I didn’t think you’d ever get that thing off the pad. How did you make it so fast? Did you write your report on the plane?”

As a rule, we spent most of a day writing the post-mission report and did not leave until it was finished. I made quick work of this one. I had to because I was racing the stork. The next day I drove Marta to the hospital and, after a brief countdown, we were blessed with our third daughter, Joan Frances. Marta’s timing was impeccable. But she didn’t leave much to chance. With the births of each of our children, she had labor induced to assure that I would be on hand.

That happy event was in stark contrast to my on-the-job progress. Anger has always served me well, and I had been smoldering with anger and frustration for months at the Cape. I was largely angry with myself. I knew what to do but did not have the hands-on knowledge to do it. I felt I was not carrying my share of the load. My first step was to learn every detail of every system in the Mercury spacecraft and boosters. Then I intended to help Kraft train members of the mission teams to make sure we had the competence and knowledge that I knew we needed to carry out our mission.

I believed Kraft had several problems looming on the horizon. His systems controllers were good engineers, but as I had learned at Holloman, engineers needed to become operators. There was a hell of a difference. An engineer can explain how a system should work (in theory) but an operator has to know what the engineer knows and then has to know how the systems tie together to get the mission accomplished. If the systems break down the operator must make rapid decisions on fixing or working around the problem to keep the mission moving.

We also had to change the way we were thinking. We had not crossed the bridge from an aircraft test mentality to one suited to space flight. Aircraft pilots have an option to get to a runway or else to eject. In space, we were always hours away from a landing site. If there was some kind of glitch, Mission Control had to be prepared to develop options to keep the spacecraft going until it could be returned from orbit.

The third problem that I identified would take time to solve. Mission Control was a new idea to the astronauts. They responded directly to Kraft because of his authority, but were generally cool to the controllers. They would double-and triple-check what the controllers said and did. We had to earn their respect and trust. To do that we had to be smarter than they were in each of our technical specialties, and we had to be utterly precise and timely in every action. This was a hell of a chore when we were writing the book as we went along.

After returning to Langley from the Cape following the Grissom mission I was assigned the responsibility for the remote site teams, with eight NASA civil servants and sixteen technical reps from the pioneer electronics company Philco. The technical challenge was to develop the remote site team skills sufficiently so that any one of the site teams could take the actions required to keep the mission going when things went wrong. The Philco personnel were from across America, virtually self-taught with an incredible mastery of communications, electronics, and data systems. They had staffed the tracking stations in Alaska, California, and at Kwajalein in the Marshall Islands in the South Pacific for the early Air Force satellite missions. The civil service recruits were mostly fresh college graduates. The shotgun wedding between the young scholars and the Philco controllers was just what we needed to bring instant maturity and poise to the fledgling remote site teams.

The bible on the Mercury capsule was the pocket checklist, a five-by-seven-inch set of schematics sized to fit in the pocket of the astronaut’s flight suit. I knew from my own flight test experience that this wasn’t adequate. Based on everything I had learned at Holloman, you lived or died by the data at your fingertips. This slim volume was the sum total of our knowledge, and it reflected the naÏveté of the engineers who produced it. I wanted to build a data set like the one I had had at Holloman. I got two engineers from McDonnell assigned to work directly with me at the Cape and at Langley. They would get the engineering data and test reports for me from McDonnell Aircraft’s St. Louis plant and help me boil it all down to information that was useful and instantly accessible.

Kraft was skeptical but gave me the benefit of the doubt. Two fine engineers, Ed Nieman and Dana Boatman, joined my remote site group. I would have my people train themselves in the same way I came up to speed as a flight test engineer. Each controller would research a capsule system to get a deep understanding of it, with the contractor’s help. When you are sitting at the console, you want a set of handbooks with certified correct data, formatted so the information can be accessed and used in seconds. We needed to separate the “nice to know” from the “must know.” We had to get the data that would enable us to work problems that were workable, and discard all the data that applied to problems that could not be solved by the crew or controller.

To manage this large mass of information, I assigned a single capsule system to each controller. He had to grind through it and digest it, put it in a readily usable format, and cross-check it with test reports and specifications. We built a comprehensive handbook out of this data. Once we had the words on paper, each controller taught the entire team about the system he had studied. This gave us a common frame of reference among the crew, the remote site controllers, and those in the control center. Once we got the data right then, in similar fashion, we wrote the troubleshooting procedures the crew would use, and from there we moved on to codify all the operational rules.

The potential for a superb real-time team was realized as the controllers fanned out to the remote tracking sites. Each mission was a final exam for the controllers; some passed the test and some didn’t. Those who survived the early missions became leaders in the rapidly developing art of space flight operations.

The next mission would use the capsule recovered from the flight that had been snuffed by the RSO on the third Mercury-Atlas mission. We had lost the booster but saved the capsule. When the destruct signal was sent, the escape tower fired and pulled the capsule away from the explosion. Then the tower separated from the capsule, the parachutes deployed, and the capsule landed safe and sound in the ocean.

Mercury-Atlas 4 was a simple orbital test of the Mercury spacecraft and control teams prior to a three-orbit mission with a chimpanzee. But there was a greater significance. This would be the first worldwide mission deployment since the global network had been completed five months earlier. For us, it was like planning the Normandy invasion. Thirteen teams of three controllers were sent, in those days mostly by slow prop-driven aircraft, to the distant corners of the Earth to function as self-contained mini-control centers. The teams had to be self-sufficient, so they carried everything needed for mission support, often including maintenance manuals and spare parts. The teams were mostly made up of men in their twenties; only one of the CapCom’s team leaders had been overseas before.