Musk & The Algorithm
A few weeks ago, I finished reading Elon Musk by Walter Isaacson.
The book provides a fascinating look into Musk’s life and how he has been able to make industry-changing contributions in business and technology. It also raises an uncomfortable question: can you get rockets to orbit and accelerate the transition to electric vehicles without accepting some of the chaos that comes with Musk?
Isaacson captures this tension well in the final paragraph:
"Could you get the rockets to orbit or the transition to electric vehicles without accepting all aspects of him, hinged and unhinged? Sometimes great innovators are risk-seeking man-children who resist potty training. They can be reckless, cringeworthy, sometimes even toxic. They can also be crazy. Crazy enough to think they can change the world."
One of the most useful parts of the book is Musk’s “algorithm” for building deep-tech hardware products:
"1. Question every requirement. Each should come with name of the person who made it. You should never accept that requirement came from a department, such as from "the legal department" or "the safety department." You need to know the name of the real person who made the requirement. Then you should question it, no matter how smart the person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirement less dumb.
2. Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn't delete enough.
3. Simplify and optimize. This should come after step two. A common mistake is to simplify and optimize a part or a process that should not exist.
4. Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted.
5. Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and bugs were shaken out. "
The chapter ends with a line that summarizes the philosophy well:
“The only rules are the ones dictated by the laws of physics. Everything else is a recommendation.”
I found the algorithm useful because it captures something I have seen repeatedly in product development: most teams optimize too early and question too late.
Customer requests are inputs, not instructions. Requirements are assumptions. Features are costs until they create value.
The goal is not to add more or delete more. The goal is to understand what creates value, remove what does not, and only then optimize or automate.
That is why I liked the algorithm. It is not just a manufacturing lesson. It is a product development lesson.
I recommend the book.
