The Algorithm: The Best Part Is No Part

Walter Isaacson’s biography of Elon Musk changed my view of him. Musk is a divisive figure, and much of the criticism appears to be deserved. But even his detractors have to concede that what he has managed to achieve at a whole array of companies is extraordinary, and much of it comes down to how he runs operations.

Jon McNeill’s The Algorithm is the first book by one of his direct reports to explain how that works. McNeill was President of Tesla from 2015 to 2018 and has since sat on the boards of Lululemon and General Motors. He writes as an operator who has also had to apply the method from the boardroom.

Five steps, in order

The method fits on an index card:

1. Question every requirement.
2. Delete every possible step in the process.
3. Simplify and optimise.
4. Accelerate cycle time.
5. Automate.

None of these is new on its own. What matters is the order.

Most organisations work through it backwards. They automate a bloated process, try to speed it up, and then wonder why it still does not work.

Tesla learned this the hard way. During the Model 3 production crisis in 2018, Musk admitted publicly that excessive automation had been a mistake. You should only automate a process once you are sure it deserves to exist.

The best part is no part

The heart of the book is deletion. Every component, step, approval and form has to justify its existence.

McNeill’s best example is simple. Buying a Tesla online once took more than 60 clicks. His team cut it to about a dozen, partly by deleting more than 40 pages of loan terms that lawyers had added over time but the law did not require.

Nobody decided to make buying a car painful. Each clause was added for a reason, by someone sensible. Together they became an obstacle to the thing the company existed to do.

Musk’s discipline is that every requirement should come with the name of a person, not a department. A requirement from “legal” cannot be questioned. A requirement from a named colleague can.

Requirements in regulated industries

This is where the book needs translating for the sectors I work in.

In medtech, pharmaceuticals and pharmacovigilance, many requirements cannot be deleted. They protect patients, and regulators are rightly not interested in hypergrowth formulas.

But that makes the first step more important, not less. The real question is which requirements come from the regulator and which have built up out of habit, caution or precedent. In my experience the second list is usually longer, and it is defended just as seriously.

The limits of the book

The Algorithm is thin in places and repetitive. It is a playbook, not a balanced account of Musk.

Its case studies come from very large companies, and it says little about the human cost of Musk-style pressure. There is also a survivorship problem: we read about the deletions that worked, not the ones that removed something important.

Start with the board pack

The lesson is uncomfortable because it applies to boards too.

We are very good at adding: another control, another report, another approval threshold. Very few boards ask what they could take away. A few questions are worth asking regularly:

• What did we stop doing this year?
• Which requirements are imposed by a regulator, and which did we impose on ourselves?
• Does every new control have a named owner and a review date?
• Are we about to automate a process that should not exist?

The board pack is a good place to start. If it has grown every year and the quality of discussion has not, the algorithm applies to us as much as to the factory floor.