A review of The Musk Way by Alejandro Sahuquillo, and what I’ve learned from bringing these ideas into practice.
Let’s get this out of the way: Elon Musk is polarizing. We know. We’ve even received complaints for sharing content connected to him.
I get it. There are real reasons to be critical. But here’s the thing. Tesla and SpaceX are among the most remarkable engineering organizations of our time. If we refuse to study how they work because we dislike the person at the top, we’re choosing to learn less. Not learning, not experimenting, not taking inspiration from both failures and successes, that’s what keeps many organizations stuck.
You can separate the person from the principles. In fact, you have to, if you want to learn from any complex, imperfect leader in history. And that’s exactly what this book makes possible.
You can approach books about Musk and his companies in two ways. If you want to understand the person, read Walter Isaacson’s biography. It covers his contradictions, relationships, and how his temperament shapes decisions. It’s compelling and human.
But if you’re looking for something you can actually use in your own work, Alejandro Sahuquillo’s The Musk Way is the better pick. It’s less about the man and more about the operating logic behind Tesla and SpaceX. The principles that make those organizations move at a pace that most companies can only talk about.
That difference matters. Because the principles are transferable. The personality is not.
Researched, not just asserted
One of the things that makes this book unique is that it’s built on evidence. Sahuquillo draws on a wide range of sources and interviews. The book is full of quotes from key people that bring the principles to life and reveal the story behind them. They also give a real sense of what it’s like to work inside these organizations.
This makes the book easy to read but still dense with insight. It’s not a fan book. It’s a study.
The core idea: learning speed is your real advantage
A key theme runs through the whole book: success comes from learning faster than others. Not just moving fast. Learning fast. That means shortening the loop between an assumption, a test, a result, and the next decision.
In product language: reduce cycle time. In complexity language: run safe-to-fail experiments, amplify what works, dampen what doesn’t.
This isn’t a new idea. But the book shows how Tesla and SpaceX have made it structural. It’s not just a value on a wall. It’s built into how they design, test, and ship. The whole system is optimized for learning speed, not for looking good in a meeting.
The Algorithm: the most practical takeaway
The book’s most useful framework is the five-step process often called Musk’s “Algorithm”:
- Make requirements less dumb
- Delete
- Simplify and optimize
- Accelerate
- Automate
The order matters. If you skip ahead and automate a bad process, you’ve just made your problems faster and harder to fix. If you optimize before you’ve deleted the unnecessary, you’re polishing waste.
This maps well to Lean thinking and flow theory: eliminate waste before optimizing, reduce batch size, shorten feedback loops. But the first step is the one I keep coming back to.
Make requirements less dumb.
That’s an invitation to treat every requirement as a hypothesis. Not a fact. Not a given. Something to be questioned.
A story about questioning requirements
I saw this play out with a team I worked with. They’d been handed a large requirements specification for becoming GDPR-compliant. It was detailed, thorough, and expensive. Following that solution would have cost around 20 million SEK.
But the team pushed back. They didn’t just accept the spec. They asked: What does the law actually require? Not the specification. The law.
They came back with an alternative proposal that fully met the legal requirements. Cost: 1 million SEK. Twenty times cheaper. Same compliance. Different thinking.
That’s “make requirements less dumb” in action. The spec wasn’t wrong. It was just one interpretation, treated as the only option. The team that questioned it saved the organization a fortune and delivered faster.
This kind of thing happens more often than we’d like to admit. Requirements harden into facts. Nobody questions them because they came from someone senior, or because they’ve been around for a long time. The Algorithm says: question them anyway. Especially those.
Simplicity as an operating principle
Another pattern that runs deep in the book is radical simplification. Fewer parts. Fewer interfaces. Fewer special cases. “The best part is no part” is not a design preference at SpaceX. It’s a strategy for cost, reliability, and speed.
This highlights something many product teams overlook. Unnecessary complexity is expensive in ways that don’t always show up in a budget. It shows up in coordination overhead. In longer meetings. In defects. In delays. In the cognitive load that slows everyone down without anyone noticing.
Delete before you optimize. Simplify before you accelerate. The book makes this case convincingly, with real examples from manufacturing and engineering.
Culture: merit over rank, with clear ownership
A big part of the “Musk way” isn’t technology at all. It’s culture.
The book describes a norm where anyone can question any decision, regardless of who made it. Ideas are valued on merit, not rank. This sounds like a nice principle, but it’s more than that. It’s a way of cutting through two problems that slow most organizations down.
The first is false alignment. Everyone nods in the meeting. Nobody actually believes in the decision. Work continues based on a fiction.
The second is decision latency. Questions get stuck in layers of approval. By the time an answer comes back, the context has changed.
The norms the book points to are direct: ask the uncomfortable questions early. Share bad news loudly and visibly. Communicate directly, not through chains of command.
But here’s the important nuance. “Question everything” only works when it’s paired with clear ownership and accountability. Without that, you get endless debate. The book shows that the best results come from combining open challenge with strong responsibility to decide, test, and deliver. Freedom to question. Obligation to act.
The intensity question
Some of the stories in the book describe extreme expectations. Long hours. Persistent pressure. High turnover.
The Agile community has long advocated for sustainable pace, and for good reason. Intensity can create urgency and fast results. But it also creates fragility. People burn out. Quality drops. Institutional knowledge walks out the door.
My take: keep the speed of learning. Don’t copy the speed of exhaustion. You can build a system that learns fast without grinding people down. That’s the design challenge worth solving.
Verdict
The Musk Way is a practical companion to Isaacson’s biography. While Isaacson helps you understand the person, Sahuquillo gives you the operating principles: question requirements, delete aggressively, simplify relentlessly, and design for fast learning.
Treat the book like a case study. Take the useful ideas and try them in your own context. As with any case study, don’t blindly copy. Run your own experiments. See what works in your system, with your people, in your reality.
If this intrigued you and you want to go deeper into how Tesla and SpaceX principles apply to product development, take a look at the JoeDX Agile SW&HW course — a hands-on program inspired by exactly these ideas.
Leave a Reply