Sharpen the Axe: A Better Way to Fix Business Processes

“Give me six hours to chop down a tree and I will spend the first hour sharpening the axe.” ~ Abraham Lincoln

When you are asked to automate a business process, where do you start?

In February 2017, Elon Musk told the market that Tesla would build 5,000 Model 3s a week by the end of June 2018. At the time, the number was fantasy. Tesla had never built cars at anything close to that rate, and by April 2018 it was still limping along at around 2,000 a week across two production lines. Short sellers smelled blood. They piled in, certain that Tesla’s own ambition was about to sink it (see what I did there).

Musk rolled up his sleeves, went to the battery plant in Nevada and reworked the processes there. Once satisfied, he moved to the Fremont factory, stood on the line, and did the same again. In the early hours of Sunday 1 July 2018, Tesla built and delivered its 5,000th Model 3 for the week. Short sellers lost billions.

Musk later admitted that the real mistake had been trying to automate every step of the Model 3 line before the process underneath was fit to automate. Speed had been applied to a machine that was not yet worth speeding up.

Out of that experience came what is now known as Musk’s Algorithm, five rules he has repeated at SpaceX, Tesla and The Boring Company ever since:

1. Question every requirement
2. Delete any part of the process you can
3. Simplify and optimise
4. Accelerate cycle time
5. Automate

Lincoln’s axe and Musk’s factory floor are the same lesson two centuries apart. The temptation in solution design is to reach straight for the axe and start chopping. This algorithm is a discipline for resisting that temptation, and it turns out to be one of the sharpest lenses available for anyone automating a business process.

The problem: we automate the process we have, not the process we need

Here is the pattern that plays out in almost every solution design. A business process is painful. Leadership wants it fixed. Someone is asked to automate it. The team maps the current state, wires up a workflow engine, bolts on some process automation, and ships something that runs the existing process faster, then pops champagne to celebrate.

The trouble is that nobody asked whether the process deserved to survive in the first place. A requirement that was reasonable in 2014, when the legacy system it protected against was fragile, might be dead weight in 2026. An approval step that exists because “that’s how we do things here” gets faithfully encoded into a workflow definition, given a shiny new interface, and made permanent. You have not solved the problem. You have sprinkled glitter on a process to make it shine.

According to Musk, the most dangerous requirements come from smart, senior people, precisely because nobody dares to question them. In architecture terms, this is technical debt’s quieter sibling, process debt, and automation is the most efficient debt-compounding machine ever invented. If you automate a broken process, you have not removed the friction. You have given the friction a promotion.

The solution: run the algorithm before you write a single workflow

Steps one to four are the axe-sharpening. Step five is the chopping. Do the first four properly, and the fifth step becomes almost anticlimactic, because there is so little left to automate.

1: Question every requirement

Every requirement in a business process should have a name attached to it, not a department. “Finance requires this” is not an answer. Who in finance requires it, and why? Walk the process with the people who actually own each rule and ask them to unpack it from first principles rather than from precedent.

You will find requirements built on assumptions from a software system that was decommissioned years ago, or safeguards against a risk that no longer exists. This is the step where an architect earns their keep, not by drawing diagrams, but by refusing to accept “we’ve always done it this way” as an answer.

Elon argues that more dangerous requirements comes from smart and senior people simply because they are less likely to be question.

2: Delete any part of the process you can

This is my favourite part of the algorithm. It is the step most teams skip, and it is the one with the highest return. Every step you delete before implementation is a feature you never had to build, test, document or maintain. It is also a meeting you never had to sit through, unpacking a workflow that should never have existed.

According to Musk, if you do not end up reinstating at least 10% of what you deleted, you did not delete enough. Deletion should feel slightly reckless. That is the signal you are doing it properly rather than politely trimming the edges.

3: Simplify and Optimize

Only now, once the process has been interrogated and cut down to what is genuinely necessary, do you start refining what remains. This ordering matters more than it appears to. Optimising a step before questioning and deleting it means polishing something that should not exist, and a beautifully optimised unnecessary step is still unnecessary.

This is where an architect can bring patterns in properly: consolidating duplicated logic, aligning the process with a clean bounded context, and making sure the ubiquitous language used in the process matches how the business actually talks about it.

4:Accelerate cycle time

Time the end-to-end value stream along its happy path, then go activity by activity to find out where the process is waiting rather than working. This is the step that exposes the real bottlenecks: the handoff where work sits in a queue for three days because someone only checks it on Fridays, or the integration point where a batch job runs once overnight when it could run in seconds.

Accelerating cycle time before this point is wasted effort, because you would be speeding up work that steps two and three were about to remove anyway.

5:Automate

By the time you reach this step, the process is small, deliberate, and fast. Automating it is no longer an act of faith. It is closing the loop on a design that has already proven itself. This is also where the technology choices genuinely matter, namely which parts of the process are stable enough to encode as a deterministic workflow, and which need the flexibility of a human or agent decision point, a non-deterministic step, or a rules engine that can be updated without a deployment. Automating too early answers those questions before you have enough information to answer them well.

According to Walter Isaacson, Musk admitted as much about his own factories. The mistake in Nevada and Fremont was reaching for automation before the requirements had been questioned, the unnecessary parts deleted, and the remaining bugs shaken out.

Seeing it in practice: booking a business trip

Take something every organisation wrestles with, booking travel. The current state at most companies looks like this.

1. A colleague needs to fly to Johannesburg on Thursday. She emails the travel desk.
2. The travel desk emails back for dates and a budget code, logs into a booking portal, and pastes flight options into a reply as a screenshot, because the portal has no clean way to share a link.
3. She picks one and replies to the travel desk.
4. Someone re-keys the booking reference into an expense spreadsheet by hand, because the booking system and the finance system have never been introduced.
5. A PDF itinerary lands forty minutes later. If the flight is cancelled, the whole chain repeats under time pressure, usually with someone on hold to an airline call centre while a client meeting runs late.

The default solution is to buy or build a shinier portal and with chatbot capability. Run the algorithm instead.

1. Question every requirement and you will find that the human review on every booking exists only because the old portal used to be unreliable. The system has since improved, but the rule never got revisited.
2. Delete what you can and the screenshot-in-an-email step disappears entirely, the manual re-keying disappears because it is pure duplication, and routine in-policy bookings no longer need a human at all.
3. Simplify what remains by putting flight search, hotel search, policy rules and expense coding on one data model instead of four disconnected systems. Also turn the travel policy from a PDF nobody reads into rules a system can actually check.
4. Accelerate what is left and a request that used to take half-a-day, most of it spent waiting for someone (who might be on lunch or at the pub) to open an email, now takes minutes, because there is almost nothing left to wait on.
5. Only then does automation make sense, and this is where agentic AI is a genuinely better fit than a scripted booking bot. An orchestrator agent owns the request end to end: a policy system checks it against the rules in milliseconds, a search-and-book system talks directly to the airline and hotel APIs and only escalates a genuine judgement call, and a finance system writes the booking straight into the expense system the moment it confirms.

When a flight is cancelled, a monitoring agent spots the disruption the instant the airline publishes it, checks what the traveller actually needs to be present for, rebooks within policy. The human only re-enters the loop when the agent genuinely cannot resolve it.

Automated first, this would have been a very well-engineered screenshot emailer. Sharpened first, it is an agent quietly doing a travel desk’s job while everyone else gets on with theirs.

Conclusion

The next time you are asked to automate a process for a client, resist the instinct to open the workflow designer. Open a conversation instead.

1. Find out who owns each requirement and why it exists.
2. Delete without mercy, then add back only what proves itself necessary.
3. Simplify what survives.
4. Time it, and find where it is idle rather than busy.
5. Only then should automation enter the room.

Do this properly, and step five stops being the hard part. The axe was always going to chop the tree quickly. The work, and the value, was in the sharpening.

Reference

1: Walter Isaacson — Elon Musk by Walter Isaacson

2: Tesla Press release — https://ir.tesla.com/press-release/update-tesla-q2-2017-vehicle-production-and-deliveries