Elon keeps it simple
Lessons from SpaceX, Starlink, and SolarCity
Want to learn from the most successful businessman of the century, but don’t want to get distracted by the politics and drama? Get Walter Isaacson’s Elon Musk as an ebook and search “simpl.” The 688-page canon becomes a thin manual on simplicity with fifty-one detailed examples.
Or just keep reading =]
How Elon protects simplicity
Elon created “The Algorithm” as a playbook to accomplish great things quickly at low cost. It goes like this:
Question every requirement. Requirements are recommendations. The only immutable ones were those decreed by physics.
Delete any part or process you can. You may have to add them back later. In fact, if you don’t add back at least 10% of them, then you didn’t delete enough.
Simplify and optimize.
Accelerate cycle time. In other words, “Go faster.”
Automate.
Remove, simplify what remains, then automate the process. It seems trite in the abstract, but a few examples will show how radically committed Elon is to this philosophy in practice.
During the early Paypal days, opening a financial account required the user to fill out long forms and hand over their SSN and address. Elon rewrote his site to get the fewest number of keystrokes to open an account by eliminating those forms and even the requirement to have a username (using email as the userid).
When Starlink’s satellites became too bulky and expensive to manufacture, Elon fired the leaders and led marathon meetings to challenge every little requirement. A rat’s nest of parts was turned into a simple flat satellite, and costs decreased by orders of magnitude.
Life got way easier because we culled those parts. I was too chicken to propose that, but Elon made us try it.
— Mark Juncosa, Starlink
When SolarCity’s panels lagged, Elon fired the leaders and eliminated the requirement that they must work around every vent and chimney pipe. Instead, they decided to shear them off and put the panels on top. The 240 roof parts were halved. The website was simplified to offer just three roofs: small, medium, and large.
When SpaceX’s Raptor engine proved incapable of a Mars mission, Elon instructed his team to focus on a lean design, one reminiscent of a gnarly post-skinned cat. He suggested some extreme ideas, like deleting the whole gas manifold and booster skirt. Then he emphasized his commitment to leanness with a flurry of emails.
We are on a deletion *rampage*!!
Nothing is sacred. Any remotely questionable tubes, sensors, manifolds, etc. will be deleted tonight. Please go ultra-hardcore on deletion and simpli cation.
Takeaways for software engineers
There’s a clear pattern throughout the book: When Elon sees a bottleneck, he removes rather than adds. Instead of adding more employees and materials, he fires people and removes parts.
This instinct is worth appreciating for us engineers, who have gotten used to adding with impunity. When a senior engineer imports a library, adds a framework, and integrates with a third-party, no one blinks an eye. Code is cheap, and it’s only getting cheaper.
But just because adding lines of code is easier than adding rocket ship parts doesn’t mean it’s free. There is a cost to every abstraction. For us, that cost is time. It takes time to dig through convoluted business logic, to wait for long CI runs to finish, and to tiptoe around a brittle part of the codebase.
When things become bloated, slow, or pricey, we should resist the urge to optimize and instead question whether we need the thing in the first place.
Removing abstractions, imports, and requirements will poke some egos, but so will becoming a team that’s incapable of shipping anything good.
More
Elon Musk, Walter Isaacson (amazon.com)
How Elon Works, Founders Podcast (youtube.com)