May 21, 201912:15 PMOpen Mic
Send us your blog for consideration!
What working in Mission Control taught me about product development
(page 1 of 2)
I had the coolest job in the world for a while. I helped assemble the International Space Station from one of the consoles in NASA’s Mission Control Center as a senior member of the ISS electrical power flight controller team. A lot of my most meaningful experiences happened in that incredible intellectual environment. Many of my best — and most painful — professional lessons were learned there.
Steve Cantley at NASA's Misson Control Center, circa 2000.
Over several years, I’ve developed a presentation about what engineers and managers need to learn from the loss of the space shuttle Columbia in 2003. It’s part of the “most painful” list mentioned in that first paragraph. I had the opportunity a few weeks ago to present it to seniors in mechanical engineering at UW–Madison.
After I’d finished, one student came up to me seeking advice before starting a co-op tour this summer in Mission Operations. I offered a couple of off-the-cuff thoughts. “What group are you joining?” I asked. The answer blew my mind. This student would be in my old group — or, at least, what it has morphed into. Sometimes, the world really is quite small!
Later, I emailed a more complete list of ideas for how to be successful as a NASA co-op. Here are the ones most relevant to product development:
1. Ideas are complex, but communication doesn’t need to be.
Work on your ability to communicate complex ideas clearly. In Mission Control, there is no currency more valuable than clear communication. Discussion within Mission Control frequently takes place without being able to see the person you’re speaking with. Visual cues for good communication aren’t available. Written communication — like procedures — needs to be tight and unambiguous. This is less about product development in general than it is about success in any profession, but in this day of frequent phone calls and constant email, clear and simple communication is valuable.
2. Understanding history makes your results stronger.
I wrote of the need to immerse in NASA’s spaceflight history — the Apollo 1 fire, the Challenger and Columbia accidents, STS-51F, and a few even more obscure examples. Why is this relevant? When I’m working on a project for a client, it’s important to understand the rest of the market around that new product idea. What similar things has the market seen before? How did previous products perform? Where were the strengths? Weaknesses? Understanding history helps our team be better developers.
3. Search for failure modes in creative ways.
I described a mentoring tool I used when working with junior flight controllers. We’d think aloud at one another about unique ways to turn off the ISS’s power system — fresh series of commands to accomplish the task in creative ways. This was useful because each of the novel sequences could be replicated through a series of system failures. Walking through them led to a deeper understanding of our system. As product developers, we all love to think about features, forms, interfaces — all the positive attributes that users will love. However, things fail. Understanding the myriad ways in which this can happen, and especially trying to be creative about how failures might manifest, helps us make products less prone to fail, and fail gracefully if they do.