Failure is Always an Option

On April 13, 1970, the words “Uh, Houston we’ve had a problem” were uttered by Apollo 13 astronaut Jim Lovell describing the crippling damage to the command module 56 hours into the trip to the moon.

Back on earth, Gene Kranz, the Apollo 13 flight director, uttered the now famous but mis-quoted words “failure is not an option” to his team when charging them with the responsibility to solve the problems with the damaged space craft and return the astronauts safely to earth.

What followed is one of history’s most memorable problem-solving moments. Despite all the planning, testing, and practice, nobody was prepared for this situation. They collaborated and found creative solutions that were rumored to include duct tape. Never leave home, or earth apparently, without it.

Fast forward to the 2000’s and Adam Savage, from television's popular “Myth Busters” show challenged that wisdom with the words “failure is always an option.” Certainly, the experiments they did were living proof of that.

Which is it? I will argue that while both are completely opposite statements, they have the same message.

Risky Business

In the simplest of terms, I describe my profession of project and program management as managing risk. We like to think that failure is not an option on our software projects, but experience tells us that no matter how hard you try, failure is, in fact, always an option. The object of the game is to minimize the frequency and impact of those failures by planning to fail.

To Plan B or Not to Plan B, That is the Question

Early in my career, I used to say “always have a plan B.” I knew there was always going to be something that would go wrong, and I had to come up with a contingency plan because I knew enough to realize that plan A was certainly going to have some risks that could not be mitigated. That theory stood the test of time for a few short years. The projects I managed were relatively small, low risk, and fairly predictable.

Today, modern software projects are orders of magnitude more complex. My career has advanced to the point where I am working with the giants of industry in complex transformational enterprise-wide programs.

The plan B theory falls apart in this context. I need a plan C, D, E, F… However, plan A is so complex that contingency planning for that many variables is itself rife with risk. These programs are so big, move so fast, and change so frequently that by the time you came up with plan B, it would be obsolete because something changed on you. 

If you can’t come up with a plan B, what do you do? Easy, make sure plan A works. More to come on that note.

Doors and Corners

I started binge watching the sci-fi series “The Expanse” on Amazon Prime. I love good sci-fi and this one really captures my imagination. The characters are multi-dimensional and as real as any you’ve seen. One of the main characters is a detective. He is in many scenes where he is chasing bad guys thru some kind of building or space ship.

With his gun drawn, he carefully moves thru the building and sometimes mutters softly to himself “doors and corners, doors and corners.” In one episode he explains that the riskiest parts of these pursuits are the doors and corners because you can't see what’s on the other side or around the corner, so it’s riskier than walking thru a large open room where the bad guys can be spotted easily.

You have to have heightened awareness when approaching doors and corners, anticipating the risk and being prepared for the bad guy to jump out at you. You may not know exactly what awaits you, but you can rely on your training and instincts to mitigate those risks and react instantly.

Complex software projects are full of doors and corners – and long narrow hallways both literally and figuratively.

Doors represent complete unknowns. You know you have to open the door and get to the other side, but you don’t have any idea what’s there. Big time risk.

Corners represent pivots or sudden, unplanned changes in direction. These are high risk, but it is possible to at least identify the most likely pivots and track the parameters that indicate whether the likelihood of that event is increasing or decreasing.

Hallways represent decisions. Once you decide to go down a hallway, going back is either too expensive or virtually impossible. Leading your team single file toward the other end that may have a whole new set of risks to deal with, requires a lot of grit and determination. Worse yet, if somebody slams the entry door shut behind you, leaving only one way out - that is straight ahead, you and your team better have your A-game on.

Prepare your team to take all risks head on and fight your way out if necessary. As one saying goes: the best defense is a good offense. On the other hand, planning to fail may keep you from ever having to go down that hallway in the first place. As Mr. Miyagi famously and wisely counseled his protegee Daniel-san in the 1986 movie "Karate Kid 2", "...best way to avoid punch --- no be there".

Complex software projects and programs are full of doors, corners, and hallways. You can’t plan for all contingencies. You have to learn to react quickly and decisively. Experience gained over the years has given me a bit of an advantage predicting the likelihood of a risk biting me and allows me to plan to fail and prepare for the most likely scenarios, but how do you account for the random risk?

Cover and Move

In the leadership book “Extreme Ownership: How U.S. Navy SEALS Lead and Win”, one of the chapters talks about the SEAL tactic of “cover and move.” They employ this tactic when advancing toward or retreating from an active hostile situation. Part of the team provides over-watch and cover fire if needed, while the other part of the team moves. The leapfrogging minimizes the risk of moving by providing constant protection to the team.

In complex programs and projects, teamwork is a critical element. There is no room for showboating, and individuals acting alone increase the risk of failure. The team must think and move as one. They must communicate clearly, and efficiently and always watch each other's backs. The team lead is responsible to communicate the objective, and then make sure the team is empowered to make decisions and actively participates in planning the mission.

In my world as a program manager, I provide the command and control cover for my team so they can advance toward the objective safely. I empower them to self-organize and make decisions. This is an extremely powerful combination and if employed correctly, builds a tremendous bond of trust among the entire team. This gives them the ability to react quickly and effectively to change and threats without a lot of discussion.

So how do you learn how to be a good team leader?

Be the dumbest person in the room

On LinkedIn I follow the late Jack Welch, former CEO of General Electric and founder of the Jack Welch Management Institute. I love the many quotes that are posted in his name. One of my very favorites is: “When you are a leader, your job is to have all the questions. You have to be incredibly comfortable looking like the dumbest person in the room. Every conversation you have about a decision, a proposal, or a piece of market information has to be filled with you saying, “What if?” and “Why not?” and “How come?”

I’ve learned this is a solid strategy for leading a team, and planning to fail; help your team identify the risks, and prepare them for the many doors, corners, and hallways they will encounter on the mission. You have to trust your team, and believe in them just as they need to trust and believe in you. You have to check your ego, keep the plan simple, prioritize and execute, and decentralize command by empowering and enabling your team leads.

Ask questions, challenge the team and encourage them to do the same with you. Give them a safe place to lean into. Engage them in the planning, and make sure they understand the big WHY of the objective. No question or detail is too small.

Failure is Not an Option

If you don’t do these things and do them well, failure is not just an option but probably your most likely outcome. Make the decision to depend on your team, but also provide the leadership and mentoring they need. Failure is not an option is a metaphor for making sure your team is prepared for any doors, corners, or hallways, and that they are energized, empowered, and enabled to cover and move, and believe they can overcome ANY obstacle.

When somebody asks me what my plan B is, I tell them, "make sure plan A works."

Doors and corners, doors and corners…