Automating a Broken Process Gives You a Faster Broken Process

Process Redesign and Economic Viability

1. An Elevator, a Robot, and a Redesign

An elevator operator sits on a wooden stool inside the car, pulling a brass lever to close the doors and stop at each floor. That was every elevator in 1920. To automate it, you wouldn’t build a robot to sit beside him and pull the lever. You would redesign the entire system: call buttons on each floor, automatic doors, control logic in a machine room. The robot is task mechanization. The redesigned elevator is automation, and those two are not the same thing.

What that metaphor didn’t capture is the other side of the problem. Even if you redesign the elevator system, you still need to ask whether the redesign generates more value than it costs over its lifetime. If the new automated elevator costs more to install and maintain than the old one with the operator, you didn’t automate anything. You replaced the human operator by financing a more expensive way to do the same job, and you’re losing money faster.

This article is about why the definition of automation has had two requirements from the very beginning: process redesign and economic viability. And why the business world systematically ignores both.

John Diebold coined the word “automation” in his 1952 book Automation: The Advent of the Automatic Factory. He was 26 years old, working at Harvard Business School on a research project called “Making the Automatic Factory a Reality.” His definition: automation is “both automatic operation and the process of making things automatic.” The process of making things automatic is part of the definition, not a separate step you take before automating. Diebold saw that automation and process redesign are the same activity, not sequential tasks, and the redesign is the automation itself. The American Management Association reissued his book 30 years later as a “management classic” with zero changes.

It wasn’t the first use of the term in industry. Ford’s vice president Del Harder had established an automation department in 1947, using the word to describe technology-driven production rate changes on the assembly line. But Diebold gave it the conceptual foundation. Automation always meant “figure out how to produce the outcome without the old process.”

Six years later, James Bright published Automation and Management (1958). He built a “mechanization profile” with 17 levels spanning from fully manual to fully automatic. His critical distinction: “islands of automation” versus “integrated systems.” An island is a standalone machine that does one task automatically. An integrated system is a redesigned process where all machines work together as a coherent whole. Bright’s research on 13 automation programs found that productivity gains varied enormously depending on integration level. Companies installed islands and called it automation. The integrated system approach, the actual redesign, was far less common.

Then, in 1990, Michael Hammer wrote the bluntest version in the Harvard Business Review under the title “Don’t Automate, Obliterate.” Companies automate broken processes and get faster broken processes. Hammer argued that reengineering, meaning complete process redesign, must come before any automation effort. He was writing 38 years after Diebold. Same argument, same problem.

Decades later, Frohm, Lindström and colleagues built a “Levels of Automation” taxonomy spanning levels 1 through 7, covering both mechanical and cognitive tasks. Their central finding: automation decisions are “often ad hoc” with “no systematic support systems guiding decisions.” Companies automate product by product, feature by feature, without ever asking whether the underlying process makes sense in the first place.

The definition has been consistent for over 70 years. Automation means redesign. The business world has a 70-year track record of ignoring that and automating whatever happens to exist today, waste and all.

2. Both Ways Automation Fails

Automation fails in exactly two ways. Both are violations of Diebold’s original definition.

The first failure is mechanization without redesign. This is Hammer’s “faster broken processes.” A company takes an inefficient, interdependent, coordination-heavy process and writes software to execute it without human intervention. The process becomes faster. It also becomes more destructive. The waste that previously accumulated across human workdays now executes in milliseconds. The sync tax that was paid in coordination meetings now compounds automatically with every API call.

This is what Bright called islands of automation. You install a robot on one station of a broken production line. Now that station produces more defects per hour. You mechanized one step of a broken process instead of automating the factory.

The second failure is redesign without economic viability. A company redesigns the process, builds the new automated system, and it works, removing human steps. But it costs more than the old process ever did. The development cost exceeds the lifetime savings. The maintenance burden is higher than the old manual process. If the break-even point never arrives, the company didn’t automate, it just spent more. It financed a more expensive way to produce the same outcome, funded by investor capital that will eventually run out. But automating doesn’t mean “replacing the human.”

This second failure is what Ludwig von Mises described when he wrote that engineering establishes causal relationships but economics determines value. Engineering can tell you “six units of A plus four units of B plus three units of C will produce eight units of P.” It can’t tell you whether producing P is the best use of A, B, and C. That requires monetary calculation. Without it, you can build something that works technically and destroys value economically.

3. Invisible Costs at Design Time

The core problem is the invisibility of future cost.

When a company considers building a new feature, the estimate includes the development cost of the feature itself. If someone proposes redesigning the underlying process first, that redesign cost gets added to the estimate. The estimate goes up. Management rejects it because it’s too expensive. What doesn’t appear in the estimate is the cost of not redesigning. Future coordination meetings have no line item, and neither do incidents caused by increasing interdependence. Engineer churn from maintenance burnout lands in HR’s budget. Recruitment costs for replacements appear in a different quarter. Slower feature delivery silently drags down revenue projections for quarters to come. Compounding coordination overhead stays completely invisible, building up until it eventually overwhelms the system.

These costs are real and they hit the budget eventually. They’re just disconnected from the decision that caused them. Nobody looks at an incident response bill three years later and traces it back to the interface they decided not to redesign.

Research confirms the scale of the problem. Maintenance consumes 60 to 80 percent of total software lifecycle costs. Initial development represents only 20 to 35 percent. Over a system’s full life, maintenance costs run 2x to 4x the original development investment. The annual maintenance burden averages 15 to 25 percent of initial development cost per year. Researchers have known these numbers for decades. Barry Boehm published Software Engineering Economics in 1981 with a cost estimation model that accounts for these factors. It has existed for 45 years. It is still not the basis for architecture decisions.

The Software Engineering Institute at Carnegie Mellon built a formal cost benefit analysis method for linking architectural decisions to business goals, quality attributes, and dollar costs. Despite being published and peer-reviewed, almost nobody uses it.

So the pattern holds. Decision time reveals the cost of redesign but hides the cost of not redesigning. The visible number gets added to the estimate, and the estimate gets rejected. The invisible cost compounds silently until it shows up as maintenance burn, churn, and incidents years after the decision-makers have moved on.

In one company I worked with, leadership pushed features and top-down priorities aggressively, quarter after quarter, with no room for redesign. The result was years of accumulated tech debt that made every new feature take longer, cost more, and break more often than the one before it. Nobody wanted to pay for the redesign. But they ended up paying for it anyway, just in a different currency: slower teams, angry customers, burnt-out engineers.

4. Why Engineers Don’t See the Economics

The gap between engineering and economics is a structural failure in three dimensions, not a knowledge gap.

Education. Engineering degrees don’t teach economics applied to software, or they don’t emphasize it enough. The curriculum treats engineering as a discipline of causal relationships: inputs produce outputs. Economics is a separate department. An engineer learns Big O notation for algorithm complexity but never learns the equivalent for operational complexity or the economic consequence of architectural decisions. The same engineer can calculate an O(n squared) algorithm but cannot see an O(n squared) architecture in coordination costs.

Incentives. Organizations reward shipping features. They measure velocity, throughput, tickets closed. Activity metrics, not financial ones. A team can ship more features while building the wrong things. Viktor Cessan’s research found that engineers rarely know what their work costs, and even when someone knows, the number rarely enters prioritization conversations. The incentives reward output, not outcome.

Cost information. When an engineer designs an interface between two modules, the cost of that decision compounds across years. Tight coupling creates coordination meetings that consume engineering hours at a real dollar cost. The engineer at the whiteboard doesn’t see that number. Neither does the CEO approving the feature. That cost data exists but never gets connected to the design moment.

The result is what organizational structure predicts about architecture. A 2008 MIT/Harvard study found that organizational structure is a stronger predictor of software modularity than any conscious technical decision. Your org chart determines your architecture. Your architecture determines your costs. And nobody is calculating those costs at the moment the org chart or the architecture is decided.

Cross-team work confirms this empirically. Research on cross-team coordination shows that dependencies across teams significantly increase merge times compared to single-team contributions. The coordination friction is real, measurable, and it’s a direct cost. But it shows up as “velocity is down this quarter,” not as “our interface decision from two years ago is costing us three times the engineering hours per feature.”

Here’s what this looks like on the ground. Engineers start suffering the tech debt, the increased incident rate, the chore work and coordination meetings filling half their days. They keep at it because that’s what the job has become. Eventually they get tired of doing chores instead of real engineering and quit. Or they get frustrated enough that they become toxic and get fired. Either way, the company pays again: recruitment costs, knowledge loss, team disruption, slower output for months after each departure. The invisible cost has a body count. It’s just not in the budget meeting.

5. Convenience Problems and Economic Limits

Ludwig von Mises wrote in Human Action that every decision is a choice about convenience. Humans act based on their value scale, and that value scale is unique to the decision’s moment. They choose what’s more valuable to them over what’s less valuable. Value is subjective and not only monetary. But the calculation of whether something is worth doing requires comparing what you give up to what you get.

Mises also established that technology and economics answer different questions. An engineer can tell you the causal chain: given these inputs, this machine will produce that output. An economist can tell you whether producing that output is the best use of those inputs. Without both, you can make a rational technical decision that’s an irrational economic decision.

The platinum bridge is the classic example. Engineering can design and build it, but it can’t tell you whether the community is better served by a platinum bridge, a steel bridge, or no bridge at all. Answering that requires knowing what else those materials and labor hours could produce, plus prices and economic calculation.

In software, the same logic applies. An engineer can tell you that adding a middle name field to the user module is a minor schema change. An economist, or an engineer thinking economically, would ask: what does it cost to maintain this field forever? What does it cost to coordinate the change across all consumer modules? What other work are the engineers not doing while they’re implementing or maintaining this over time? Is there real customer demand for middle names, or is someone just trying to look productive?

The software companies I’ve seen skip these questions entirely. They see a feature request and estimate only the implementation cost, skipping maintenance, coordination, and opportunity costs entirely. They make a technical decision without the economic half of the equation.

When Human Action teaches that people act for convenience, it means they choose based on what they can see and value. If the redesign cost is visible and the non-redesign cost is invisible, the convenient choice is to skip the redesign. Not because anyone is irrational, but because the value calculation is working with incomplete data. The decision-maker isn’t choosing revenue over structure deliberately. The structure’s absence doesn’t show up as a cost until much later, when it’s disconnected from the decision that caused it.

This brings us to a parallel that engineers already know but rarely apply to operations. Engineers learn Big O notation to describe how an algorithm’s resource consumption grows as input size grows. O(n) means linear growth. O(n squared) means quadratic cost growth. The notation tells you today that your future is bad, even when n is small.

A parallel concept applies to engineering operations, but nobody teaches or measures it. What grows is the number of interdependent components, specifically interdependent ones. Not modules with clean interfaces that evolve independently. Modules that share data, call each other directly, or require coordination to change.

When n interdependent modules grow, coordination cost grows with it. This is why a small company can survive with a disorganized architecture and a larger company can’t. At five people and two modules, the coordination cost is trivial. At two hundred people and fifty interdependent modules, every feature touches multiple teams. Every change requires a meeting. Every meeting consumes hours that could’ve been spent building something more valuable for paying customers.

The multiplier effect is real. A company with high interdependence pays a high tax on every feature, every incident, every hire, and every departure. The tax compounds as the company grows. The same architecture that worked at the startup stage becomes the primary cost at the scale-up stage. And the company never saw it coming because nobody was measuring interdependence as a cost multiplier.

This is the operational equivalent of Big O and interdependence is the exponent. Clean interfaces reduce the exponent and undefined interfaces increase it. The difference between O(n) and O(n squared) is the difference between sustainable growth and a company that drowns in its own coordination costs.

6. AI Industry as a Case Study

The current AI industry is the largest-scale demonstration of automation without economic viability in history. OpenAI and Anthropic (among others) burn billions of dollars on compute infrastructure, research talent, and operational costs, automating processes and building systems that can generate text, code, images, and analysis without human labor.

The question that Mises would ask: is the output worth more than the input?

If revenue exceeds cost, the automation is economically viable. It generates more value than it consumes over its full lifecycle. The company can sustain itself and grow. If revenue doesn’t exceed cost, the automation is simply making broken economics faster instead of better. More users mean more compute cost per interaction, and more automation means more loss per unit of time. The company artificially survives only as long as investor capital keeps flowing.

This is the Hammer principle at a scale Diebold, Bright, and Hammer couldn’t have imagined. They were thinking about factory production lines. The AI industry is the same structural problem with billions of dollars on the line. Building AI models that cost more to run than they generate in revenue is mechanization of an economically unviable process. The capital will run out, and the economics will catch up.

The AI companies are an extreme case, but the pattern is universal. Every company adding a feature without redesigning the underlying process is doing the same thing at a smaller scale. A company that automates without asking whether it pays for itself is burning capital their team could use more productively. The principle is the same whether the bill is five billion dollars or five developer days.

7. What the True Definition Requires

Automation, properly defined, has two legs. Both must hold.

First, process redesign. Automation means redesigning the system so the process produces outcomes without the old coordination structure. This means identifying the natural boundaries, defining clean interfaces, and making modules autonomous enough that they don’t require constant negotiation. This is what Diebold meant by “the process of making things automatic.” Bright called it integrated systems over islands of automation. For Hammer, it meant obliterate, don’t automate.

Second, economic viability. The redesigned system must produce more value than it costs over its lifetime. Development cost plus maintenance cost must be lower than the value generated. If the redesign costs more than it saves, or if the automated process burns money faster than the manual one, that’s value destruction, not automation. Mises meant this when he said engineering establishes causality but economics determines value. The 60 to 80 percent maintenance ratio tells the same story: the design decision locks in most of the cost.

A company that skips the redesign mechanizes waste. The broken process runs faster, and the coordination overhead compounds automatically.

If a company skips the economic calculation, it builds a machine that consumes more value than it produces. The capital runs out and the market corrects the error. The only question is whether the correction happens quietly through a failed product or spectacularly through a failed company.

A company that does both has automated something. Redesigned for outcomes, the process no longer preserves the old way of working. Economics justify the investment. That company becomes more efficient, more profitable, and more resilient.

The definition of automation has been clear since 1952. Diebold wrote it, Bright refined it, Hammer screamed it, and Boehm quantified it. Mises gave it the economic foundation.

And the business world has spent 70 years ignoring it. Companies automate tasks instead of processes. They calculate development cost instead of lifecycle cost. They reward shipping features instead of sustainable economics. Neither engineers nor designers receive cost data at decision time. They measure velocity and call it productivity while the maintenance budget silently consumes the company.

The solution is more discipline applied across the board: redesign the process before you automate it, calculate the full cost before you commit to it, and treat every architectural decision as an economic decision because that’s what it is. Treat every interface as a cost multiplier because that’s what it becomes. And see automation not as making the computer do the work, but as restructuring the system so it produces the outcome efficiently.

The elevator doesn’t need a robot pulling the lever. It needs a new way to operate, and that new way has to pay for itself. Automation that doesn’t redesign the process or justify its own cost is just waste running on electricity, and it’s not going to sustain itself forever.

References

1. Diebold, J. (1952). Automation: The Advent of the Automatic Factory. D. Van Nostrand. Reissued 1983 by AMACOM as a management classic. Wikipedia, AMA reissue listing
2. Harder, D.S. Ford Motor Company Automation Department, established 1947. The term “automation” was coined at Ford in this period for automatic material handling. Wikipedia: Automation, Assembly Magazine
3. Bright, J.R. (1958). Automation and Management. Harvard University, Division of Research, Graduate School of Business Administration. Introduced the 17-level mechanization profile and the concepts of “islands of automation” vs. integrated systems, based on 13 automation program case studies. Full text
4. Hammer, M. (1990). “Reengineering Work: Don’t Automate, Obliterate.” Harvard Business Review, July-August 1990, pp. 104-112. HBR
5. Frohm, J., Lindström, V., Stahre, J., & Winroth, M. (2008). “Levels of Automation in Manufacturing.” Chalmers University of Technology. Taxonomy spanning levels 1-7 for both mechanical and cognitive task automation. ResearchGate
6. Mises, L. von. (1949). Human Action: A Treatise on Economics. Ludwig von Mises Institute. Establishes that engineering determines causality while economics determines value. Mises Institute
7. Boehm, B. (1981). Software Engineering Economics. Prentice Hall. Foundational work documenting that maintenance consumes 60-80% of total software lifecycle costs, with the COCOMO cost estimation model. Wikipedia
8. Software Engineering Institute, Carnegie Mellon University. Cost Benefit Analysis Method (CBAM), extending ATAM to link architectural decisions to business goals and quality attributes with economic analysis. SEI CBAM
9. Cessan, V. “The Economics of Software Teams: Why Most Engineering Organizations Are Flying Blind.” Engineers and their managers rarely know the fully loaded cost of engineering work. viktorcessan.com
10. MacCormack, A., Rusnak, J., & Baldwin, C.Y. (2008). “Exploring the Duality between Product and Organizational Architectures: A Test of the ‘Mirroring’ Hypothesis.” Harvard Business School Working Paper 08-039. Found that organizational structure is a stronger predictor of software modularity than conscious technical decisions. HBS
11. Uplevel Team. “How to Reduce Cycle Time.” Analysis of cross-team coordination overhead, with senior engineers reporting 25-50% of time blocked on cross-team dependencies. uplevelteam.com