The Five-Step Algorithm for Redesigning Anything

Five steps, ordered by cost: the cheapest move first, the most expensive last. Most of us run them backwards, on our companies and on our lives.

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

The most powerful rocket ever flown has no landing legs.

Falcon 9 has four. They fold out in the final seconds before touchdown, and they work. So when SpaceX designed Super Heavy, a booster as long as a 747, the obvious plan was bigger legs for a bigger rocket. The early drawings had them.

Then somebody questioned the requirement. The booster has to come back to the launch tower anyway. That is where it gets lifted, restacked, and reflown, and the tower is already strong enough to carry the whole ship. So why should the rocket haul its own landing gear up to space and back? The legs were deleted before one was ever built. Two steel arms on the tower do the catching now, and the mass the legs would have cost flies as payload instead. Since October 2024, SpaceX has been catching skyscraper-sized boosters out of the air with the same tower that launched them.

To be fair, the physics helped. Falcon 9 cannot hover. Even a single engine throttled all the way down pushes harder than the nearly empty booster weighs, so it has to hit zero speed at exactly zero altitude and let the legs eat whatever error is left. Super Heavy is heavy enough that a few center engines, throttled down, can hold it in a hover and walk it sideways into the arms. A catch that precise was simply not on the table before. But notice the uncomfortable part: the constraint that created the legs had disappeared, and the requirement did not disappear with it. Requirements never delete themselves. Somebody has to ask.

That decision was not a stroke of genius. It was a checklist. SpaceX runs its designs through a five-step process engineers there can recite from memory. Musk calls it the algorithm. And the quiet genius of it is something almost nobody notices: the steps are ordered by cost. The cheapest, highest-leverage move comes first. The most expensive comes last. Run them in order and you spend the least to learn the most. Run them backwards, which is what most of us do by instinct, and you pour your most expensive effort into things you should have deleted for free.

Here is the whole thing. Save it. It works on a rocket, a company, and a life.

The five steps

1. Question every requirement. Before you improve anything, ask whether it should exist at all. At SpaceX, every requirement must come with a name attached. Not a department. A person you can go ask. The most dangerous requirements are the ones from smart people, because you question them less.

Ask: who set this requirement, and is it still mine?

2. Delete. Remove whatever survived step one but serves no one. The best part is no part. The test for doing this well is counterintuitive: if you never have to add anything back, you were too timid. Musk's rule of thumb is that about ten percent of what you delete should turn out to be needed after all. On Super Heavy, even the grid fins do not fold the way Falcon 9's do. A folding mechanism is a part, and the best part is no part.

Ask: what happens if I simply stop doing this?

3. Simplify. Only now, and only for what survived deletion, make it as simple as the job allows. Not simpler. Just no more complex than it needs to be.

Ask: what is the simplest version of this that still works?

4. Accelerate. Shorten the loop between trying something and learning whether it worked. Speed is wonderful. It also comes fourth for a reason: if you are digging yourself into a hole, the last thing you need is a faster shovel.

Ask: how could I get feedback on this sooner?

5. Automate. Last of all, build the machine. Make permanent only the thing that earned it, the thing that survived questioning, deleting, simplifying, and tightening.

Ask: is this stable and worth keeping, before I build something permanent around it?

Each step also has its own essay on this site, if one of them is where you are stuck: Don't Build an SLS for questioning requirements, The Best Part Is No Part for deleting, Why Your Life Won't Run Smoothly Until You Stop Trying for simplifying, The Weekly Retrospective for cycle time, and Don't Automate a Life That Shouldn't Exist for automation. This essay is the map. Those are the territory.

Why the order is the entire point

Each step costs more than the one before it.

Questioning a requirement is nearly free. It's a thought, a conversation, a line changed on paper. Deleting is cheap too, and it keeps paying you back for as long as the thing would have existed. Simplifying takes real engineering effort. Accelerating takes more. Automating is the most expensive item on the list, because now you are building and maintaining a whole second system whose only job is to run the first one.

So the order is not a style choice. It is a budget. You make the cheap, powerful moves first, and you earn the right to the expensive ones only after the cheap ones are done. You never spend automation money on something you could have killed with one honest question.

The expensive mistake almost everyone makes

We run it backwards.

The instinct, especially in capable people who love to build, is to optimize, to add, to automate. Those feel like progress. They look like work. The unglamorous front of the list, questioning the requirement and deleting the thing, gets skipped because it doesn't feel like building anything.

Musk says he has personally made the mistake of running all five steps in reverse, more than once. The checklist exists because even its author keeps catching himself going backwards.

Now look at your own week. You build an inbox system for newsletters you could unsubscribe from. You optimize a commute that one remote day would delete. You install an app to manage commitments you never actually chose. This trap catches technical founders and senior leaders hardest, because building is your strength and your identity. You are world-class at steps four and five. That is exactly what makes it so easy to never ask step one.

If you only do one thing

Do step one.

Question a single requirement you have been treating as fixed. Not because the other steps don't matter, but because everything downstream is built on top of it. Change a requirement and the change ripples through everything below. Optimize a requirement that should not exist, and all you have done is make the wrong thing more efficient.

The catch is that requirements in a life almost never come with a name attached. Be reachable at all hours. Move into management. Keep the house, keep the title, keep the pace. Ask who set these and the answer is usually a department: the industry, the family, some younger version of you. The algorithm says that is not good enough. Find the person. Often the person is you, ten years ago, solving a problem you no longer have.

So this week, take one thing you have been trying to optimize or automate, and run it through step one. You might decide to keep it, now as a choice instead of a habit. You might delete it entirely and skip steps two through five for free.

What is one requirement you have been optimizing for years without ever asking whether it should exist?

Frequently asked questions

Why are the five steps in this exact order?

Because each step costs more than the one before it. Questioning a requirement is a conversation. Deleting is a decision. Simplifying takes real work, accelerating takes more, and automating means building and maintaining a second system on top of the first. Running the cheap steps first means you never spend automation effort on something one honest question could have removed.

How is this different from “Stop Optimizing Your Life. Start Specifying It.”?

That essay walks the whole algorithm through one life, mine, including the astronaut requirement I had to rewrite. This one is the reference card: the five steps in one place, why the order is the point, and what each step looks like in flight hardware. Start with this five-step overview to understand how the algorithm works, then read “Stop Optimizing Your Life. Start Specifying It.” to see it applied to a real life.

Why did SpaceX delete Super Heavy's landing legs?

The booster returns to the launch tower anyway, and the tower is strong enough to carry it. Legs are mass, hardware, and maintenance the rocket would haul to space and back on every flight. Super Heavy can also hover, which Falcon 9 cannot, so a precise tower catch became possible. The requirement “a rocket needs legs” came from an older constraint, and once that constraint disappeared, the legs went too.

What does it mean that a requirement should come with a name?

At SpaceX, a requirement must trace to a person who owns it, not to a department, because you cannot ask a department why. Life requirements almost never pass this test. Be reachable at all hours, move into management, keep the pace: ask who set these and you usually find an industry, a family, or a younger version of you. Finding the actual person, even if it is past-you, is what makes the requirement questionable at all.

Which step should I start with?

Step one, on a single requirement. It is the cheapest move with the largest downstream effect, because every other step only operates on what survives it. Take one thing you have been optimizing or automating and ask who set it and whether it is still yours. Everything else in the algorithm waits behind that question.

If you want to watch the whole algorithm run on one life, including the astronaut requirement that had to be rewritten, read Stop Optimizing Your Life. Start Specifying It. And if you want help finding the requirement to question first, the Essential Self Diagnostic is 15 questions and takes about 60 seconds.