No Plan B

Should you burn the ships?

The famous filmmaker Steven Spielberg said in an HBO documentary that he almost gave up wanting to be a director after watching David Lean’s epic “Lawrence of Arabia.” He said that after watching that film, the bar was too high. He recalled about that event, “I had such a profound reaction to the filmmaking, and I went back and saw the film a week later…I realized that there was no going back. This was going to be what I was going to do or I was going to die trying.” This attitude of having no backup plan or "burning the boats," which is a metaphor that signifies the act of committing fully to a new endeavor by eliminating the possibility of retreat, is a common refrain amongst entrepreneurs. Jeff Bezos when asked about a plan ‘B’ or a backup plan said, "I'm not a fan of plan B.”

I was thinking about this lately because I will describe myself as a “belts and suspenders” type of person. Sorry for all the metaphors but this one is used to express a conservative or double-checking approach to ensure safety or success. Maybe this quality was ingrained into me in pilot training but I think rather that I learned this approach working with software. There are seemingly infinite ways in which software can and often will fail. The cyclomatic complexity, or the number of logical paths through code, can be extraordinarily large making it incredibly difficult to test them all. Combine this with the extreme numbers of customers that many applications handle, and this leads to those seemingly rare edge cases being not so rare.

As we are all products of our experiences, I know how the pain of not having a plan B in some instances has made me realize how important they are. I’ve previously shared this story about a release that went horribly wrong at PayPal in the book Scalability Rules and it remains a great example of why I think we need plan B’s, backup plans, or at least some way to back out of situations.

In early October 2004, we decided it was finally time to break up our massive monolithic database at PayPal, so we rolled out release 24.0. We were determined to keep our competitive edge by supporting real-time, synchronous debit and credit transactions across accounts, something that had been core to our product from day one, even if it wasn’t typical in the rest of the payments industry. To make that work as we split the database, we chose to lean on the two phase commit (2PC) protocol to keep everything in sync across the systems. But 2PC is known for deadlocks and performance hits, and almost immediately, it turned into a nightmare. Even though we tried to limit how many accounts actually used 2PC, the system practically ground to a halt right after launch. Payment volumes fell through the floor, dropping to less than half of what we expected, and our users noticed fast. We spent three grueling days working around the clock, trying to fix it and keep our promise of real-time transactions alive, but the performance problems were just too big to get past. To make it worse, we’d always followed a “fix forward” mindset, deploying new code without any way to roll back if things went wrong. That approach had never really caused us issues before 24.0, but this time it made everything so much harder. The whole thing was so painful that on October 14th, the company issued a public apology to our customers. In the end, we had no choice but to rip out 2PC altogether, and within a couple of weeks, we put together a rollback plan for future releases so we’d never get stuck like that again.

So with such great entrepreneurs and wildly successful people saying they did not have a plan B and don’t even like the idea of one, how do I reconcile this with my experiences that not having backup plans can be devastating for businesses and customers? I think the answer is in the layer of abstraction. If we take Steven Spielberg, who said he was going to be a director or die trying, he didn’t say every film he made was going to be successful. Of the 33 films that he has made, for every Schindler's List, Saving Private Ryan, and ET, there are the 1941, Always, and Hook films. If you don’t recognize those last three it’s because they were not successful critically nor financially. The same thing with Bezos. The list of failed Amazon products is pretty long and includes the Fire Phone. I think the Microsoft phone was even more successful, which is saying a lot. Both of those folks, Bezos and Spielberg, had no plan B for their overarching goal (successful filmmaker/business) but they knew a layer below was likely filled with failures.

In the world of complex systems, particularly those involving software and large-scale technology, the idea of burning the boats can be alluring but incredibly risky. When you’re dealing with distributed systems, millions of users, and financial transactions, the stakes are far too high to proceed without a fallback. My experience at PayPal and beyond has shown me that software will always find a way to fail in places you never anticipated, and when it does, the costs can be catastrophic. It’s not about a lack of faith in the product or the mission, it’s about respecting the reality that even our best intentions and cleverest code will eventually hit unforeseen snags. Having a rollback plan, a “plan B,” is the only way to ensure we can recover without eroding customer trust or doing irreversible harm to the business.

I’ve come to believe that the tension between having no backup plan and always having a backup plan actually lives in the difference between vision and execution. Spielberg and Bezos weren’t talking about the details of how they executed on their dreams, they were talking about the unwavering commitment to those dreams themselves. There’s a big difference between saying “I will be a filmmaker no matter what” and saying “I’ll ship this new product without any way to back out if it doesn’t work.” The first is about long-term purpose, the second is about the messy, practical reality of making that purpose real day-to-day. As leaders, it’s our job to separate the two in our minds and in our organizations, unwavering vision, but flexible and humble execution.

I’ll admit, I didn’t always see this distinction so clearly. I struggled when I heard a successful entrepreneur say they had no backup plan. I bought into the idea that any backup plan was a sign of weakness or a lack of real commitment. I thought that if I truly believed in what I was doing, I shouldn’t even allow the thought of retreat. But experience, especially in the world of technology and complex systems, has a funny way of teaching that lesson. I’ve seen enough failures to know that no matter how much conviction you have, the reality is that things will go wrong. Users will be affected, and without a fallback, it’s impossible to course correct. That realization didn’t make me doubt the importance of unwavering vision or bold ideas, it simply taught me that real leadership is about being prepared for those inevitable missteps, not just hoping they’ll never happen.

While unwavering vision is essential for leaders, having no fallback plan in the messy reality of execution can be devastating. Experience has shown me that you can’t control every outcome, but you can always be ready to recover quickly and protect your team and your customers. Embrace this mindset and build in the flexibility to roll back and adapt, even as you chase the big, bold goals that drive you forward.