19 ms·

Everyday Astronaut's walk and talk with Elon Musk where he attempts to explain his management process, starts at 13:30 of part 1: https://www.youtube.com/watch?

Everyday Astronaut's walk and talk with Elon Musk where he attempts to explain his management process, starts at 13:30 of part 1: https://www.youtube.com/watch?v=t705r8ICkRw&t=13m30s https://www.youtube.com/watch?v=t705r8ICkRw&t=13m30s Here's a rough summary: 1. Make requirements less dumb. 2. Delete part or process steps. If you're not occasionally adding things back (he says 10%) (ideally in improved versions), you're not removing things often enough. 3. Simplify, optimize, solve. Everyone's trained to jump to this because the educational process requires you to answer a question as posed, when often the question is dumb and shouldn't be dealt with as-stated. 4. Accelerate process 5. Automate Those tend to blur together at the edges. I'm sure if he formalized this and wrote it down for mass consumption it'd be presented differently, but it's his current mental model. Process testing - remove unnecessary in-process testing after production line debugging is done. Obviously there are nuances, he's not saying to do no in-process testing, but rather to remove testing which was intended to reveal information once that's already been collected and addressed. He cautions about false positives from in-process testing, and notes most testing can be done end of line with acceptable results. Finally, it's important to understand the context. The part about part/step deletion in particular, when things get added back 10% of the time, is not appropriate for all development processes. That would have to be adjusted a the specific product and market objective.

adolph 5y ago
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. The final step is automate.
- daveguy 5y ago
  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?
  - maroonblazer 5y ago
    I had the same question. 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. I see value in both exercises.
  - colordrops 5y ago
    Either there isn't a precise goal so the requirements are scattered, or there is a precise goal and the requirements don't match the goal.
  - actinium226 5y ago
    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).
RandomLensman 5y ago
Also note the things mentioned by him that happen kind of before/in parallel, i.e. costing and planning. Building high performance organizations really often is about the "mundane" stuff: - Planning processes - Assigning responsibility and putting incentives in place - Clear objectives with good KPIs

adolph 5y ago

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. The final step is automate.

daveguy 5y ago
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?
- maroonblazer 5y ago
  I had the same question. 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. I see value in both exercises.
- colordrops 5y ago
  Either there isn't a precise goal so the requirements are scattered, or there is a precise goal and the requirements don't match the goal.
- actinium226 5y ago
  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).

RandomLensman 5y ago

Also note the things mentioned by him that happen kind of before/in parallel, i.e. costing and planning. Building high performance organizations really often is about the "mundane" stuff: - Planning processes - Assigning responsibility and putting incentives in place - Clear objectives with good KPIs