Thinking tool: Musk's 5 step design process (question, delete, simplify, accelerate, automate)

Headshot of Adam Jones

Adam Jones

Elon Musk has a 5 step design process, first recorded in his interview with Tim Dodd.

A key focus is to eliminate work as much as possible, to avoid optimising or automating stuff that doesn't need to be there in the first place.

The five steps as a left-to-right chain: 1 make requirements less dumb, 2 delete, 3 simplify, 4 accelerate cycle time, 5 automate. Caption: the classic mistake is optimising something that shouldn't exist

Step 1: Make requirements less dumb

Your requirements are definitely dumb.

When handed requirements: question them.

Musk says they're most dangerous when they came from a smart person, because then nobody questions them enough. Make each requirement come with a person (not a department) who can explain why it exists.

In my own work I've often seen dumb requirements spawned from:

  • Misunderstandings. Someone will misinterpret or mishear something in a meeting, and suddenly create extra work. Similarly, people who don't invest in understanding customers or the environment enough might spawn requirements that end up disconnected from true customer need.
  • Mistakes. For example, I've seen someone get wires crossed between projects, and think that a legal requirement that applied to one project also applied to another. This was only caught later when we'd spent about $100,000 on the wrong thing.
  • Assuming a solution. Imagine wanting to know if your website's loading speed affects customer conversions. One team might tell another that we need to make the website much faster and do an A-B test, and suddenly the requirement of "test loading speed" has turned into "make website faster". But in fact, there are easier solutions, like making the website slower and seeing if this hurts customer conversions then extrapolating how making it faster might improve conversions. Ideally the requesting team would communicate the surrounding context, but in practice this often doesn't happen, so as an extra line of defence the teams receiving requirements should challenge them (especially if they come in the form of solutions).

Step 2: Delete everything

If you're not occasionally adding things back in, you're not deleting enough.

Before working on improving something, ask "should it exist at all?".

This complements step one. Where step one focuses on avoiding requirements that result in new unnecessary complexity, step 2 applies pressure to delete existing complexity.

I still occasionally catch myself thinking about how to optimise systems or processes without even considering whether the system is needed at all. When you end up so zoomed in on the detail, you don't stop to think about whether the larger system still makes sense.

Musk explains why he thinks this mistake is common:

Everyone has been trained in high school and college to answer the question. You can't tell your professor that the question's done, or you'll get a bad grade. You have to answer the question.

So everyone, without knowing it, has got mental straitjackets on, and works on optimising the thing that simply should not exist.

(Trying to delete everything might appear to go against accepting redundancy on first glance. But a redundant bet for an important, uncertain outcome can be genuinely necessary for increasing chance of success - so the answer to "should it exist at all" is yes!)

Step 3: Simplify or optimise the design

If you have confirmed you have real requirements and can't delete the thing, then you may simplify or optimise it.

Step 4: Accelerate cycle time

If you're moving too slowly, go faster.

A fast cycle time reduces costs: despite best efforts at applying the first three steps, often you'll find that your requirements weren't quite right, or assumptions about what you could delete, simplify or optimise were wrong.

Being able to produce something wrong quickly, realise this, and learn, is much better than spending a lot more time, materials or other resources in a huge batch of the wrong thing. Or worse, investing in automating production of the wrong thing!

Step 5: Automate

Finally, you can automate what you've done. But only after the steps above.

It is easy to do this wrong

A dark grey Tesla Model 3 photographed from the front three-quarter view on a sunlit road Somewhere under the floor of this car are fibreglass mats nobody could explain. (Photo: iMoD Official, CC BY 3.0, via Wikimedia Commons)

Musk gives examples of wasting time doing the steps backwards:

I have personally made the mistake of going backwards on all five steps multiple times. [...] Where I automated, accelerated, simplified, then deleted.

One example is the fibreglass mats on top of the Model 3 battery pack, in between the floor pan and the battery. It was at one point choking the battery pack production line. [...]

The first mistake was to try to fix the automation, make the robot move faster [...], and instead of spackling glue on the entire battery pack just put little dabs of glue [...].

So automating was a mistake, then accelerating was a mistake, then optimising was a mistake. And finally I said, "what the hell are these mats for?"

I asked the battery safety team, "what are these mats for? Are they for fire protection or something?". They said "no they're for noise and vibration". And I said "but you're the battery department". I then asked the noise vibration analysis team "what's this for", and they said "fire safety".

It was like being in a Goldberg cartoon. I actually feel like I'm in a Goldberg cartoon quite frequently!

This is part of my thinking tools series.