LLM Book Knowledgebase

The Algorithm: Musk's Five-Step Engineering Process

8 min read

The Algorithm: Musk’s Five-Step Engineering Process

“The Algorithm” is Elon Musk’s five-step engineering and manufacturing methodology, developed through the construction of SpaceX rockets and Tesla cars and subsequently applied across all his companies. It is not merely a manufacturing checklist but a philosophy of design: a structured way of removing the layers of accumulated conventional thinking from a problem until only the physically necessary remains.

The Algorithm is one of the most practically actionable frameworks to emerge from Musk’s documented methodology. It can be applied to product design, organizational processes, software architecture, and any domain where complexity has accumulated through habit rather than necessity.

The Five Steps (Canonical Formulation)

From Elon Musk (Isaacson, 2023):

“1. Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from ‘the legal department’ or ‘the safety department.’ You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.

  1. Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn’t delete enough.

  2. Simplify and optimize. This should come after step two. A common mistake is to simplify and optimize a part or a process that should not exist.

  3. Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps.

  4. Automate. That comes last.”

Why Order Matters: The Core Insight

The counterintuitive power of the Algorithm lies in its sequence. Most engineering processes do steps 3, 4, and 5 first — which means they optimize, speed up, and automate processes that shouldn’t exist:

“A common mistake is to simplify and optimize a part or a process that should not exist.” — Elon Musk, Walter Isaacson

“The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.” — Elon Musk, Walter Isaacson

This is the lesson from Tesla’s initial automation disaster: Musk automated before deleting, which meant he built expensive, complex robotic systems that were later torn out. “We had to put a hole in the side of the building just to remove all that equipment.” The cost was enormous in time and money — far exceeding what careful deletion in advance would have required.

The sequence also implies a discipline about optimization:

“The most common mistake of smart engineers is to optimize a thing that should not exist.” — The Book of Elon, Eric Jorgenson

Smart engineers are most dangerous in step 3. Their instinct is to make things better — but better at the wrong level, optimizing within a flawed constraint structure rather than questioning the constraints themselves.

Step 1: Question Requirements — Especially from Smart People

The most counterintuitive instruction is to distrust requirements from smart people most:

“Requirements from smart people are the most dangerous, because people are less likely to question them.” — Elon Musk, Walter Isaacson

This is a claim about authority and social epistemology: we accept requirements less critically when they come from people we respect. But requirements from smart people are still contingent — still shaped by the circumstances, assumptions, and biases of the person who created them at the time they created them. A safety requirement that made sense in 2010 for a specific launch vehicle may not make sense for a different vehicle in 2023.

Musk’s instruction to attach a human name to every requirement is a bureaucracy-disruption technique: it forces people to think about why the requirement exists (because John Smith thought it was necessary at some point) rather than that it exists (it’s in the spec).

Step 2: Delete — And Expect to Add Back

The counterintuitive target in deletion:

“In fact, if you do not end up adding back at least 10% of them, then you didn’t delete enough.” — Elon Musk, Walter Isaacson

“If you’re not adding deleted things back in 10 percent of the time, you’re clearly not deleting enough. Somewhat illogically, people often feel they’ve succeeded if they are not forced to put anything back in.” — The Book of Elon, Eric Jorgenson

This reframe inverts the normal risk calculus. Most engineers are afraid of deleting things because they fear having to add them back — it looks like a failure of judgment. Musk argues the reverse: if you never have to add anything back, you haven’t deleted aggressively enough. The goal is to find the minimum viable structure, and the only way to find it is to overshoot on deletion and then restore what turns out to be necessary.

The corollary: “The best part is no part. The best process is no process.” Every part that doesn’t exist can’t fail, add weight, create misalignment, or generate maintenance costs.

Step 3: Simplify and Optimize (After Deletion)

“Simplicity is our mantra. It creates both reliability and low cost.” — The Book of Elon, Eric Jorgenson

“It’s easy to say ‘simplify,’ but it’s very difficult to do it.” — The Book of Elon, Eric Jorgenson

Simplification that precedes deletion is cosmetically pleasing but structurally inadequate — you’re organizing something that shouldn’t exist. Simplification that follows deletion is structurally powerful — you’re making the necessary elements as efficient as possible.

Musk’s tolerance window for variance in precision is telling:

“Precision is not expensive. It’s mostly about caring. Do you care to make it precise? Then you can make it precise.” — Elon Musk, Walter Isaacson

Step 4: Accelerate Cycle Time

This step is placed fourth deliberately:

“In early SpaceX, I told the team everything we did was a function of our burn rate… Every day we were slower to achieve our goals was a day of missing out on that revenue.” — The Book of Elon, Eric Jorgenson

But speed at steps 1-3 is not the goal. Speed at step 4 only — after requirements have been questioned, waste deleted, and the remaining process simplified — produces compounding returns without the false economy of accelerating the wrong things.

The related principle:

“The power of speed is underappreciated as a competitive factor. The real way you actually achieve intellectual property protection is by innovating fast.” — The Book of Elon, Eric Jorgenson

Step 5: Automate (Last)

Automation is the step with the highest capital cost and lowest reversibility. Applied last — after the process has been stripped to its minimum viable form — it produces maximum returns. Applied first, it locks in inefficiency at machine scale.

This is why Musk’s early Tesla mistakes were so costly: he built automation around a process that still contained unnecessary steps. When the process changed (as it inevitably did), the automation had to be rebuilt.

Broader Application

The Algorithm was developed for physical manufacturing but applies to any process involving complexity that has accumulated through habit:

  • Organizational processes: Question every meeting, every approval layer, every reporting structure. Who mandated this? Why? Delete the ones that don’t serve the ultimate goal. Simplify the remaining ones before adding coordination software.

  • Software architecture: Delete code before optimizing it. “The number of lines of code is not a figure of merit. I consider a large number of lines of code to be bad, not good. I would award one point for adding a line of code and two points for deleting a line of code.” — The Book of Elon

  • Strategic planning: Question the assumptions embedded in the strategy (step 1) before optimizing execution (steps 3-5).

Corollaries from the Same Sources

Musk’s supporting principles that extend the Algorithm:

Technical managers must have hands-on experience. “Managers of software teams must spend at least 20% of their time coding.” A manager who doesn’t understand what their team does cannot effectively question requirements or evaluate deletions.

All bad news loudly and often. “All bad news should be given loudly and often. Good news can be said quietly and once.” This is a feedback mechanism for steps 1 and 2: bad news about processes is the signal that something should be questioned or deleted.

Failure is acceptable; timidity is not. “If we’re not occasionally blowing up an engine on the test stand, we’re not trying hard enough.” The Algorithm requires bold deletion, and bold deletion will sometimes delete things that turn out to be needed. This is a feature, not a bug.

Backlinks