Books — what I read and what I think about it.
I’m allergic to founder hero-worship. That’s exactly why I read “The Algorithm”: the subtitle promises a formula — and I wanted to know whether there’s a transferable method under the Tesla mythology, or just the usual “be a genius like Elon.” The answer: both. But the useful part is surprisingly sober.
What it’s about
Jon McNeill was President of Tesla — by the book’s account, the first of Musk’s direct reports to write a book at all. Sheryl Sandberg introduced him to Musk; McNeill had already founded and sold six companies by then. His headline number: during his tenure, Tesla’s revenue grew from $2B to $20B in 30 months — out of a production crisis that nearly killed the company.
The book distills that into “the algorithm” — Musk’s famous five steps — plus the culture required to make them stick, with case studies from Tesla, SpaceX, GM, and Lululemon.
What stuck with me
- The algorithm itself — and its order. Five steps: question every requirement → delete every possible step → simplify and optimize → accelerate cycle time → automate. The punchline is the order: automation comes last. Automate a bloated process and you cement the waste into software — only faster and more expensive.
- “Every requirement has a name.” Requirements should come from a person, not “the department” or “compliance” — otherwise nobody can challenge them. Requirements are debt, not safety.
- Companies don’t slow down because people are lazy. They slow down because of invisible rules — processes that once made sense and that nobody has questioned in years. It’s the most honest diagnosis in the book.
- Speed is a culture, not a tool. Short cycle time beats perfection: better to test something unfinished quickly than to ship something supposedly perfect slowly.
My view as someone in the SME world
This is where it gets interesting — and where you have to filter. Strip out the Musk pathos, the “set unrealistic goals” romanticism, and above all the prerequisites a normal company doesn’t have (billions in capital, risk appetite, and the survivorship bias — Tesla survived; nobody writes a book about the hundreds that died chasing the same “crazy goals”), and what remains is scale-independent: the algorithm is, at its core, just disciplined process design.
Which is why the book confirmed more than it surprised me. “Question every requirement” is exactly what I’ve described elsewhere as the leading cause of failed software projects — see why software projects fail. And “delete and simplify first, automate last” is the same order I argue for with AI — see a tool, not a miracle. Mostly, McNeill gave me crisp vocabulary for things I already believed.
What I keep, what I reject
I’d keep the five steps as a plain checklist — especially “delete before automate” and “every requirement needs a name.” That works in an 8-person team just as well as in a factory.
I’d reject the implicit “be like Musk”: glorifying brutality and 100-hour weeks as a recipe, and the uncritical transfer of hypergrowth logic to companies that don’t want to hypergrow — and shouldn’t. Most smaller companies don’t need “exponential growth”; they need less friction. The algorithm delivers the second; the first is marketing.
Who it’s for
Read it if you own processes and want language for why you’ve become slow. Don’t read it as a Tesla-admiration book — the method inside is too good to bury under hero worship.
The real value of the book isn’t “become like Tesla.” It’s: before you automate something, delete it first — most waste disappears once you question the requirement that caused it.
