The Safest Rocket Never Launches

For founders and senior leaders: the waiting that protects you and the waiting that is quietly killing the thing can feel identical from the inside. Here is how to tell them apart.

By Peter Plötner. Aerospace engineer and Wayfinder Life Coach. More about Peter →

The only rocket with a zero percent chance of failure is the one that never leaves the pad. And that one has already failed.

There is no such thing as a launch without risk. You cannot engineer it away. The closest you get is a vehicle so wrapped in caution, so loaded with checks and reviews and reasons to wait, that it never flies. That is not a safe rocket. It is a failed one. It just fails quietly, on the ground, where nobody has to watch.

If you have built a company, or a career, or a senior position, you already know this feeling, even if you have never named it. The decision you keep not making. The pivot you will not commit to. The hard conversation you keep restructuring instead of having. It feels responsible to wait. It feels like diligence. But a thing that never moves is not being kept safe. It is quietly failing on the pad.

Real engineering is never about eliminating risk. It is about deciding which risks are acceptable, and then flying. The teams that succeed are not the ones who avoid all danger. They are the ones who know the difference between a risk worth taking and a risk worth refusing, and who launch once they have done the math.

I learned this the hard way, and not from a rocket. I learned it from a project that would not move, and from what I eventually understood about myself inside it.

The project that never flew

A few years ago I spent a long time on a project that simply would not progress. I will keep the details vague, because they are not the point and the people involved are real. What matters is the shape of it.

I worked alongside two colleagues whose goals had been set, by the organization, against mine. We were all doing what we had been asked to do. The trouble was that what I had been asked to do and what they had been asked to do pulled in opposite directions, and the safest path for everyone involved was to not move at all. Any real step forward carried some risk, and the system around us quietly preferred no risk to any progress. So the project sat there. For a long time. As far as I know, it is still sitting there.

For most of that time, I tried to solve it the way an engineer solves things. Better structure. Clearer documentation. A cleaner breakdown of the problem. I assumed that if I could just organize the situation well enough, lay out the facts clearly enough, the right path would become obvious to everyone and we would move.

It never worked. And it took me an embarrassingly long time to understand why. It was not an engineering problem. It was a human one, and I was using the wrong tools on it.

Everyone thinks they are the good guy

Here is the thing I did not want to see.

From where my colleagues sat, they were right. They had been given different goals than me, and against those goals, their caution made complete sense. They were not villains in their own story. Almost nobody is. Nearly every person, in nearly every conflict, believes they are the reasonable one, and usually they have a real reason to.

I knew that in theory. Putting it into practice, genuinely standing in the shoes of someone whose values and priorities were very different from mine, was much harder than I expected. When someone sees the world the way I do, perspective-taking is easy. When their values are far from mine, I found I had a real wall there. I kept wanting them to be wrong, because it would have been simpler.

That wall turned out to be the most important thing the whole experience showed me. Not the project. The wall. The discovery that I was not nearly as good as I thought at understanding people who were not like me, and that this was a skill, not a fixed trait, something I could actually work on.

How high is this, really?

If I could tell an engineer stuck in a standoff like that one thing, it would be this. Go check your requirements first. All of them. The ones for your whole life, not just this project. Write them down and put them in order.

Because the standoff feels enormous when you are inside it. It fills the whole screen. But when I finally sat down and honestly listed what I actually wanted my life to be about, and ranked those things, the conflict at work dropped much further down the list than the space it was taking up in my head. It was real. It mattered. But it was not anywhere near the top of what I cared about, and I had been letting it consume energy as if it were.

That is what a requirements check does. It does not solve the conflict. It shows you the true size of it. And most of the things that are quietly wrecking us are far smaller, on the list that actually matters, than the room they occupy in our minds.

My own zero-risk move

Here is the part that took me longest to admit, and it is the reason the rocket metaphor is really about me and not about anyone else.

I kept trying to engineer the situation because engineering felt safe. It was my home turf. Restructuring the problem, clarifying the facts, making better documents, all of that let me feel like I was working hard on the conflict without ever doing the genuinely risky thing, which was to step into the messy, uncertain, human layer underneath it. To actually try to understand people I did not understand. To have the uncomfortable direct conversations. To sit in the discomfort of values I did not share.

Staying in the engineering frame was my version of the rocket that never launches. It felt productive. It felt safe. And it went nowhere, because the safe move was never going to solve a problem that lived entirely in the human layer I was avoiding.

The launch that mattered was at home

In the end, the situation did not resolve. I did. I stopped pouring myself into a launch that was never going to happen under those conditions. I put more of myself into my life outside work, I changed my own circumstances, and the whole experience pushed me much deeper into something I now care about enormously, understanding people. The dynamics between them. The reasons underneath the behavior. It is a large part of why I coach at all.

But the place it changed things most was not at work. It was at home. The hardest perspective to truly take is not a difficult colleague's. It is the perspective of the people closest to you, your partner, your children, precisely because you assume you already understand them. Learning to step into a viewpoint whose values differ from mine, without needing it to be wrong first, has done more for me as a husband and a father than it ever did for any project. That, it turns out, was always the top of my list. The conflict at work just happened to be where I learned the skill.

Two colleagues I once struggled with ended up redirecting my whole path. They showed me the exact edge of my own ability, the place where my engineering skills ran out and a completely different kind of work began. I would not have gone looking for that edge on my own.

If you are sitting on a launch right now, a decision, a pivot, a conversation, it is worth asking which kind of safe you are choosing. The safe that protects something real, or the safe that just keeps you on the pad because flying is uncomfortable. They feel identical from the inside. Only one of them is actually safe.

Try this week

Think of one decision or situation that has been sitting still for a while. Before you try to solve it, do two things.

First, the requirements check. Honestly list what your life is actually about, and rank it. Then ask where this thing really sits on that list. Not where it feels like it sits. Where it actually does.

Second, ask whether you are doing the safe version of working on it or the real version. Are you reorganizing, planning, and preparing, the things that feel like progress and risk nothing? Or are you doing the harder, riskier thing the situation actually needs?

The move that keeps you on the ground almost always feels like the safe one. Often it is the only real failure available to you.

So here is what I am genuinely curious about. What is the launch you keep not making, because staying on the ground feels safer than the risk of flying? And what would it cost you, in a year, if it never left the pad?

Frequently asked questions

What does “the safest rocket never launches” actually mean?

A rocket you never fly has a zero percent failure rate, and it has also failed completely, because the whole point was to fly. In a life or a company, the decision you keep deferring, the pivot you will not commit to, the conversation you keep restructuring, can feel like prudence. Often it is just a quiet failure on the ground that nobody has to watch. Not moving is itself a choice with a cost.

Isn't waiting sometimes the genuinely responsible call?

Yes, and that is the hard part: the protective kind of safe and the avoidant kind feel identical from the inside. The test is what the waiting is for. Real engineering does not eliminate risk, it decides which risks are acceptable and then flies. If the delay is buying you specific information that changes the decision, it is diligence. If it is buying you distance from discomfort, it is the rocket that never leaves the pad.

How does a requirements check help with a stuck decision?

It does not solve the conflict. It shows you its true size. When you honestly list what your life is about and rank it, the standoff that fills your whole screen often drops far down the list. Most of the things quietly wrecking us are much smaller, on the list that actually matters, than the room they take up in our heads. Sizing the thing correctly is what frees the energy it was eating.

What if the other people really are being unreasonable?

Almost everyone believes they are the reasonable one, and usually they have a real reason to. Colleagues given different goals than you are not villains in their own story; against their brief, their caution makes sense. This is not about deciding they are right. It is that wanting them to be wrong, because it is simpler, keeps you from seeing the actual shape of the problem, which is almost always human, not technical.

Why would an engineer be worse at this than most people?

Because the engineering toolkit is so good that it becomes a place to hide. Restructuring the problem and making better documents feels like hard work while risking nothing. It is its own zero-risk move. A standoff that lives entirely in the human layer cannot be solved from the engineering layer, no matter how clean the documentation gets. Perspective-taking across values you do not share is a trainable skill, not a fixed trait.

The requirements check in this essay is the first step of an engineering framework for a life. It starts in Stop Optimizing Your Life. Start Specifying It. And the goals that were set against mine, the constraints I never chose, are the kind of inherited hardware I write about in Don't Build an SLS. If you want a place to start, the Essential Self Diagnostic is fifteen questions that take about sixty seconds, a quick read on which parts of your life are still carrying their weight.