There is a five-step hierarchy for engineering work, and the steps must be done in order. Almost everyone does them backwards — automating first, accelerating second, optimizing third, and never questioning whether the thing should exist at all. Weinberg sharpens this: most people seize the first statement that looks like a problem and solve it as fast as they can — so the wrong thing being optimized is often not just the wrong solution but the wrong problem. The most common error of a smart engineer is to optimize something that should simply not exist.
The Five Steps
1. Make the Requirement Less Dumb
The requirements are definitely dumb; it does not matter who gave them to you. It’s particularly dangerous when they come from an intelligent person, as you may not question them. Everyone’s wrong. No matter what you are, everyone is wrong some of the time. All designs are wrong, it’s just a matter of how wrong. — Elon Musk
Every requirement must come with a name, not a department. You cannot ask departments — you have to ask a person. The person putting forward the requirement must take responsibility for it. Otherwise you end up with requirements that an intern randomly created two years ago, fossilized into process because nobody remembers why they exist.
This is paradigm-lock-in at the engineering level. Requirements that once made sense calcify into unchallengeable constraints. The more senior and intelligent the person who created them, the more dangerous they are — because intelligence grants an aura of infallibility that survives long after the reasoning has expired. The will to think is precisely the refusal to accept a requirement you do not understand, even when it comes from someone you respect.
2. Try to Delete Part of the Process
If parts are not being added back to the design at least 10% of the time, not enough parts are being deleted. — Elon Musk
The bias is always toward addition: “let’s add this part or process step in case we need it.” An “in case” argument can be made for almost anything. But a rocket trying to be the first fully reusable vehicle must run tight margins — and tight margins mean every component must justify its existence, not merely its potential utility.
The 10% rule is the diagnostic: if you are never adding back something you previously deleted, you are not deleting aggressively enough. Yegge tells the story of the fixed-gear bicycle: someone took the time-tested “solved problem” of bicycles, removed something, and wound up creating a new market. Deletion is not just cost-saving — it is a design move that can produce things that addition never could. The Theory of Constraints frames this as: any step not at the constraint is a candidate for removal. The OSS sabotage manual’s instructions — multiply procedures, demand three approvals where one would do — describe what happens when deletion never occurs. Every process step that survives unchallenged is a step that a saboteur could exploit.
3. Simplify or Optimize
The reason this is the third step and not the first step is because the most common error of a smart engineer is to optimize something that should simply not exist. — Elon Musk
This is the step most engineers treat as the first step, because the educational system trained them to answer questions, not to question them. Tell a professor “your question is dumb” and you get a bad grade. The school system produces engineers who will brilliantly optimize the wrong thing rather than ask whether it should exist.
The Expert Beginner is the pathological endpoint: someone who has optimized their local technique so thoroughly that questioning its existence becomes an attack on their identity. The Agile critique lands here too: Scrum optimizes ticket throughput without questioning whether the tickets should exist.
4. Accelerate Cycle Time
You are moving too slowly. Go faster. But do not go faster until you have worked on the other three steps first. Acceleration applied to a process full of unnecessary requirements and undeleted steps only makes the waste happen faster.
The Milo Criterion adds the user-facing constraint: even after optimizing the engineering process, the output must not exceed the rate at which users can absorb it. Acceleration is bounded by the slowest link in the full system — which often is not engineering at all.
5. Automate
Automation is the last step. The worst failure mode — which Musk admits making personally on the Tesla Model 3 battery line — is doing these steps backwards: automate, accelerate, simplify, then finally delete. You end up with automated complexity, fast waste, and elegant solutions to problems that should not exist.
The Ordering Principle
The hierarchy is not arbitrary. It follows a cost-of-error gradient:
- Automating the wrong thing locks the mistake into infrastructure that is expensive to change
- Accelerating the wrong thing amplifies waste proportional to speed
- Optimizing the wrong thing consumes engineering brilliance on problems that should not exist
- Failing to delete preserves complexity that compounds over time
- Failing to question requirements means every downstream step is building on a flawed foundation
Each step becomes cheaper to fix as you move up the hierarchy. Questioning a requirement costs a conversation. Ripping out automated infrastructure costs months. The ordering exists to minimize the total cost of being wrong — which you will be, because everyone is wrong some of the time.
Dimwit / Midwit / Better Take
The dimwit take is “move fast and break things — speed is everything.”
The midwit take is “optimize for efficiency — measure everything and improve the bottlenecks.”
The better take is that the highest-leverage engineering act is not building or optimizing but deleting — removing requirements, process steps, and components that should not exist. Every surviving unnecessary element is a permanent tax on everything downstream. The best engineers are not the fastest builders but the most ruthless questioners. They produce less because they delete more, and the system is better for it.
Main Payoff
The five-step algorithm is deceptively simple because every engineer will nod along and then immediately violate it. The violation is not a failure of understanding but a failure of incentives: questioning requirements is politically dangerous, deleting process makes people nervous, and simplification produces no visible output. The system rewards the engineer who adds a clever optimization to a process that should not exist — and punishes the engineer who asks “why do we do this at all?”
The algorithm is ultimately about the courage to subtract in a culture that only rewards addition. The person who deletes a requirement, removes a process step, or simplifies a system has produced invisible value — the hardest kind to claim credit for and the most important kind to create.
References:
- Elon Musk, interview with Everyday Astronaut on SpaceX’s design process
- Walter Isaacson, Elon Musk (2023)