Somewhere in your process is a rule an intern made up two years ago, now run by a robot.
Elon Musk admits that on the Tesla Model 3 battery line he did everything backwards. He automated first, then sped things up, then simplified, and only at the end asked which steps should exist at all. The result was automated complexity and fast waste. Why would a smart engineer build in that order?
Because building in that order feels like progress, and the alternative feels like doing nothing. His correction is a five-step sequence that runs the other way: question the requirement, delete what you can, simplify or optimize, accelerate, and only then automate. The order is the whole point. Musk’s explanation for it: The most common error of a smart engineer is to optimize something that should simply not exist.
Start with the requirement
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
The practical rule is that every requirement must come with a name, not a department. A department cannot explain itself, but the person who puts forward a requirement can be made responsible 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.
Once the intern’s requirement has a name attached, the next step is to try deleting it, along with every part and process step it spawned. The bias always runs toward addition, “in case we need it”, and an “in case” argument can be made for almost anything. So Musk sets a test:
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 rule builds in its own counterweight. It assumes you will sometimes delete something that mattered, and treats that as the price of deleting enough. A process where nothing is ever added back is one where every step survives by default, the condition the OSS sabotage manual tried to create on purpose.
Why engineers optimize instead
Optimization comes third, and most engineers treat it as first, because the educational system trained them to answer questions rather than 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. Handed the intern’s requirement, they make it faster and cheaper, and their brilliance ends up protecting it.
The ordering follows the cost of being wrong. Questioning a requirement costs a conversation. Deleting a step costs a little nerve and an occasional add-back. Optimizing the wrong thing consumes engineering talent. Accelerating it amplifies the waste in proportion to speed. Automating it locks the mistake into infrastructure, and ripping that out costs months, the trap the Model 3 line fell into. Every step you take before questioning raises the price of the question.
That is why the highest-leverage engineering act is not building or optimizing but deleting — removing requirements, process steps, and components that should not exist. Yet the sequence is easy to nod along to and hard to follow, and the obstacle is incentives rather than understanding: questioning requirements is politically dangerous, deleting process makes people nervous, and simplification produces no visible output. The engineer who adds a clever optimization gets credit; the one who asks “why do we do this at all?” produces invisible value. Which leaves a question worth asking of any process you run: who, by name, asked for each step, and when did anyone last try to delete it?
References:
- Elon Musk, interview with Everyday Astronaut on SpaceX’s design process
- Walter Isaacson, Elon Musk (2023)