Musk engineering process

Elon Musk’s five-step algorithm for designing products and processes, stated on the Everyday Astronaut Starbase tour (2021) and used as an operating principle at SpaceX and Tesla. The order is the content — each step is a gate for the next:

1. Make the requirements less dumb — “your requirements are definitely dumb; it does not matter who gave them to you. It’s particularly dangerous if a smart person gave them to you, because you might not question them enough.” Every requirement must carry a name, not a department — a person who takes responsibility for it and agrees it’s still right (“this happened several times” — requirements left behind by interns, defended by nobody).
2. Delete the part or process step — the bias is always to add “in case we need it”; for a tightly-margined rocket, “in case” arguments are how you get nothing to orbit. Calibration: if you’re not adding things back in ~10% of the time, you’re not deleting enough.
3. Simplify or optimize — only now, and the reason it’s step three: “possibly the most common error of a smart engineer is to optimize the thing that should not exist.” School trains convergent logic — you must answer the professor’s question, never call it dumb — so smart people arrive pre-loaded with a “mental straitjacket” that optimizes what should be deleted. His example: a hypothetical genius optimizing an NTO/MMH upper stage — “you’re screwed” — the propellant is wrong, perfection is irrelevant (“the biggest loss is the perfect execution of unnecessary work”).
4. Accelerate cycle time — “you’re moving too slowly, go faster — but only after the other three. If you’re digging and you’re great, don’t dig faster; stop digging your grave.”
5. Automate — last, once the design is simple, necessary, and fast. (His Model 3 confessions: he did it backwards — “I automated, accelerated, simplified and then deleted” — e.g. fiberglass mats in the battery pack that got a robot to place a part that shouldn’t have existed.)

Transcript (verbatim, 13:29–17:26)

13:29 · I have a rule just implement rigorously is the sort of five step process. First make your requirements less dumb, your requirements are definitely dumb. It does not matter who gave them to you. It’s particularly dangerous, if a smart person gave you the requirements, because you might not question them enough.

13:50 · Everyone’s wrong, no matter who you are, everyone’s wrong some of the time. So mega requirements is less dumb, then try very hard to delete the part or process. This is actually very important. If you’re not occasionally adding things back in, you are not leading enough. The bias tends to be very strongly towards, let’s add this part of the process step in case we need it.

14:29 · […] you’ve got to delete the part or process step, it’s super important. And you can like hedge your bets. So that’s why the grid fins for example, do not fold down because that’s a whole extra mechanism that we don’t need.

16:00 · Whatever requirement or constraint you have, it must come with a name, not a department. ‘Cause you can’t ask the departments, you have to ask a person, and that person who’s putting forward, the requirement or constraint must agree that they must take responsibility for that requirement. Otherwise you could have a requirement that basically an intern two years ago randomly came up with, off the cuff and they’re not even have the company anymore.

16:56 · These things are often just way more silly than you think. Anyway, so step one, make your requirements less dumb. Step two, delete the part or process step. If you’re not deleting a part or process step, at least 10% of the time, basically if you’re not adding things back in 10% of the time, you’re clearly not deleting enough. And then only the third step is simplify or optimize.

17:26 · The reason it’s the third step is ‘cause it’s very common, possibly the most common error of a smart engineer is to optimize the thing that should not exist.

Sources

• Article capture: clippings/superengineer-net-blog-dfx-elon-musk-design-method.md — superengineer.net’s DFX writeup (Design for Excellence framing: DFM/DFA context for each step)
• Video capture (full transcript): sources/Starbase Tour with Elon Musk [PART 1 Summer 2021].md + clippings/t705r8ICkRw-transcript.md — Everyday Astronaut, 17-Jun-2021, algorithm at 13:29–22:10; the segment continues with the Falcon 1 NTO/MMH example (18:04–21:22) and step 4/5 with the Model 3 story (21:23–22:10)

Where it fits

• Steps 1–2 are the elimination ladder’s design-side twin: Performance engineering says “don’t do it / do it less” for compute; Musk’s algorithm says “question the requirement / delete the part” before any optimization exists — both order elimination first because optimization multiplies whatever it touches, including mistakes
• “Requirements must come with a name, not a department” is the accountability rule that keeps Golden repo CODEOWNERS-style gates honest — a gate owned by nobody rots
• Step 3’s diagnosis (convergent-logic training → optimizing what shouldn’t exist) explains why Agent tests and requirement-questioning matter more as agents get faster at executing wrong specs

Related: Performance engineering · Golden repo · Agent tests