The 1990 diagnosis
The July–August 1990 issue of Harvard Business Review carried an article by Michael Hammer called “Reengineering Work: Don’t Automate, Obliterate”. The HBR page is behind a paywall, so we read the PDF of reprint 90406.
The article opens with a diagnosis. Companies had put serious money into information technology and were disappointed with what they got. Hammer puts the blame on how the technology was used: to mechanise old ways of working. The processes stayed as they were. The computers only made them run faster.
The tool has changed since then. Now a language model gets built into the old process: the enquiry travels the same route, except that a bot writes the first reply. A pointless step on that route gets passed faster, but it does not go away.
This piece follows on from “What to automate first”. There we counted the hours each step eats. Here the question comes earlier: which steps should never survive long enough to be counted.
Cow paths
The best-known line in the article is about asphalt. “It is time to stop paving the cow paths. Instead of embedding outdated processes in silicon and software, we should obliterate them and start over,” Hammer writes (HBR, 1990).
Nobody designed the cow path. It appeared where the cows walked. Asphalt makes it smoother, but the loops stay where they were, and now they are expensive to move.
A made-up example. An enquiry reaches a manager in Telegram. He forwards it to the warehouse chat to check stock. The storekeeper replies, and the manager copies the answer into a chat with his boss to agree the price. The boss answers somewhere else, in the department’s group chat. The customer gets a reply stitched together from four conversations.
Now add a bot that forwards the messages between chats by itself. The enquiry takes the same route, faster. The route still has the same four places where a message can get lost, and the same copying, only now it is done by a program that does not notice mistakes. If the storekeeper gets the stock figure wrong, the wrong figure reaches the customer within a minute.
Hammer would ask a different question: why does an enquiry need four chats? If stock is kept in a spreadsheet, checking it is a lookup in that spreadsheet, not a message to a person. If discounts follow rules, the boss is needed only for the exceptions. After that edit the route is shorter, and there is less in it to automate.
Gates, 1995: how we traced the rule
The same idea has a shorter version. It is credited to Bill Gates and usually quoted with no word on where it comes from.
It does have a source: The Road Ahead, the book Gates wrote with Nathan Myhrvold and Peter Rinearson, at the end of chapter 7, “Implications for Business”. The rule is two sentences long. The first says that automation applied to an efficient operation magnifies the efficiency. The second reads: “automation applied to an inefficient operation will magnify the inefficiency” (The Road Ahead, 1995).
Here is how we checked. Open Library can search the text of scanned books. A search on the end of the second sentence found it in two 1995 scans, the Viking edition and the Wheeler edition. In both, the words “magnify the inefficiency” are followed by the same continuation, so the sentence comes from the book itself and not from a quotation collection.
The first sentence was harder. For that one, the scan search shows only the opening words. Both sentences appear in full, word for word, in quotation collections such as The Economist Book of Business Quotations (2012). That is why only the second sentence is in quotation marks here: we saw the part that carries its meaning in the scan ourselves.
The most precise word in the rule is “magnify”. Automation does not add a helping of benefit to a process. It takes the process as it is and repeats it more often and faster. There is a second effect as well: a pointless step that a person used to do is now run by a workflow, and there is nobody left to notice it.
Drucker, 1963: doing efficiently what should not be done
Twenty-seven years before Hammer, Peter Drucker put the same idea into “Managing for Business Effectiveness” (Harvard Business Review, May 1963). It contains the sentence: “There is surely nothing quite so useless as doing with great efficiency what should not be done at all.” We checked the wording and the source against Quote Investigator.
Retellings wore it down over time. Quote Investigator lists several versions. By 1964 “surely” had gone. In 1991 “with great efficiency” shrank to “efficiently”. In 1995 “useless” was swapped for “less productive”. “At all” survived every version, which makes sense: the sentence rests on it. Drucker is talking about work that should not exist in the first place.
The idea is older than Drucker. Quote Investigator finds a similar line in The Journal of Education in 1907, quoting Professor Giddings, who called administration a systematic way of doing what does not need doing. But the version about efficiency is Drucker’s. His article’s title is about effectiveness, while the sentence says efficiency. You can do needless work very efficiently and still get no result from it.
Deming: quality cannot be bought
W. Edwards Deming came at it from another side. In “Out of the Crisis” (1986; an earlier version came out in 1982 under a different title) he wrote: “The transformation can only be accomplished by man, not by hardware (computers, gadgets, automation, new machinery). A company can not buy its way into quality” (Out of the Crisis, p. 18).
Deming wrote this forty years before language models, but the mechanics are the same. Buying a tool does not answer the question of which steps are needed. The answer comes from someone who knows the process: who reads the output of a step, and what breaks if the step is removed. The model does not know that. It sees messages being forwarded from chat to chat, but not why they are forwarded.
What to strike out before building the workflow
Before you build a workflow in n8n or plug in a model, write the process out step by step, as in the piece on counting hours. Then put five questions to each step.
- Who uses the output of this step? If you cannot name a person or a next step, nobody reads it.
- What breaks if the step disappears tomorrow? If the answer is “nothing” or “we’ve always done it”, the step is a candidate for striking out.
- Does it duplicate another step? The same data typed into two places, the same check done by sales and by accounts.
- Can it be merged with the step next to it? Two sign-offs in a row by two people can sometimes become one.
- Is it needed at all? A report for a manager who left long ago, a copy sent to a chat nobody opens: these are leftovers from a process that no longer exists.
Sometimes a step passes all five questions but is not needed every time. Then it becomes conditional: for example, a sign-off only for discounts above a threshold.
What is left gets automated. The order matters for the same reason the word “magnify” matters. Removing a step from a process run by people takes one instruction. Removing it from a live workflow means an edit, a test, and a hunt for everything that has come to depend on its output.
Only then does it make sense to build the n8n workflow. That is why our business automation work starts with taking the process apart step by step, and the build comes after. The workflow goes on the client’s server, running on the client’s keys, so every surplus step would be something the client then has to maintain.
What we don’t know
Hammer’s article is paywalled on the HBR site, so we took his wording from the PDF of reprint 90406. For Gates, the search of the 1995 scans showed the end of the second sentence of the rule and the opening of the first. We saw both sentences in full only in quotation collections, which is why we paraphrase the first. Drucker’s sentence and its later versions were checked against Quote Investigator, which cites HBR 1963; we did not open the HBR archive itself. Deming was checked against the Deming Institute page and a text search of the scan; we have not read the whole book.
We have no data of our own showing that striking steps out pays off better than automating them. We have no clients yet, so there are no measurements. The rule is old and explains the mechanics well, but it is not a measurement.
If you want to find what is surplus in your own process, describe it in the quiz. Within 48 hours we will send back a map: what to take off people, in what order, and what it costs. No intro call needed.
