I thought this was an absolutely masterful explanation of engineering design thinking. If I may, I would also like to add to this list another thing he mentioned: "each requirement must have a name attached to it."

I believe he was referring to the first step. And "Name" was really "a person" as opposed to "a department." This was his way of saying DRI all the way down to each individual requirements, to force someone to be accountable for it. His example was that SpaceX interns previously listed requirements, that were later assigned to a department (e.g. avionics), and when prompted, no one in that department really knew why it was there.

Two things I took from that interview:

* the quip about people spending a lot of time to optimize something unnecessary,

* the quip that you must be wary about recommendations made by smart people, because you will tend to trust smart people too much and they can still make mistakes.

Also leadership through humbleness and vulnerability: "I myself made that mistake, I followed the process exactly backwards and wasted a lot of time."

Also leadership by storytelling. Don't say what you want, tell a story that shows people what you want, so they can envision themselves doing what you want.

"If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted."

I am struggling to understand this one.

Is he saying that you should remove parts on a routine basis, like a "remove parts/processes" meeting every month and then re-adding them back in once you find they're needed.

Or is he saying when you get a list of requirements, remove parts/processes related to those requirements and then re-add them once you find they're needed?

Or is it something else entirely?

He’s talking about physical parts and manufacturing processes. For example laser etching a part number might might not be worth it. If nobody can justify why it’s needed then why not skip it.

Got it, thank you!

Awesome video and thanks for the list, I was just going to write that down and you saved me a job.

Tim Dodd's website also has an article version of the video with a more detailed summary: https://everydayastronaut.com/starbase-tour-and-interview-wi...

> Musk overviewed his five step engineering process, which must be completed in order:

> 1. Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. He notes that it’s particularly dangerous if someone who is smart gives them the requirements, as one may not question the requirements enough. “Everyone’s wrong. No matter who you are, everyone is wrong some of the time.” He further notes that “all designs are wrong, it’s just a matter of how wrong.”

> 2. Try very hard to delete the part or process. If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted. Musk noted that the bias tends to be very strongly toward “let’s add this part or process step in case we need it.” Additionally, each required part and process must come from a name, not a department, as a department cannot be asked why a requirement exists, but a person can.

> 3. Simplify and optimize the design. This is step three as the most common error of a smart engineer is to optimize something that should not exist.

> 4. Accelerate cycle time. Musk states “you’re moving too slowly, go faster! But don’t go faster until you’ve worked on the other three things first.”

> 5. Automate. An important part of this is to remove in-process testing after the problems have been diagnosed; if a product is reaching the end of a production line with a high acceptance rate, there is no need for in-process testing.

1a. tie requirements to a person not group