Elon Musk

01 Nov 2024

Book	Elon Musk
Author	Walter Issacson

Like him or not, Elon Musk is one of the greatest entrepreneurs in history.

Since entrepreneurs build businesses zero-to-one and products are mini-businesses, I think a lot of product wisdom can be gleaned from his approach to business.

These are some lessons I learned reading Walter Issacson’s biography of Musk.

Speed

Speed is the most important metric he optimizes for.

How fast he makes his teams move seems to be the primary reason for his success across so many areas.

Most teams do not put enough emphasis on this.

Unrealistic Deadlines

It’s extremely useful to set unrealistic deadlines.

Even if you don’t hit them, you motivate yourself and the team to figure out how to do stuff as fast as humanly possible.

At the very least you either (a) learn how to do it extremely fast/ effectively or (b) very quickly learn it’s not humanly or physically possible. Either way it’s a win.

Prioritization vs Iteration

An interesting side effect of speed is that it seems to make prioritization easier and/ or irrelevant.

I noticed there weren’t a lot of examples in the book where he and his team needed to discuss “priorities.” There was usually just one priority and the goal was to move as fast as possible on achieving it.

When you have a high cycle speed, you can also address issues extremely rapidly. You try something and if it doesn’t work you figure out another option. When you move fast, it matters less which option you do first because you can try many options iteratively in a short timeframe.

Singular Focus on the Problem and Vision

Elon is almost manically focused on the problems he’s working on and then using first principles to design a solution. He doesn’t allow him or his team to be bound to any conventions or rules, except for the laws of physics.

He literally had his team build a SpaceX rocket almost purely out of stainless steel.

This is incredibly powerful because you can move so much faster when you give yourself maximum flexibility on what the exact solution will look like.

It was also interesting to see how he would focus first on how to best solve the problem (e.g. engineering reusable rockets), and then work out how to monetize later (e.g. Starlink). Consistent with the startup advice: first build something people want, then figure out how to get them to pay for it.

Radical Simplification

Huge increases in speed can be also gained by radically reducing the number and complexity of “requirements.”

This is captured in his “algorithm”, which given his success is arguably the most effective process management framework in history. Although more applicable to assembly-line-type processes, I think it can be applied to products in general.

Elon Musk’s Algorithm:

1. Question every requirement and make a person own each one

   • Question everything.
   • Hold stakeholders accountable for the requirements they ask for.

2. Delete as many requirements as possible 

   • “If you’re not adding 10% back in, you’re doing it wrong.”

3. Simplify and optimize

   • Only optimize a feature that addresses a requirement after vetting it through the first 2 steps.

4. Accelerate cycle time

   • Only make a feature faster after simplifying it first.

5. Automate

   • Only invest in automation as a final step.

Who Not How

Related to Step 1 in Elon’s Algorithm (where he holds people accountable for their requirements), if something isn’t moving as fast as he wants, he’ll often approach whoever’s in charge and say “Do this in X timeframe or I’ll find someone else who will” (i.e. sets a deadline). Just like unrealistic deadlines, this can often have the desired effect in that either (a) the team moves faster and gets it done, or (b) he finds someone who can make the team get it done.

I find it interesting that Musk has this focus on “who” over “how.” You would think for an engineer type, he would almost exclusively focus on “how.”

What he probably realized at some point was adjusting the “how” isn’t enough if you have the wrong “who.” That’s because if something isn’t going well, it could be a thousand things that whoever’s in charge is not doing right.

What makes Elon’s particular approach rare is that most people aren’t willing to be an asshole and fire someone on the spot if they aren’t getting it done. (More on this below.)

There were a few examples where he overcorrected and fired people wrongly, but that may be a necessary side effect. High sensitivity requires taking a hit on specificity.

Effective Management and Caring

It’s hard to do all of the above and “be a really nice guy.”

I don’t believe to be a good manager you have to be an asshole, like it sounds like Elon Musk can be. But I agree you can’t be friendly as a manager and expect to be great. 

You can’t have friendly conversations when you hold people to high standards. However, this doesn’t mean you shouldn’t care. You just care at a different level.

Elon genuinely cares a lot about the problems he’s trying to solve, but since those problems are at a much larger scale than individuals (e.g. make humans multi-planetary), he doesn’t care about individuals or their feelings.

At some point in the book, he says something like “speeding up production is just about caring more.” This is related to “who” over “how” because if you find someone who cares more, then they’ll care enough to figure out how to get it done right.

Everyone cares about something, except most people tend to care about being liked or some other aspect of their own lives. As a manager, you need to encourage people to care as much about the mission/ vision/ problem as you do. You want them to care at a different level.

Extreme Crossfunctionality

Elon often stressed how important it was to have engineers produce/ manufacture the products they design. They shouldn’t design from their desk without understanding what it means for production. They needed to care about and appreciate downstream consequences, rather than just the designs themselves (which is sort of obvious when you think about it).

For software, this is equivalent to requiring designers to understand how their designs will need to be implemented, by building themselves or observing engineers building.

I love this approach because everyone upstream in the development process understand how the downstream effects of their decisions, and they can adjust/ address them as upstream as possible (i.e. at the “root cause”).

Risk, Being All In and “Burning the Boats” Strategy

Elon loves “burning the boats”, where there’s no way to turn back after committing to a decision. He rarely has a fall back option. He goes all in and that’s clearly taken a huge part in his success.

If you feel like you’re risking it all and have no option but to keep going, you’re have to work tirelessly to make it successful.