First-principles thinking and The Algorithm at Tesla, SpaceX

I've been reading a new biography of Elon Musk, by Walter Issaccson, that chronicled Musk's dramas and successes since PayPal's days to date. Aside setting the backstage behind dramatic headlines flooding the news in recent years (which I haven't watched), the biography put more light on a particular pattern in Musk's thinking, first-principles thinking. In my line of work, apply automation on current processes to drive efficiency, the stories of how first-principles thinking has been applied at Tesla and SpaceX hit home for me several useful lessons.

For those who are not familiar with first-principles thinking, it's a method of questioning and reasoning what you hear everyday. Too many times we outsource our thinking to someone else, not thinking twice about the information we receive. To reason any thing from first principles, we would need a lot of energy, time and other resources. But I like to imagine what would happen if we use first-principles thinking more in our work.

It is not an exaggeration to say that SpaceX was born because Musk was spit on during a negotiation to buy missiles. Using first-principles thinking, Musk calculated that it would cost 50 times more to build a midsize rocket than the raw materials using current manufacturing methods. That insight not only gave birth to a new business model but also led to a culture of "deleting" stuff in both Tesla and SpaceX. In particular, first-principles thinking has been encoded as the following algorithm.

First, question every requirement. Second, delete any part or process if possible. Third, simplify and optimize. Fourth, accelerate cycle time. And finally, automate. Note that automation comes last. Tesla paid a steep price for this lesson when the company spent a lot of resources automating a process that should have been deleted.

This anecdote took me by surprise, but it felt right; I like the thought of having more quality automation. Many projects came my way simply too complex or unreliable to take on, but I did anyway because I was young and eager to prove what I was capable of. Another reason I did not question enough was that I was often brought into the picture when all requirements had been scoped, either by my manager or the business analyst. It did not feel right to be an ass that question everything I heard or demand an explanation from business. The only thing that would feel right is to take every requirement as truths handed down from other department's perch.

But when I analyzed all major project failures, that behavior was precisely the root cause. First, I should have been part of the initial use case discussion. Understanding the business context of the proposed use case should be part of the agenda, if not the most important item in the agenda. Second, I should have taken more courage to slow down and challenge what I heard from my colleagues. This would run the risk of appearing awkward or being negative, but by delivering the message right, the upside would be worth the risks.

To be clear, I'm not advocating for going into the meeting and blatantly ask about "deleting" stuff (It would have been fun doing so in thought experiments, though). I also don't think it is a good use of limited brain power to exercise first-principles thinking on every projects at work. Practice and awareness are key. By practice, I mean practice choosing (1) when to use first-principles thinking and (2) how far your inquiry should go. By awareness, I mean being aware of (1) how your audience is perceiving your behavior or intention and (2) whether you have got the trust to "simplify and optimize".

A few months back, I inserted this question in every solution design documents I reviewed: "Explain what would happen if this process did not exist ?". Very often I see developers got this question wrong. I did not ask what they think the benefits of the planned automation would be. This is easy. What I asked is for them to imagine an alternative reality where the process did not exist.

I maybe asking for too much in a culture where automation and efficiency are highly rated, but here's my conviction: simplicity beats efficiency. And simplicity is achieved when you have nothing left to remove.