Musk's five-step algorithm for cutting bureaucracy — and what AI changes about it

The most useful framework for adopting AI agents wasn’t written for AI at all. It comes from Walter Isaacson’s 2023 biography of Elon Musk, where it appears simply as “the algorithm” — a five-step discipline for stripping bureaucracy out of any process, repeated so often at Tesla and SpaceX that engineers could recite it back like a catechism. Question every requirement, delete any part of the process you can, simplify and optimise what’s left, accelerate the cycle time, and only then, fifth and last, automate. The algorithm is older than ChatGPT, and for most of its life that last step meant scripts, macros and industrial robots. What’s changed is that “automate” now means handing work to software that can reason, and that shift makes the first four steps matter even more.

Five steps with warning labels

Each step carries its own warning label, and the labels are where the value sits. A requirement can’t be attributed to a department — it has to carry the name of a person, who can then be asked whether it’s still true. Deletion comes with a target: if you aren’t adding back at least ten per cent of what you cut, you didn’t cut enough — the discipline SpaceX applied when stripping parts and mass out of its Raptor engine. Simplification sits deliberately after deletion because, as Musk puts it in the book, the most common error of a smart engineer is to optimise a thing that shouldn’t exist. The steps are ranked, in other words, by how expensive their mistakes are, and automating something that should have been deleted is the most expensive mistake available.

Musk arrived at the order the expensive way. The Model 3 production crisis of 2018 was in large part an over-automation story, an assembly line so elaborately automated that he ended up ripping out part of the conveyor network and handing work back to humans. His verdict at the time — “excessive automation at Tesla was a mistake. To be precise, my mistake. Humans are underrated” — still reads as one of the more expensive lessons in modern manufacturing, and the algorithm is what he salvaged from it.

Automation used to say no

For decades, step five policed itself. Automation was rigid and dear: to script a process you had to understand it completely, specify every branch, and pay a developer to encode the lot, and any edge case you’d missed came back as a support ticket. That rigidity worked like an unpaid consultant. A messy, half-understood process wouldn’t fit into the software: try scripting your approvals and you’d discover by Tuesday that nobody agreed what the rules actually were. So the questioning and simplifying got done, sometimes resentfully, because the alternative was a system that fell over daily.

AI agents dissolve that constraint. An agent copes with ambiguity, works around inconsistency, and makes a passable decision when the inputs don’t match the template. That sounds like progress, and mostly it is, but something valuable got lost on the way: automation used to refuse a bad process, and now it accepts one willingly. Point an agent at a workflow nobody has questioned and it will run that workflow faithfully and at scale, including the steps that exist only because someone senior asked for them in 2019. I’ve written before that AI won’t fix bad management — it will expose it; agents raise the stakes again, because an agent doesn’t merely expose a broken process — it industrialises it.

You can see the cost of skipping the first four steps in the adoption numbers. The temptation is easy to understand: standing up an agent takes an afternoon, while questioning a process means weeks of awkward conversations, so the afternoon usually wins. When MIT’s Project NANDA reported last summer that 95 per cent of enterprise generative-AI pilots were showing no measurable profit-and-loss impact, the report’s own diagnosis pointed at exactly this: pilots bolted onto processes that nobody had redesigned. Musk’s rule that you never automate before you simplify is being violated at industrial scale, by organisations that would nod along to every word of it in a leadership offsite.

Delete first, then build

The counter-examples are instructive, and my favourite recent one comes from publishing. Scott Purcell, co-founder of the Australian publisher Man of Many, wrote in TechRadar this spring about Otto OS, the AI “operating system” he built to run his company’s back office. The advice he leads with is pure steps one and two: map your tool sprawl — list every SaaS product you pay for and, next to each, which fifth of its features you actually use — and cut before you build. What he automated was the boring residue that survived the cull, starting with a morning briefing that pulls revenue, traffic and outstanding invoices into one place. The build took roughly a week using Claude Code, with no traditional developers involved, and it was quick precisely because the thinking had already been done.

The same holds in software engineering, where agents are furthest along. Andrew Filev, who founded Wrike and now builds coding agents at Zencoder, promises engineers ten times the output — and the teams actually seeing that multiplier are the ones whose testing and review discipline was in place before the agents arrived.

This is also the lesson I keep arriving back at from my E-Myth years: AI rewards the business that has written itself down. Documenting a process forces the algorithm on you whether you’ve read Isaacson or not, because nobody writes down step six of a workflow without eventually asking why step six exists. I spent seventeen years at Vertical Leap learning that discipline the slow way, and AI has repriced it: a written-down business can hand an agent a process that’s already been questioned, while everyone else is automating guesswork.

Running the algorithm before your next agent

None of this needs Tesla’s budget — the algorithm maps directly onto AI adoption, and applying it looks like this:

1. Question every requirement, with a name attached: Before specifying an agent, list what the process is required to do and who required it. A requirement without a living, askable owner is a candidate for the next step.
2. Delete before you prompt: Any step you remove now is a step you’ll never have to automate, monitor or debug. The cheapest agent is the one you don’t build because its process stopped existing.
3. Simplify what survives: Collapse duplicate approvals, settle on one source of truth for each piece of data, and rewrite the process in plain language. A simple process needs a shorter prompt, fewer tools and far less oversight.
4. Accelerate by hand first: Run the leaner process manually for a cycle or two. It will feel slow, but it surfaces what the agent will need to know — the exceptions, the judgement calls, the tacit rules nobody had written down.
5. Automate last, and expect to reinstate: Deployment is where your deletions get tested, and Musk’s rule says at least ten per cent of what you cut should eventually come back. When a deleted step turns out to matter, put it back deliberately, with a name attached.

One question I can’t settle yet: agents are now good enough to help with the questioning and deleting themselves, and I don’t know whether that’s a legitimate accelerant or a way of outsourcing the very discipline the algorithm exists to protect. For now I’d keep the deleting itself a human decision, made by someone who understands why each step existed and who’ll answer for its absence.

The order, though, has never been in doubt. Automation has become the easiest of the five steps, which leaves the other four as the real work, and they were always the real work; the machines have simply stopped hiding it. So before you build the agent, spend a week asking who wants each step and deleting the ones nobody can defend, then give the software a process worth amplifying. Your team will feel that week’s work before the software does: the steps nobody could explain are gone, and what’s left is work that deserves the speed.