That was so good I transcribed/transliterated it for my team:
Elon Musk’s Five Steps to Optimize:
- Question the Requirements
- Delete Parts or Processes
- Simplify
- Accelerate
- Automate
Quotes:
You want everyone to be a chief engineer. So, “everyone is a chief engineer” means that people need to understand the system at a high level to know when they are making a bad optimization. Like when we put immense effort into reducing engine mass but hardly any effort into reducing propellant residuals.
All designs are wrong, it’s just a matter of how wrong.
Transcript of Five Steps description:
What I’m trying to have us all implement rigorously is the five step process.
First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.
Then, try very hard to delete a part or process. This is actually very important. If you’re not occasionally adding things back in, you’re not deleting enough. The bias tends to be very strongly towards “Let’s add this part or process step in case we need it.” But you can basically make “in case” arguments for so many things. And for a rocket that’s trying to achieve, trying to be the first fully reusable rocket…you have to run at tight margins because if you don’t run tight margins you get nothing to orbit.
Whatever requirement or constraint you have must come with a name, not a department. Because you can’t ask the department, you have to ask a person. And that person who it putting forward the requirement or constraint must take responsibility for that requirement. Otherwise you can have a requirement that basically an intern two years ago randomly came up with off the cuff and they aren’t even at the company any more . . . these things are way more silly than you’d think.
If you’re not adding things back in at least ten percent of the time you’re clearly not deleting enough.
Only at the third step you simplify or optimize. The third step, not the first step. The reason it’s the third step is because its very common, its possibly the most common error of a smart engineer is to optimize something that should not exist. And you say why would people do that? Well, everyone’s been trained in high school and college that you’ve got to answer the question, convergent logic. So you can’t tell a professor “your question is dumb.” You will get a bad grade. You have to answer the question. So everyones basically without knowing it they’ve got a mental straightjacket on. They will work on optimizing the thing that should simply not exist.
Finally you get to step four which is accelerate cycle time. You are moving too slowly, go faster. But don’t go faster until you’ve worked on the other three things first. If you’re digging your grave, don’t dig it faster, stop digging your grave.
What does "make your requirements less dumb" mean? Make them more applicable? Make them more precise? Something completely different? Question them, but what is the flaw of "dumb" in a requirement?
I'll take a stab at answering this by paraphrasing Musk.
He said this 5 step process was inspired by the time they were trying to optimize part of the Model 3 production. There was a segment that was causing a lot of problems - the installation of some sort of foam or padding on the battery. I guess the glue wasn't adhering well between the metal of the car and the foam, or whatever I dunno, problems.
They tried all sorts of things to optimize the process, until eventually Musk asked, "what's this for?" and the Noise and Vibration team told him they weren't sure, probably for fire safety. The Battery team (the one that would institute a fire-related requirement) told him they weren't sure, it was probably for noise and vibration.
They built a car without the foam, tested it for noise and vibration against a car with the foam, couldn't tell the difference, and ultimately removed the part entirely.
So this story touches all 5 of the points, but on the point of "make the requirement less dumb" it means that whoever got the requirement in the first place should have asked "what is this for?" and should have tried to find another way to meet the requirement without needing foam (and in doing so would have found out that the requirement was BS in the first place).
I think the parent comment's story describes the concept really well. The below clip from "Pentagon Wars" describes some of the organizational dynamics that are another way to arrive at dumb requirements.
Does it refer to eliminating or deprioritizing requirements that are not core to the product? Removing "gold-plating" requirements? Or does it mean converting solutions/implementations disguised as requirements into actual requirements? Something I see a lot of in my role.
Elon Musk’s Five Steps to Optimize:
- Question the Requirements - Delete Parts or Processes - Simplify - Accelerate - Automate
Quotes:
You want everyone to be a chief engineer. So, “everyone is a chief engineer” means that people need to understand the system at a high level to know when they are making a bad optimization. Like when we put immense effort into reducing engine mass but hardly any effort into reducing propellant residuals.
All designs are wrong, it’s just a matter of how wrong.
Transcript of Five Steps description:
What I’m trying to have us all implement rigorously is the five step process.
First, make your requirements less dumb. Your requirements are definitely dumb. It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough.
Then, try very hard to delete a part or process. This is actually very important. If you’re not occasionally adding things back in, you’re not deleting enough. The bias tends to be very strongly towards “Let’s add this part or process step in case we need it.” But you can basically make “in case” arguments for so many things. And for a rocket that’s trying to achieve, trying to be the first fully reusable rocket…you have to run at tight margins because if you don’t run tight margins you get nothing to orbit.
Whatever requirement or constraint you have must come with a name, not a department. Because you can’t ask the department, you have to ask a person. And that person who it putting forward the requirement or constraint must take responsibility for that requirement. Otherwise you can have a requirement that basically an intern two years ago randomly came up with off the cuff and they aren’t even at the company any more . . . these things are way more silly than you’d think.
If you’re not adding things back in at least ten percent of the time you’re clearly not deleting enough.
Only at the third step you simplify or optimize. The third step, not the first step. The reason it’s the third step is because its very common, its possibly the most common error of a smart engineer is to optimize something that should not exist. And you say why would people do that? Well, everyone’s been trained in high school and college that you’ve got to answer the question, convergent logic. So you can’t tell a professor “your question is dumb.” You will get a bad grade. You have to answer the question. So everyones basically without knowing it they’ve got a mental straightjacket on. They will work on optimizing the thing that should simply not exist.
Finally you get to step four which is accelerate cycle time. You are moving too slowly, go faster. But don’t go faster until you’ve worked on the other three things first. If you’re digging your grave, don’t dig it faster, stop digging your grave.
The final step is automate.