Elon Musk’s 5-Step Engineering and Problem-Solving Process

Elon describes a strict order of operations for designing systems, solving problems, or improving processes. The order matters a lot.

All requirements are suspect, no matter who created them.
It’s especially dangerous when a smart person created the requirement, because people hesitate to question it.
Everyone is wrong sometimes.
Every requirement or constraint must have a single named owner, not a department.
- You must be able to ask one person why it exists.
- That person must take responsibility for it.
Otherwise, you end up with rules created years ago by someone who may not even work there anymore.

This is critically important and heavily underestimated.
There is a strong bias toward adding “just in case” steps or components.
If you’re not adding things back in ~10% of the time, you are not deleting enough.
Many systems are far more complex than they need to be.
Example principle: If it doesn’t absolutely need to exist, remove it.

This is where many engineers go wrong.
People are trained to optimize whatever exists, even if it shouldn’t exist at all.
Engineers often optimize a bad question instead of questioning the question.
Never optimize something before asking whether it should exist.

Once you’ve:
1. Fixed bad requirements
2. Deleted unnecessary steps
3. Simplified what remains
Then, and only then, focus on speed.
Making things faster is easy compared to fixing bad structure.

Automation comes last, not first.
Automating a bad or unnecessary process just makes the mistake happen faster and more expensively.
Elon admits he has personally made this mistake many times.

Real-World Example: Tesla Model 3 Battery Pack

There were five glass fiber mats in the battery pack.
They were slowing down production and required a $2 million robot.
Elon first tried:
- Fixing the automation
- Speeding it up
- Optimizing the process
Finally, he asked: “Why do these even exist?”
- Battery safety team said: noise & vibration
- Noise & vibration team said: fire safety
Turns out:
- They did nothing measurable
- Removing them made no difference
Result:
- The mats were deleted
- The robot was eliminated
- A major production bottleneck vanished

Question everything, especially requirements.
Delete aggressively.
Don’t optimize garbage.
Speed and automation are powerful—but only after the fundamentals are correct.
Most complexity exists because no one asked, “Do we actually need this?”