The Algorithm: Question, Delete, Simplify, Accelerate, Automate
Make the requirements less dumb, delete what you can, and only then simplify, speed up and automate — in that order.
To an executive
Money is often spent speeding up and automating work that should never have existed. Questioning requirements and removing steps first saves more than optimising them.
To an engineer
Work in order: challenge the requirement, delete the part or step, then simplify, speed up and automate. Don't automate something you should have removed.
The idea
During a 2021 tour of SpaceX's Starbase with Tim Dodd (the Everyday Astronaut), Elon Musk described the five-step process he applies to engineering problems, and stressed that the order matters:
- Make the requirements less dumb. Every requirement is somewhat wrong, especially those from smart people, because people question them less.
- Delete the part or process step. If you are not occasionally adding back some of what you deleted — he suggested about one in ten — you are not deleting enough.
- Simplify or optimise what is left.
- Accelerate the cycle time.
- Automate.
Musk said his most common mistake was doing these backwards: automating, speeding up and optimising things that should have been deleted.
Why it works
The cheapest component is one that does not exist. Every part or step removed also removes its cost, failures and maintenance.
Order prevents waste. Optimising or automating a step that should not exist locks in the mistake and makes it harder to remove.
Named owners keep requirements honest. Musk insisted each requirement come from a person, not a department, so someone can be asked why it exists.
Where it applies
- Design reviews, especially of systems that grew by accretion.
- Migrations, where it is tempting to rebuild everything the old system did.
- Process and pipeline work, before any automation project.
How to apply
- Trace each requirement to a person and ask whether it is still needed.
- Delete boldly, then watch for the few things you need to add back.
- Simplify what remains, then shorten the cycle time.
- Automate last, once the process is right.
Example scenario
A team planned to automate a twelve-step release checklist. Before writing scripts, they traced each step to its owner. Four steps existed for systems that had been retired, and three duplicated checks the pipeline already did.
They deleted seven steps, simplified the rest and automated only what remained. The release took a fraction of the time, and the automation was much smaller than planned.
Questions to ask
- Who, by name, asked for this requirement, and is it still right?
- What can we delete entirely before we try to improve it?
- Are we about to optimise or automate something that should not exist?
When not to use it
- Safety and regulatory requirements, which may look unnecessary but exist for reasons you must verify before deleting — see Chesterton's Fence.
How it misleads you
Aggressive deletion without understanding why something exists removes safeguards along with waste. Ask why first, and keep deletions reversible where the cost of being wrong is high.
Further reading
Last reviewed · Suggest an improvement