In Burkina Faso, a cooperative makes kabakrou. It is the household soap of the region: a ball of about 250 grams, made from local oil and caustic soda, sold one ball at a time in the market and by the 100-kilo sack to wholesalers who come from Côte d’Ivoire, Mali, Niger, and Togo. One product. Two ways to sell it.
The process takes four days. Heat the oil — the long cook, brûler l’huile — and let it rest overnight. Dissolve the soda in water and leave the solution to cool for a day or two. Combine, and stir by hand until the paste feels right. Shape the balls, then dry them, and the drying is the whole game: too fast or too humid and the ball cracks, and a cracked ball is not a product, it is a loss. Nobody can tell you in advance how long drying will take, because it depends on the air that week.
The cooperative wrote a funding dossier. The plan was a semi-mechanized unit: an electric mixer and extruder, ten barrels, drying racks, a 120-square-metre building, four staggered production lines running the same four-day cycle in parallel. Eight times the output of a manual workshop, 13,600 kilos a month. It is a good plan, and it starts at the wrong step.
When I looked at the four days, most of them were waiting. The overnight rest after the cook, the day or two of cooling for the soda, the transfers from barrel to barrel with a pause between each, the stirring that goes on past the point where the reaction is done because “until it feels right” has no clock. Every one of those waits is a part. Some of them are chemistry. Some of them are habit, or the logistics of having only so many barrels. Nobody had ever separated the two.
The turn
The cooperative had asked for a machine. What it needed first was a list. That is what almost every company asks for when it says “AI”: make the current process faster. And that request contains a trap so common that the man who named it did so as an engineering rule, not a business one.
The most common mistake in AI transformation is automating a part that should not exist. Before any tool is bought, any pilot started, or any agent trained, a company should run one test on every part of the process it wants to improve: who, by name, asked for this, and what breaks if it is gone tomorrow. Parts that fail the test are deleted. Only what survives gets automated. Done in this order, the automation is cheaper, safer, and smaller. Done in the reverse order, you build a faithful copy of the old process with a chatbot attached — and the copy is now harder to delete than the original.
The five steps, and why the order is the whole point
Elon Musk’s production teams work to a five-step rule that has been documented in detail. It was written for rockets and cars, and it is the sharpest statement of the idea I know.
First, make the requirements less dumb. Every requirement must come with the name of the person who set it. Not a department, not a standard, not “the customer”: a person, who can be asked why. Second, delete the part or the process step. If you don’t end up adding back at least ten percent of what you deleted, you didn’t delete enough. Third, simplify and optimize what survives. Fourth, accelerate the cycle time. Fifth, and only fifth, automate.
The rule inside the rule is the order. Musk’s own phrasing is that the most common error of a smart engineer is to optimize a thing that should not exist. Automation is optimization with a very large budget. Apply it to a step that should not exist and you have not saved the cost of the step; you have made the step permanent.
Most AI programmes run the five steps backwards. They start at five, because the vendor sells step five. They skip four, because nobody measured the cycle time before. They never reach one, because asking who owns a requirement is the one question a mature organization has taught everyone not to ask.
A company is made of parts
Here is where the soap matters, and where it stops mattering.
In a workshop, a part is a thing you can hold or stand next to: a barrel, a sack, a drying rack, a batch, an overnight rest. The five-step rule is easy to picture because the parts are physical. Delete a step and you can see the barrel it used to happen in.
Your company has exactly as many parts. You just can’t see them, because they are made of words. Steps and rules. Approvals and sign-offs. Fields on a form, columns in a report. Meetings that exist because a meeting once went wrong. Roles whose title describes a problem from 2014. Systems and the integrations between them. Features in your product, variants in your catalogue, tiers in your price list. Clauses in your standard contract. Policies. KPIs. Anything that has a cost has a part number, whether or not anyone wrote it down.
I spent years designing a language that turns legal contracts into executable logic, and the first thing you learn when you make a contract computable is how many clauses no one can justify. They were copied from the previous contract, which copied them from a template, which was written for a dispute nobody remembers. A clause nobody owns and a form field nobody owns and an approval nobody owns are the same part. They fail the same test.
So the taxonomy I use, in the room, is deliberately flat:
- Process parts: steps, rules, approvals, handoffs, exceptions, checklists.
- Information parts: form fields, report columns, dashboards, status updates, the weekly deck.
- Organization parts: meetings, roles, committees, review cycles.
- System parts: applications, integrations, spreadsheets that became systems.
- Offer parts: features, SKUs and variants, price tiers, bundles, service levels.
- Contract parts: clauses, policies, terms, disclaimers, the renewal ritual.
- Measurement parts: KPIs, targets, reports about the KPIs.
List them for one workflow, not the company. One workflow produces more parts than fit on a whiteboard, and that is plenty to work with.
The owner test
For each part, two questions, asked out loud, in front of the people who run the workflow.
Who asked for this, by name? “Compliance” is not a name. “The auditors” is not a name. “The client” is not a name unless you can say which client, and whether that client is still a client. When a part has no name attached, there is no one who can release it, and a part that no one can release is not a requirement. It is an antibody: a piece of organizational tissue that exists to defend the organization from a threat that has usually passed.
What breaks if it is gone tomorrow? Not “what might break” — what breaks. If the answer is a story about a thing that happened once, in 2019, note the story and put the part on the delete list anyway. You are allowed to bring it back. That is what the ten percent is for.
The output is unglamorous: a list of parts, each with a name or a blank, each with a consequence or a shrug, and a delete list of the blanks and the shrugs. Done honestly, the delete list exists before anyone has typed a prompt.
Why your organization will refuse
This is the part the five-step rule does not cover, because it was written for a company with one owner who can say yes.
In a company of two hundred people, deletion is the change the immune system rejects hardest. Every ownerless part is ownerless for a reason: someone, at some point, made it nobody’s responsibility so that it could never be removed. The approval that protects a manager’s relevance. The report that justifies a team. The clause that legal added because deleting it would require legal to sign off on deleting it. You can delete a part in the room on Tuesday and find it back in the process by the end of the quarter, restored by people who were never in the room and who sincerely believe they are protecting the company.
I’ve mapped twelve of these antibodies, and three of them are specifically about parts. The Committee of No: a group that can veto but cannot own, so nothing it protects can ever be released. The Procurement Filter: a rule that adds a part to every process as the price of buying anything. And We’re Special: the belief that the industry, the regulator, or the client requires the part, which nobody has checked in years.
Which is why the map, in the way I run it, is not a workshop the leadership team attends. It happens with the CEO first, privately, on one workflow, so that the inventory of parts and the antibodies defending them exist before the people who will defend them see it. The Cut itself then runs on a different object: not the old process, but the workflow designed again from zero — if we needed this capability today, with everything now possible, how would we build it? Every part of that design has to earn its place with a name and a consequence. The old process is never improved; it is retired when the new one has won, and the roughly ten percent of it that turns out to be needed comes back on its own while the two run side by side.
What automation looks like on the other side
Once the delete list is applied, the process you have left is shorter, has fewer exceptions, and, crucially, has a named owner for every rule that remains. That is the process you capture as a playbook, that is the process an agent learns to run, and that is the process you measure the agent against. Set the benchmarks before the run, keep the old way alive until the new one has won, and count the deleted parts as their own result next to cycle time and error rate. A good first workflow shows a falling override rate and a rising count of things that no longer happen at all.
At the soap cooperative, the delete list has four items, and each one is a test, not a decision. Does the overnight rest after the cook change the soap, or is it barrel logistics? Does the soda solution need two days to cool, or would a controlled shorter cool-down, with the right safety precautions, give the same stable paste? Can the barrel-to-barrel transfers collapse into fewer vessels and a tighter sequence? And how much of the stirring completes the reaction, versus how much is a person standing at a barrel because that is what the step is called? If the tests hold, the four-day cycle gets shorter before a single machine is bought, and the mixer, when it comes, mixes for less time on a process that has fewer steps.
And the drying, the one part nobody could put a clock on? Nothing was automated. What we designed is a paper log: every batch, every step, the humidity and temperature that day, the quantity, where the oil came from, and a photograph of what came out. That is Musk’s first step, not his fifth. You cannot automate “dry enough” until someone has written down what it meant on forty different days. When the log is long enough, a model can learn to predict the drying time from the weather and the batch. Until then, the log is the requirement, made less dumb.
The point was never the automation. It was that the parts came first.
Frequently asked questions
What is Musk’s five-step algorithm? A rule for improving any production process, in a fixed order: make the requirements less dumb (every requirement carries the name of the person who set it), delete the part or process step (if you don’t add back ten percent, you didn’t delete enough), simplify and optimize what remains, accelerate the cycle time, and automate last. The order is the substance: automating a step that should not exist makes it permanent.
Why should you delete before automating a process? Because automation is optimization with a large budget, and optimizing a part that should not exist locks it in. Every AI agent trained on the current process learns its ownerless approvals, redundant fields, and dead clauses as requirements. Deleting first makes the automation smaller, cheaper, and safer, and gives every remaining rule a named owner the agent can escalate to.
What is the owner test? Two questions asked of every part of a workflow: who asked for this, by name, and what breaks if it is gone tomorrow. Departments, standards, and “the client” are not names. Parts with no name and no concrete consequence go on the delete list. You are allowed to bring some back; that is what the ten percent rule is for.
What counts as a “part” in a company? Anything that has a cost: process steps, rules, approvals, form fields, report columns, meetings, roles, systems and integrations, product features, SKUs and price tiers, contract clauses, policies, and KPIs. In a workshop the parts are physical; in a services firm they are made of words, which is why nobody counts them.
Why do deleted processes come back? Because in a mature organization, most ownerless parts were made ownerless so they could never be removed. The corporate immune system restores them through people who were not in the room and believe they are protecting the company. That is why the deletion is decided privately with the CEO, on one workflow, before the wider team is involved.
Samuel Pouyt has spent twenty years building decision-grade systems: eight as software architect for the European Respiratory Society, seven building AI for geopolitical risk forecasting inside a Fortune 500 company, and thirteen as a Swiss Armed Forces reconnaissance NCO. He writes about organizational transformation, specification, and decision-making under uncertainty. The full story →