Elon Musk’s 5-Step Algorithm

During a 2021 tour of SpaceX’s Starbase, Elon Musk explained to Tim Dodd the five-step process he tries to apply “rigorously”: make the requirements less dumb; delete the part or process; simplify or optimise; accelerate cycle time; and automate. These are not five independent suggestions. They are an order of operations. Each step earns the right to proceed to the next, and each prevents us from making an earlier mistake faster, cheaper, and more permanent.

The order is the method: question, delete, simplify, accelerate, automate.

1. Make the requirements less dumb

A requirement is any claim that something must be done in a particular way: a product specification, a policy, an approval, a deadline, a meeting, or an assumption about what success looks like. Musk’s starting premise is that every requirement is at least partly wrong, regardless of who supplied it. Indeed, requirements from intelligent or senior people may be the most dangerous, because everyone else is less willing to question them.

Attach every requirement to a named owner, never merely to “Legal”, “Safety”, “Finance”, or “the department”. That person must be able to explain the evidence behind it and own the requirement from conception to production and beyond. Questioning a requirement does not mean ignoring a law, a safety constraint, or the laws of physics. It means locating the real source and testing whether the requirement says what people assume it says. Otherwise an organisation can spend years answering a question that nobody can defend.

2. Delete the part or process

Once the requirements have been challenged, remove whatever does not need to exist. The “part” might be a component, feature, report, approval layer, standing meeting, hand-off, rule, or entire initiative. Deletion comes before simplification because the simplest version of an unnecessary thing is still unnecessary.

Musk’s boundary test is deliberately uncomfortable: if you do not later have to restore roughly 10% of what you removed, you probably did not delete enough. The point is not reckless cutting. It is to overcome the powerful “just in case” bias that causes systems to accumulate weight. A controlled deletion creates evidence: what proves necessary can be restored; what nobody misses has lost its right to remain.

3. Simplify and optimise

Only now should we improve what survived. Simplification removes hand-offs, exceptions, interfaces, decisions, and dependencies. Optimisation then makes the remaining system cheaper, safer, clearer, or more reliable.

This ordering matters because intelligent people are particularly good at solving the problem placed in front of them. That strength becomes a weakness when the problem itself is wrong. We can build an elegant workflow, perfect a report, or tune a machine that should never have existed. Complexity also creates attachment: the more ingenuity we invest in something, the harder it becomes to delete.

4. Accelerate cycle time

After the system is necessary and simple, make it move faster. Cycle time is the interval between acting, receiving real feedback, and correcting course. Shorter cycles mean smaller batches, earlier evidence, and less time spent moving confidently in the wrong direction.

This is not an instruction to hurry indiscriminately. Accelerating before the first three steps merely increases the throughput of waste. The common failure is to confuse activity with progress: more meetings, faster approvals, or more output can all make a bad process consume resources more quickly. Speed becomes valuable only after the work has earned its place.

5. Automate

Automation comes last. Software, machines, and AI make a process repeatable at scale. That is precisely why they are dangerous when introduced too early: they encode assumptions, conceal unnecessary steps behind a clean interface, and multiply defects as efficiently as they multiply value.

Automate only when the requirement has a defensible owner, deletion has found the minimum viable system, the remainder is simple, and the feedback loop is fast enough to reveal errors. Automation is a multiplier; it is not a substitute for judgement.

Why the order is so powerful

Each step changes the object inherited by the next. Step one tests whether we are solving the right problem. Step two finds the smallest system capable of solving it. Step three makes that system intelligible. Step four makes learning from it faster. Step five scales it. Reverse the order and automation hardens the waste, acceleration spreads it, and optimisation makes everyone more attached to it.

Musk’s own warning is that he has repeatedly run all five backwards: automating, accelerating, and optimising before finally asking why the thing existed. That is the algorithm’s most important common failure mode. Others follow from it: anonymous requirements that nobody owns; timid deletion that removes only the obvious waste; simplification that merely tidies complexity; speed pursued without faster learning; and automation used to avoid making a hard decision.

The sequence applies well beyond engineering. In business, run it against a product, committee, report, or operating process. In life, run it against the inherited requirements around status, career, possessions, and what a successful week is supposed to look like. Before asking how to do something better, faster, or automatically, ask the harder question: should it exist at all?