Picture the floor plan of an American machine shop around 1900. Along the ceiling runs a single iron shaft, the length of the building. Leather belts drop from it to every lathe, drill and press, so the machines stand in rows wherever the shaft can reach them, not where the work needs them to be. At one end, where the steam engine used to sit, someone has pencilled in a large electric motor. The motor turns the same shaft. The belts, the rows and the walking between them are unchanged. The owner has adopted the new technology, and the shop runs much as it did before.
That pencilled motor is the oldest version of a question now asked in every AI steering meeting. Should we fix the workflow first and then add the tool, or redesign the workflow with the tool in hand? The first answer I will call paving the path: make the existing work lean and stable, then automate it, so the tool speeds up a step whose purpose stays the same. The second I will call redrawing the floor: design the work around what the new tool makes possible, which you can only see once you know what it can do. My argument is that the familiar advice, redesign your workflow before you add AI, is right for paving and wrong for redrawing, and that many AI projects are the second kind presented as the first.
This is not a case against process work, and it is not permission to automate a mess. In both cases the first job is the same: understand the workflow as it really runs, with its exceptions and workarounds. What differs is the order of everything after that. When the tool leaves the step's purpose intact, fix the step and then automate it. When the tool changes who decides, when information arrives or whether a handoff needs to exist, the redesign has to happen alongside the tool, because the right workflow cannot be drawn until you know what the tool can do.
The case for paving first
The advice to fix the work before automating it has a distinguished history, and it deserves to be stated at full strength. In the July 1990 issue of the Harvard Business Review, Michael Hammer argued that companies had spent heavily on computers and got little back because they kept their old processes and used computers only to make them run faster.1 Those processes had been designed for a world of paper forms and slow communication, and automating them preserved every delay the paper had imposed. "It is time to stop paving the cow paths," he wrote. His remedy was to obliterate the old process and design a new one first.
Toyota gives the same advice from the factory floor, with the authority of a production system that much of the world has copied. Its description of its own method calls automation with a human touch "jidoka", and insists that rather than starting with a machine, you must first try doing it thoroughly by hand.2 The logic is plain. A person doing the work by hand finds its waste, its failure points and its natural rhythm. A machine installed before that learning simply repeats whatever it was given, at speed and at a cost that makes it hard to change.
The modern cautionary tale comes from Tesla. Elon Musk designed the Fremont line for the Model 3 to automate every task from the outset, rather than starting with people and automating where it proved possible.4 By spring 2018 the company was in what Musk called production hell. He told an interviewer that a complex network of conveyor belts was not working, and that the company had got rid of it. On April 13 he wrote on Twitter that excessive automation at Tesla had been a mistake, his mistake, adding that humans are underrated.3 Walter Isaacson's 2023 biography records the rule Musk took from the episode, five steps in a fixed order: question every requirement, delete any part or process you can, simplify and optimize, accelerate the cycle, and only then automate.4
Hammer, Toyota and Musk agree on the mechanism. Automation freezes whatever it touches. If a process is wrong, a machine makes it wrong faster and makes the error expensive to remove. That is true, and for a large class of projects it is the whole story.
The same summer, another answer
In the same summer of 1990, Thomas Davenport and James Short published a different account in the Sloan Management Review.5 They called process design and information technology natural partners, and argued that, used together, the two could create a new kind of industrial engineering. In that account the technology is not only a way to run a finished design faster. It is part of how the design gets made, because what the technology can do changes which designs are available.
The difference sounds academic. It is not. Hammer's sequence assumes that the best workflow can be found by examining the work. Davenport and Short's assumes that some of the best workflows are invisible until you understand the tool. Both can be true, of different projects. The question is how to tell which kind you are looking at.
What the motor did to the floor
The clearest historical answer is the one the opening plan comes from. Also in 1990, the economic historian Paul David published "The Dynamo and the Computer", asking why computers had so far done little for measured productivity.6 His comparison was electricity. Edison's first central power stations opened in 1881. Yet by the early 1920s, David found, only slightly more than half of the mechanical drive capacity in American factories had been electrified, four decades after the first station opened. For much of that time factories used what was called group drive: an electric motor replaced the steam engine and turned the same shafts and belts.
The gains came with unit drive, in which each machine had its own motor. Once power no longer had to travel along a shaft, the shaft stopped dictating the layout. Factory buildings could be radically redesigned, and David points to the shift to single-story factories, whose layouts no longer had to follow the shafts. In his estimate, the growth of that kind of motor capacity accounts for about half of the acceleration in manufacturing productivity growth between the 1910s and the 1920s.
No amount of studying the steam-powered shop would have produced the single-story flow line. The line shaft was not waste to be removed; it was the reason the shop looked the way it did. A consultant asked to make the old shop lean, before the motors arrived, would have shortened walks and rearranged rows beneath the shaft. Every improvement would have been real, and every one would have been an improvement to a floor that was about to disappear.
What hindsight says
If redesign first were the whole truth, the reengineering movement of the 1990s should have delivered its promise. By its own founders' account it did not. A retrospective in strategy+business in 2000 reported that a series of studies in the early 1990s had found that 70 percent or more of reengineering initiatives had made things worse, and that Hammer had admitted error in an interview with the Wall Street Journal.7 The retrospective does not name the studies, and that figure should be treated as a reported estimate, not a measured rate. The founders' own diagnosis was that, in the rush to redesign, they had forgotten about people.
The more telling evidence came from the productivity puzzle itself. When economists eventually measured computers' effects firm by firm, the returns were concentrated in firms that changed several things together. Timothy Bresnahan, Erik Brynjolfsson and Lorin Hitt, in the Quarterly Journal of Economics in 2002, studied information technology, workplace reorganization and new products and services, and found complementarities among all three.8 The technology paid when the organization around it was redesigned too, and the firms that did both used more skilled labor. That is not the sequence Hammer prescribed, nor automation without change. It is redesign alongside the tool. No. 31, "The work around the machine.", covers what those complements are and how to fund them. The point here is narrower: the complements and the technology moved together, not one after the other.
A test: does the tool change the step, or only its speed?
Ajay Agrawal, Joshua Gans and Avi Goldfarb, economists at the University of Toronto, have brought David's lesson to AI. In Power and Prediction, published in November 2022, and in a Harvard Business Review article the same month, they argue that AI is like electricity, used narrowly at first and transformative only later, and that introducing it often entails redesigning whole systems.9 Their vocabulary distinguishes point solutions, which drop a prediction into one existing decision, from system solutions, which change the decisions around it.10
That distinction maps onto the two kinds of project. A point solution is paving. The step stays where it is, its inputs and outputs are the same, and the tool does it faster or more accurately. For those, the old advice is right: stabilize the step, remove what is unnecessary, and automate last. A system solution is redrawing the floor. The tool changes when information becomes available, who can act on it, or whether a handoff needs to exist at all. For those, perfecting today's workflow first means perfecting the arrangement the tool is about to remove.
Rebecca Henderson and Kim Clark explained, again in 1990, why organizations misread the second kind as the first.11 They studied innovations that change the way the components of a product are linked together while leaving the components themselves familiar. Established firms handle those badly, they found, because their knowledge of how the parts connect is embedded in their routines and procedures, where nobody thinks to examine it. An AI project that changes how the steps of a workflow connect looks, step by step, like a set of familiar improvements. The change is in the connections, and that is where nobody is looking.
How projects get misfiled
Take two illustrative requests that might arrive in the same week. The first asks for a tool to match supplier invoices against purchase orders and receipts. The step exists today, people do it by hand, and the tool would do it faster with fewer errors. Nothing upstream or downstream changes. This is paving, and the right sequence is Toyota's: clean up the matching rules, delete the exceptions that should not exist, then automate.
The second asks for a tool to read incoming claims and route them to the right team. It sounds like the same kind of request, a faster version of the sorting desk. But if the tool can read every claim the moment it arrives, the sorting desk, the queue in front of it and two handoffs after it may have no reason to exist. Claims could reach the person who decides them on the first day, with the missing documents already requested. The step has not been sped up; it has been dissolved. Spending three months making the sorting desk lean, before anyone has seen what the tool can read, is the pencilled motor on the old floor.
The way to tell them apart is not the technology. It is a question about the work: if the tool performed as promised, what would we stop doing entirely? If the answer is nothing, only faster, you are paving. If the answer is a queue, a handoff, a review or a meeting, you are redrawing the floor, and the design has to be done with the tool in hand.
Paves the path
same step, faster
Redraws the floor
the step changes or goes
Tap a card to file it. Each one says what would have to be true for it to move to the other tray.
Notice what the pencilled line on each card is doing. The filing is not fixed. A reply-drafting tool is paving while an agent reviews every reply, and becomes a redrawing the day routine replies go out unreviewed, because the review step, its staffing and its accountability all change. Writing down the assumption that would move a project to the other tray is the cheapest protection against misfiling it.
What to do instead
For both kinds, begin by mapping the work as it actually runs, including the exceptions and the workarounds nobody wrote down. That step is not optional, and it is the part of the old advice that survives intact.
Then file the project. If it paves a path, follow Toyota and Musk: remove what should not exist, simplify what remains, and automate last. If it redraws the floor, run a small, bounded redesign alongside the tool. Give a single team the tool and real cases, and ask them to change the workflow as they learn what the tool can and cannot do. Set a date to compare the new floor with the old one on outcomes that matter, not on activity. And keep the lesson of the 1990s: a redesign that forgets the people doing the work will fail whatever its sequence.
Objections, considered
This is an excuse to skip the hard process work. It is the opposite. Understanding the current workflow comes first either way. A redrawing project needs more process work, not less; it is done while the tool is in hand, by people who can see both the old floor and the new one.
Electrification took decades; AI deploys in weeks, so the analogy fails. It is fair on speed, but the lesson is about layout, not time. If anything, quick deployment makes the risk larger: a tool that can be installed in a month can be installed into the old floor in a month, and once it is woven into the old arrangement, the arrangement becomes harder to question.
Toyota and Tesla prove that automating first fails. They prove that automating a mature, physical process before it is stable fails, which is the paving case. This essay agrees with them there. Toyota's advice to try the work by hand is advice about learning the work before freezing it; in the redrawing case, using the tool on real cases is how that learning happens.
Reengineering failed because of layoffs and poor execution, not because of its sequence. Partly true, and its founders said as much. That is why this essay leans on the firm-level evidence on complementarities, not on reengineering's failure rate, and why the reported 70 percent should be read as an estimate. The firm-level finding stands on its own: the returns came when technology and organization changed together.
Before you fix the workflow for the machine, find out whether the machine changes the floor.
Before the next AI project is approved
- What would we stop doing entirely? If nothing, only faster, it paves a path. If a queue, a handoff or a review, it redraws the floor.
- Who decides, and when, once the tool works? A change in either is a sign the step is changing, not just speeding up.
- What can we only learn by using it? Name the part of the design that has to wait for a month of real cases.
- What would move this project to the other tray? Write the assumption down, and check it at the first review.
Back to the machine shop. The pencilled motor at the end of the shaft was not a foolish choice; it was the obvious one, and it worked. It simply could not show its owner the shop he would build twenty years later, with every machine turning on its own and the work moving in one direction down a single floor. Before approving the next AI project, it is worth asking which drawing it belongs on: the old plan with a new motor pencilled in, or a floor plan nobody could have drawn before the motor arrived.