The doctrine rests on first principles thinking. If you're reasoning by analogy (the default), you'll keep the parts that "everyone else has" — bloat becomes invisible. First principles forces the question "what does physics actually require?" — and the answer to that is almost always smaller than what we currently have. The deletion concept is what first principles looks like in product/process terms.
The doctrine in operational form, from Walter Isaacson's biography of Musk (2023). Verbatim from the user's Zotero highlights of Isaacson (item VMZZ3I2I, annotation BVEFYCGA, page 338):
"I became a broken record on the algorithm. But I think it's helpful to say it to an annoying degree."
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... 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.
2. 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.
3. 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.
4. Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted.
5. Automate. That comes last. 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.
The critical paragraph in step 2: "if you do not end up adding back at least 10% of them, then you didn't delete enough." This is the operational spec for forced reduction. It says: if you delete and everything still works, you under-deleted. The 10% re-add is the proof that you went past the line.
The implicit correspondence to people/rick rubin: Musk says "delete 100%, add back ≥10%." Rubin says "force to 40%, add back to 70%" (i.e., delete 60% of a notional 100%, re-add 30%). Both treat the 10-30% re-add as evidence you deleted the right things, not as a failure mode. The variance is in how aggressively to overshoot.
From Jorgenson's Book of Elon (item H3C96IPI, annotation LRS5VC2Z, page 135):
"The most common mistake of smart engineers is to optimize a thing that should not exist."
This is the deletion concept in its most compressed form. The point is not that engineers are bad at their jobs — it's that they apply the wrong move (optimize) to a stale object (something that should have been deleted). The most common engineering failure is not "didn't optimize well enough" but "optimized the wrong thing." Forced reduction is the discipline that prevents this.
From Isaacson, page 340 (annotation ZKXJGPP7); also in Jorgenson, page 56 (annotation IV66VEEE):
"The only rules are the ones dictated by the laws of physics. Everything else is a recommendation."
This is the why behind the deletion concept. If you take physics as the only hard constraint, then every other rule — every requirement, every process, every part — is a human choice that can be unchosen. The doctrine isn't "be minimalist for aesthetic reasons." It's "everything is removable because nothing is physics-constrained." Forced reduction is what you do once you've internalized the axiom.
"If you have 100% and know you want 70%, instead of whittling down that 30 to get to 70, I'd say reduce it to 40%… force yourself to get to 40%. And then add back what's needed to get to the 70." — David Senra, "The Simple Genius of Rick Rubin" (May 2026), 16:34
Rubin's frame is from the rebuild side: kill most of it, then re-introduce only what matters. The mental motion is: overshoot the cut, then earn the add-back.
"The best part is no part." — Elon Musk
"Delete, delete, delete." — Musk's Step 2 of The Algorithm
Musk's frame is from the cull side: start with the assumption that everything is non-essential, then defend any retention. The mental motion is: justify the keep, not the cut.
Both arrive at subtraction-as-discovery. The practical difference is which frame is faster for which kind of work:
| Situation | Better frame | |---|---| | Shipping a v1, spec is bloated | Musk — pure cull is faster than rebuild | | Finding the irreducible core of something that already exists | Rubin — rebuild is more honest about what survives the cull | | Deciding which of 10 features to keep in v1 | Musk — defend retention | | Redesigning a mature product / system | Rubin — overshoot, then re-add the things that turn out to matter | | When ego is blocking ("I love this part") | Both work; Musk cuts faster, Rubin teaches you something |
When reducing, the question is not "what do I cut?" — it's "what would I add back?" A reduction that can't survive a re-introduction challenge was already over-reduced; a reduction that survives was probably under-reduced.
Rick Rubin side:
Elon Musk side:
VMZZ3I2IH3C96IPIUser's synthesis:
<!--- gbrain:facts:begin --> | # | claim | kind | confidence | visibility | notability | valid_from | valid_until | source | context | |---|-------|------|------------|------------|------------|------------|-------------|--------|---------| | 1 | User has a concepts/forced-reduction family in their knowledge graph, linked to Rubin's forced-reduction frame | fact | 0.7 | private | low | 2026-06-19 | | mcp:put_page | | | 2 | Has a concept entry 'concepts/forced-reduction' that connects to Thiel's monopoly framework | belief | 0.85 | private | medium | 2026-06-27 | | mcp:put_page | | <!--- gbrain:facts:end -->