1. Make your requirements less dumb
As engineers we are often given a list of requirements from someone else. We just accept them and start trying to design. We trust that other people know what they’re doing in part because our entire educational career we could never question the premise of a problem. The teacher says “Solve this” and you solve it – you don’t get to say “This is a dumb question” (Unless you’re fine failing as I was with Prof. Dempsey in Calc 3)
Musk goes on to say that in order to allow people to question the requirements, there’s another rule that goes along with this one.
1.a All requirements must have a person associated with them, not a department.
You can have a reasoned argument with a person but try arguing with a “department” and you’ll soon find yourself in a Dilbert Cartoon.
2. Delete the part or process
If you are not occasionally (say 10% of them time) adding things back in, then you aren’t deleting enough.
3. Simplify or Optimize
The most common error of a smart engineer is to optimize a thing that should not exist.
Once you have less dumb requirements, and you’ve eliminated as much as you can from the design only then try and optimize what’s left. These first 3 rules are really trying to get at one problem. The problem of really smart engineers trying to optimize the system they’ve been given rather than thinking about things from base principles and then optimizing. We tend to jump to optimization.
4. Accelerate Cycle Time
Only once all the other steps are complete, only then should we then try and automate a process. Doing it this way unlocks a few really nice properties. Automation takes longer to setup and get working but pays dividends in the future. However, those dividends only come if you’ve automated the right thing.