Question-and-Delete Engineering Algorithm
Kill the requirement and the part before you ever optimize them
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 4
- Confidence
- 82%
Musk's engineering algorithm front-loads deletion before optimization. Step one is to question every requirement and trace it to a named person, because a requirement owned by 'the legal department' can never be challenged. Step two is to try very hard to delete the part or the process outright, on the logic that the best part is no part and the best process is no process. Only what survives deletion gets simplified, and only then optimized. The payoff is that simplicity delivers both reliability and low cost: every part you combine or remove is fewer connections, fewer tolerances, fewer things that can fail. The framework directly attacks the most common mistake of smart engineers, which is lovingly optimizing something that should not exist at all.
Origin
Attributed to Elon Musk's five-step engineering process, described by Eric Jorgenson from Musk's public accounts and the Isaacson biography.
Core principles
- 01The best part is no part; the best process is no process
- 02Every requirement is one person's opinion, not a law of physics
- 03Simplicity delivers both reliability and low cost
- 04School trains you to solve the problem in front of you, never to reject it
- 05The most common mistake of smart engineers is optimizing something that should not exist
How to run it
- 1
Question the requirement
Challenge whether each requirement should exist. Attach it to the specific person who set it so it can actually be argued with, rather than treating it as fixed.
Pro tip If a requirement is owned by a department rather than a name, you cannot challenge it; find the name.
- 2
Delete the part or process
Try very hard to remove the part or process entirely. The best part is no part; the best process is no process. Deletion is the biggest lever.
Watch out If you never have to add at least some deleted parts back later, you did not delete aggressively enough.
- 3
Combine what remains
Merge parts that can be a single unit instead of two. Every combination removes fasteners, tolerances, and failure points downstream.
- 4
Simplify and optimize last
Only after questioning and deleting do you simplify and optimize the survivors. Simplicity itself buys reliability and cost, so optimization is the final, smallest step.
Pro tip Revisit the whole chain repeatedly as the design evolves.
In the wild
Building a car from 10,000 parts, every time two components can be combined it removes a part, and often the two screws that would have joined them. That means less tolerance stack-up and fewer things that can fall apart, because one unit is more robust than two connected units.
→ Fewer parts, lower cost, higher reliability from combination alone.
Common mistakes
Optimizing before deleting
Smart engineers instinctively refine a part rather than ask whether it should exist. Optimizing something that should be deleted wastes the most effort.
Treating requirements as physics
Requirements are opinions from people. Failing to name and challenge them locks in complexity that could have been removed at the source.
Is it for you?
Best for
Engineers, product builders, and operators fighting complexity and cost creep.
Not ideal for
Safety-critical steps where deletion introduces unacceptable risk without review.
From the transcript
“The most common mistake of smart engineers is to optimize something that should not exist”
“the best part is no part, the best process is no process. So, if something can be deleted, the product gets simpler. And simplicity, as…”
From the episode
The Wild Psychology of Elon Musk - Eric Jorgenson - #1082
Eric Jorgenson