What Apollo Can Still Teach Us
And it’s not just that we can do anything we put our minds to.
You’ve undoubtedly witnessed the plethora of books, articles, movies, interviews, and TV programming in the recent weeks, all attempting to acknowledge and celebrate the 50th anniversary of the first moon landing.
Most treatments of the Apollo program look back nostalgically: “We did something truly remarkable—and not just once, but six times!”
Some of these treatments seek to apply a challenge and lesson to the problems we face today: “If we as a nation could do that, why can’t we solve _______?” You fill in the blank.
I don’t discount the value in that type of thinking, but I believe there is a more immediate benefit to be gleaned from Apollo.
Apollo necessarily started as an exercise in constraint. Weight and size were on the minds of everyone who worked on the program. What was the least number of men and least amount of material needed to carry to the moon and back, and how could we make what we needed to carry as light and small as possible?
We typically don’t like constraints in the work we do because they seem to make the work harder. We ask questions such as: “Why can’t I have more staff?” “Why can’t I have more development dollars, more marketing dollars?” “Why can’t I have more time?”
Innovation science, however, shows us that constraints are actually beneficial. Constraints force us to make more or better from what we have. Constraints force us to ask more and better questions. Constraints force us to innovate inside the box. Apollo excelled at this type of innovation, and how it did that is a lesson from which today’s product developers, service providers, and process managers can benefit.
But I’m getting ahead of myself.
Back to the Future
In July 1969, I was sweating over stacks of freshly planed lumber in Polson, Montana. My father, a buyer of wholesale lumber, had done his best impression of Lyndon Johnson and twisted the arm of a supplier to get me the summer job at a lumber mill. There I was, a newly minted high school graduate from the suburbs of Chicago, working next to salt-of-the earth men stacking lumber and loading it on freight cars bound for every town U.S.A.
It was my “Summer of ’42” save for a Jennifer O’Neill.
It was also the summer of the first moon landing. And if the men I worked with were dubious about the whole Apollo program, as was much of America initially, their curiosity about the elimination of bodily waste in space was as infinite as space itself.
I, on the other hand, was fascinated with the Apollo program, having been fed a steady diet of space exploits courtesy of the earlier Mercury and Gemini missions. At lunch I would attempt to regale my ax- and saw-wielding mates with erudite descriptions of reduced gravity, rocket thrust, and orbital mechanics as I knew them.
But with little success.
Inevitably, one of them would look at me with a squinty, skeptical eye and ask, “Yeah, but how do they...?”
How pedestrian, I thought. Little did I know that theirs was to be one of the more prescient questions NASA would have to wrestle to the ground. More on that at the end.
Most coverage of the Apollo program focuses on President Kennedy’s challenge to the nation to go to the moon and return safely to Earth, the astronauts who flew the missions, and the sheer technological challenge of it all.
And it’s right to focus there. The Apollo program was the single largest enterprise ever undertaken by man, dwarfing the building of the pyramids, the Panama Canal, or our interstate highway system. It would involve some 420,000 scientists, engineers, technicians, electricians and just about any other type of “cians” you can imagine. And it would require some 2,000 contractors and subcontractors to work together to put the complicated Apollo puzzle together piece by piece.
President Kennedy may have laid down the challenge of going to the moon, but as anyone on the project would tell, knowing how to go to the moon was an entirely different matter.
They didn’t know what they didn’t know.
In the early ’60s, a rocket that was powerful enough to get astronauts to the moon didn’t exist. Nor was there an agreed-upon system to get them on and off the moon.
Computers, which were going to be the single most critical component of navigating in space, were at the time the size of a large refrigerator or walk-in closet. Imagine that inside what you know today as the tiny confines of the Command Module.
No one knew how to undock, dock, and re-dock two spacecraft in space. Solving that problem became a key determinant of success.
Mathematics certainly existed, but the extremely complicated math formulas required to determine flight paths, and orbits, and docking maneuvers didn’t.
Oh, those pesky details.
But, then, we know how the story ends.
Neil Armstrong took “one small step for a man, one giant leap for mankind.” We beat the Russians, which was all Kennedy really cared about. Democracy triumphed over Communism. Freedom and American ingenuity triumphed over totalitarianism.
Welcome constraints. They are your friends.
There are endless statistics associated with Apollo, but the most foundational one, the one that guided everything else, is this:
Every pound of man and material that the engineers wanted to send to space required three pounds of fuel to put them there, keep them there, and bring them home.
Multiply all of those three pounds of fuel times what you wanted to put into space thus required a container and propulsion system of a certain size. The more weight you decided to carry, the bigger the container and the more powerful the propulsion system had to be.
What follows are three examples of critical Apollo components where constraints forced the entire team to think differently and to innovate differently. And the common innovation process in each example was to divide the conceptual component into sub-parts.
The Saturn V Rocket — The rocket was and remains the largest and most powerful rocket ever built. It stood some 360 feet tall – the Statue of Liberty is 305 feet from pedestal to torch – and weighed about 6.5 million pounds. At launch, it could deliver some 7.5 million pounds of thundering, ground-shaking thrust.
But as the illustration to the left shows, characterizing the “Saturn V” as something singular is a bit misleading, because it was really a series of compartments and engines tied together. Each of those compartments and engines had its own function: get everything off the ground and into space; get the men and what was going to the moon into orbit around the earth; get everything headed to the moon; get everything into the moon’s orbit; land on the moon; get off the moon.
When the function was no longer required, the component was jettisoned or left behind. And the reason for doing that was weight. If the rocket had to drag all of those no-longer-needed components around, more fuel would have been required. Much more fuel.
The solution was brilliant. Divide and conquer. Break the single conceptual component into sub-parts.
The Lunar Module — One of the biggest and most heated debates among the planning team was how to get men on and off the moon. To make a long story very short, the engineers developed the Lunar Module (LM), which upon lift-off was safely stored in one of the rocket’s components. (You’ll find it in the Boeing diagram above.) Once in space, the Command Module – where all the astronauts were working – briefly separated from this component and pulled the LM out of its housing. Two of the astronauts would eventually enter the LM and head to the moon.
But like the Saturn V rocket, calling the LM a single “module” is a misnomer because it wasn’t one module; it was, as shown in the schematic at right, two modules. Joined together, the two components would allow the astronauts to descend and land on the moon’s surface. Once the astronauts were finished with their work, the top portion, which had its own engine, used the lower half as a launch pad. That half remained on the moon’s surface for eternity. (Yes, there are six of those lower platforms still on the moon.)
The solution was brilliant. Divide and conquer. Break the single conceptual component into sub-parts.
The Lunar Rover — Astronauts aboard the first three Apollo missions – 11, 12, and 14 – were limited in how far they could move away from the LM. They weren’t allowed to walk – hop and skip, really – too far away from the LM should they encounter any problems. This constraint limited their ability to study the moon and collect samples to bring back to Earth.
There was talk early in the planning of Apollo of providing the astronauts with a “moon buggy,” which would increase their ability to work far from the LM, but the issue was always space. Where would you store a lunar car on the LM that measured 10 feet long by 7.5 feet wide by almost four feet tall? (See an actual Rover pictured below)
Two engineers eventually came up with a solution. Take the idea of a “moon buggy” and build in structural flexibility. In short, make it so the Lunar Rover, as it was eventually named, could be folded up on Earth and then stowed in a relatively tiny compartment aboard the LM. Once on the moon, the astronauts would unfold the Rover’s frame and unfold its wheels and seats, which had also been tucked into the package. And that’s exactly what the astronauts did on Apollo 15, 16, and 17.
On the first three lunar landing missions – Apollo 11, 12, and 14 – astronauts covered a total combined distance of 4.4 miles. With a Lunar Rover, astronauts on the last three missions travelled a combined total of around 56 miles.
The solution was brilliant. Divide and conquer. Break the single conceptual component into flexible sub-parts.
Apollo gave the United States a critical victory at an important time in the Cold War against Communism. American ingenuity won out, and yes, it showed we can do great things when we put our collective mind and resources behind a problem.
But Apollo gave us more immediate and lasting benefits: a different way to think. Next time you stare at a product, service, or process concept, get your scissors out. Where can you cut the whole concept into parts to increase its flexibility and value? Where can you innovate within the box we call “constraints”?
Back to the question of what to do with the astronauts’ bodily waste, and I’m not making this up, OK? There was from the beginning no intention of storing it aboard the spacecraft.
What weight would it add?
Where would you store it?
How would you store it?
And most important, what would happen to the atmosphere inside the spacecraft should the storage container leak?
No, human waste was going to have to be ejected into space.
So, one of the lead engineers rightfully asked the “What would happen when we did that?” question. And here was the foundation for his concern: one of the principles of physics is that a thing being pushed has an impact on the thing pushing it. The force of ejecting human waste into space, the engineer reasoned, would act like the many small quad-stabilizing thrusters you see dotting the outside of the Command and Service Module pictured above. Those thrusters rotated the spacecraft and kept it pointed in the right direction. Forcefully ejecting human waste could impact the spacecraft’s direction, so much so that if not corrected, it could send the spacecraft off its course to the moon. The solution was to strictly regulate when the ejection of waste could take place and have its impact monitored precisely.
When I stare at the moon, I sometimes catch myself wishing I could find some of my fellow loggers and confess “You know, you were right all along.”
Pedestrian they were not.