You can find the tour and interview, done by Everyday Astronaut, here. This is me mostly transcribing.

Elon’s Development Process

1. Make your requirements less dumb

   It does not matter who gave them to you. Especially if they come from a smart person, because you question them less. Don’t take things as gospel. No matter who you are, everybody is wrong some of the time.

   And whatever requirement or constraint you have, it must come with the name of a person, not a department. You can’t ask departments, you have to ask a person. That person must take responsibility for that requirement.

2. Delete a part or process step

   Try very hard to delete the part of process. This is actually very important. If you are not occasionally adding something back in, at least 10% of the time, you are not deleting enough. There is often a bias to add this part or process step “in case we need it” but you can make an “in case” argument for pretty much anything.

   Thats why the grid fins do not fold down. It’s a whole extra mechanism thats not needed. They simulated it and saw no difference. And it in case they do find out they need them, they can add them back in later.

3. Simplify or optimise

   This the third step, not the first step. Why? The most common error of a smart engineer is to optimise a thing that shouldn't exist. Why is that? Everybody is trained to do so. Convergent logic, you are trained to answer questions, you can’t say to your professor the question is dumb. Everybody has a mental straightjacket on, optimising the thing that should not exist.

4. Accelerate Cycle-Time.

   You are too slow. Go faster. But don't go faster until you did the other three things first. If you are digging your grave, don’t dig it faster. Stop digging your grave.

5. Automate

   Thats the final step.

I have personally made the mistake of going backwards on all five steps multiple times. Where I literally automated, accelerated, simplified and then deleted. – Elon Musk

Here is one examples to illustrate how not to go through this process:

Fiberglass Mats on the Model 3

At Tesla, they had these fiberglass mats on top of the Model 3 battery packs. The mats were a chokepoint in the battery pack production line. Musk described he was basically living on the production line trying to fix this. It was chocking the entire Model 3 production program.

Musk tried to fix the automation first, making the robot better, make it move faster, shorter paths, increase the torque, etc. So automating was a mistake, accelerating was a mistake, then optimising was a mistake. And finally he asked, what the hell are these mats for?

The battery safety team told him they are for noise and vibration, the Noise & Vibration team said they are for fire safety…you get the idea. So finally they tried a car with the figerglass mats and without, they put a microphone in both – and couldn’t tell the difference. In the end Tesla just deleted that step, bypassing a 2M$ robot installation.

This framework really stuck with me and I hope you find it interesting as well.

“For me it goes back to root cause solutions. Slapping a marketplace onto a market where all the actors are bad or its super low NPS doesn’t actually solve any of the underlying problems that cause pain for customers.

So you actually have to go down and vertically integrate everything to provide that full stack solution thats going to solve their problems. And a low NPS environment is a very easy way to identify that that is the right strategy as opposed to doing a marketplace or a platform “ - Chris Power (ca. minute 17:00)

Full Stack vs. Focus

End-to-end strategies always seemed like lazy thinking to me. If you don’t know how to win, you just say “we do it all and if we achieve this, then we get imaginary advantage x, y and z”. If… Focus seems so much harder to achieve and that much more desirable.

Just look at military strategy. It’s about shifting centres of gravity, blitz manoeuvres that focus on the weakest part of the enemy’s formation. Same thing in business. Put “more wood behind fewer arrows” as Snowflake CEO Frank Slootman puts it. And especially for startups the advice is always to go narrow, narrow, narrow.

Chris’s argument was prompted by the Keith Rabois framework for finding fragmented industries with low NPS and building full stack solutions for them (i.e. Opendoor). And it really resonated with me. It goes down to solve the issue by first principles, from the ground up, instead of layering on top. And it also reminds me of that quote from Napoleon, that “quantity has a quality of its own”.

This framework gives us a a trigger, a green flag, for when to think about using a full-stack strategy. And even if one decides against a such an approach, it should force us to have a good answer as to how we deal with the lows NPS / bad actor problem.

Chain-link Strategies

What Richard Rumelt1 in “Good Strategy, Bad Strategy” calls Chain-link Strategies seems to be related to this:

A system has chain-link logic when its performance is limited by its weakest subunit, or “link”. When there is a weak link, a chain is not made stronger by strengthening the other links.

Food for thought:

1. Where do you start? If you do follow an end-to-end, full-stack, chain-link strategy, what do you focus on?

2. Systems thinking really comes into play here. I like Alex Danco’s short section in “World Building” on this:

   If you want to change how a system works, and move the system into a new steady state that’s closer to your goal, sequential effort won’t do much. What you need is parallel effort: you need several different things to happen, all at the same time, for the system to actually move in the direction that you want and stay there. 

3. How does this interplay with the API model of companies as lego bricks, ready to be combined and remixed?

Thanks for reading this first edition of The Irregulars!