Shuttle Discovery on pad 39a, night before her final launch

My visits to NASA for this launch were an amazing experience, but I also noticed a valuable lesson for company founders and leaders.

Innovation and reliability sometimes compete, but they matter differently to each of the things you do. At any stage and any size, your company can be more nimble and accepting of failure where needed, and more risk averse where needed. The trick is knowing the difference and taking advantage, rather than succumbing to the temptation to always favor one over the other.

Perhaps a more interesting way to look at it might be that we’re always engineering a reduction in different kinds of risks. Focus on the right one to reduce for each problem, and we can meet our most important and appropriate goals. Beware the temptation to manage the wrong risks.

More about the lesson and the launch, with a few of the snapshots I took on this trip (all are unedited/uncropped from my point-and-shoot Canon sx30is), after the break…

The world's most famous clock?

“Tears.”

That was all I could think to Tweet after Discovery lifted off as I stood feet from the world-famous countdown clock.

The physicality of the launch from that distance (as near as any are allowed to be, and miles closer than the public), is enough to change your emotional state. The sound of the SRBs and main engines reverberates in your chest at least as much as in your ears.

Discovery's last launch (STS-133)

I was also intensely aware of how many people had worked tirelessly to make one of the world’s most complex machines ready to fly one more time. I was lucky enough to talk to many of the astronauts and managers during the programs NASA put together for us.

Even when things go well, the Shuttle is amazingly complex. So much goes into planning and carrying out a launch and mission under the best of circumstances.

Last November, I was here for a series of delays and an eventual scrubbed launch attempt. After that, cracks were found, and Discovery pulled off the pad to make modifications to her External Tank (note the lighter orange band on the ET — those are the repair). For me, this meant the inconvenience of a second trip to Florida. For countless NASA employees and contractors, it meant significant parts of the 100 elapsed days working around the clock weekends and holidays throughout that time to investigate the problem, come up with solutions, run the math and execute the plan. Thousands of people were involved. The layers of procedure they work through and documentation they create to come to agreement about root cause, to understand risk, confidently eliminate it and generate flight rationale is stunning.

Last trip, a turkey vulture, this one, a Huey, flies in front of the Vehicle Assembly Building.

Really though, they added a drop in the bucket to the enormous history of human energy that has accumulated in the shuttle program. When she took off, I could feel all that blood, sweat and tears, all that amazing capacity we as a species have to reach beyond and do what should be impossible. And to be safe and reliable at that.

Remember that moment in the Apollo 13 movie where the engineers work all night to figure out how to put a square air scrubber in a round hole (or was it vice-versa)? It may not always be so obvious, but that’s practically a day in the life. NASA always has to solve problems with lives in the balance, before and during missions.

In the week after the launch date was made official, the countdown started and went smoothly, but we still ended up with a nail-biter. The Range computer went down, resulting in a No-Go and an unplanned hold at T-5 minutes. A verbal OK and override was given by RCO with just seconds before another scrub would have been forced. Even the professional media gathered to cover the event let up a cheer when the countdown resumed.

All that, and the knowing that this would be Discovery’s last flight before she retires to a museum. There were few dry eyes after liftoff.

That’s what it feels like when we have a new product launch, too, doesn’t it?

During the dot-com boom, we mostly built startups the way NASA builds rockets. Acting as if we knew exactly where we were going, we layed out elaborate plans to get there and set huge teams of engineers to multi-year projects building out software to do it. We often ended up with robust solutions no one wanted to buy.

Zoom.

We’ve learned a lot about how much we usually don’t know in a startup. The first risk to manage in most new products is that we don’t know enough about our customer and what the product would look like that they’d really use.

Better tools make it easier and faster to build web startups with smaller, more nimble teams. The welcome trend is toward doing better customer research up front, incorporating good user experience design, and Lean Startup methods. You can reduce risk by getting to know customers early and often, putting low-fidelity prototypes in front of them early and then getting actual usable software into their hands as quickly as possible. Then you repeat the process, iterating on making changes and looking for customer feedback, constantly learning, proving assumptions and getting new insight and inspiration.

When you get a good product/market fit, then you face the problems of building to scale and refactoring the prototype code that customers are actually using. You have to create a more robust implementation. Now you start to get into the situation where people really are depending on your code and downtime or failures are much more costly. You get to do both at the same time, sometimes focusing on enhancing reliability and maintainability, sometimes focusing again on innovation and customers and market. The more flexibility you have to do both, the better off you are.

It starts happening much earlier, but it’s easiest to see at the extreme: If you’re lucky enough to get to be the size of Google (or Yahoo or Microsoft), you’ll run into the problem that the temptation is to use large teams and build everything to work with your scalable architecture (see Why Google can’t build Instagram, for great insights about their innovation problem). When you want to try out a new feature or product, rather than prototype it with the fastest available tools and try it with a small audience, you’ll build it more slowly so that it can scale if you turn it on to the firehose of traffic you can send to it. When you acquire a new startup, you’ll let them spend their first year integrating their code rather than continuing to innovate. You’d be better off keeping more teams separate longer, running skunkworks operations to prove new concepts before handing them off.

BBQ.

One way NASA demonstrates that it is nimble enough to use different rules in different domains is in how it handles social media. Despite all the beauracracy of a large government organization and the heritage of “Failure is Not an Option” engineering, in this area, they’ve managed to take more risks, embrace test and learn, and allow for public mistakes and a human face that people want to engage with. In a recent study, NASA ranked first of 100 public sector organizations based on the effectiveness of their websites, social media use, mobile sites, and digital outreach. In fact, they came in 26 points ahead of its next closest competitor. The biggest risk most companies face in social media is the risk of not engaging in authentic conversation with customers, of being too afraid of mistakes and failure, and too conservative in what they’re willing to try.

Be mindful with any problem set. What don’t you know? What risks can you afford to take in order to learn more quickly? How can you better connect with your audience by being open and transparent? Often, you are best off trying things and failing as fast as possible to learn more quickly. At other times, slowing down is valuable, and sometimes, you’ll need adopt a more risk-averse stance. In a startup, you’re likely to move between problems in each of these areas every day. Godspeed.

(See also my earlier posts about my November trip and my history as a Rocket Scientist. Thanks to NASA for inviting me back a third time and for access to so many sites and people along the way. Shout out to all the media and Twitter folks I met along the way, and special thanks to Stephanie Schierholz (@NASATweetup) for all your hard work and facilitating so much kind hospitality for us! Catch her SxSW panel in a couple of weeks.)