Automation Debt: The Fallback You Retired by Default
Automation debt is not the messy code you inherited. It is the manual capability the automation retired. The workflow that ships takes the fallback along…
Every workflow that ships removes two things. It removes the labor, which the business case counts, and it removes the fallback, which nothing counts. The manual path is not archived when the automation goes live. It stops being practiced, and the steps then exist nowhere except in the code. Automation debt is usually described as brittle scripts and undocumented integrations. That description is accurate and it is the smaller half. The larger half is not in the repository at all. A manual process under load degrades. It queues, it makes more errors, and it keeps producing output while it fails, because the rule is held redundantly, in six heads instead of one file, and six people at reduced throughput still constitute throughput. An automated process holds the whole rule in one execution path. It runs at full rate or not at all. One engagement replaced a weekly 90-minute resource allocation meeting that consumed six senior operators, and three of the five weekly decisions are now auto-resolved. If that function stops on a Tuesday, the meeting does not reconvene at full strength. Nobody has made those three decisions by hand since it shipped. Capacity does not fall along a curve. It falls in one step. Abandonment. The author leaves, the automation keeps running correctly, and correctness is why nobody touches it. It appears in no runbook and survives every budget cycle by never appearing on one, though a production system of the kind we deploy costs $3K to $8K per month to operate. Drift. The business rule changed and the code did not: a discount threshold set for a pricing model the company retired two years ago. The automation is not broken. It throws no exception, and exceptions are how operations finds out something is wrong. Compensation is the worst of the three, because it is invisible by construction. An automation gets written to correct a defect upstream: a field that arrives blank, an amount unconverted. The correction works. The complaints stop. The defect stays. Two years later an engineer fixes the upstream error, and three downstream automations that had been correcting for it start producing wrong output. A wrong system produces a dispute, and the dispute is the alarm. These three produce none. Obsolete and load-bearing is harder than wrong. The first half of the question, how long the business runs if this stops today, has an answer somewhere. The second half, who executes it manually in the meantime, comes back blank for a structural reason. An org chart records who owns systems. Process ownership appears nowhere on the chart, and the automation dissolved the process into a system on the day it shipped. The people who performed it were reassigned by the same business case that funded the build. The question has no addressee. Run the question against ten automations and count the blanks. The ones that answer are the recent ones, where somebody still remembers the steps by hand. Memory is doing the work documentation was supposed to do, and memory has a departure date. A parallel human process is a permanent cost charged against a benefit that may never be claimed, and the fallback decays into fiction without any help. A runbook nobody has executed in eighteen months is a description, not a capability. Unpracticed insurance is not insurance. So retire it. Retire it on purpose. Right now the manual path is removed by default, by whoever merged the workflow, and a decision taken by default cannot be revisited, because there is no record that anybody made it. The response is a shipping standard, not a cleanup project. Five things ship with the next automation. An owner, named, a person rather than a queue. The rule in business language, so a director who has never opened the repository can say whether the company still believes it. A documented way to turn it off. A review date with a person attached. A written answer to the two-part question, even when the answer is four hours and nobody. Blank is the only wrong answer. The audit that opens an engagement covers what is already running, because the automations in place decide what can safely be added on top of them. We scope the ones with no answer to the second half first. Engagements run 8 to 16 weeks and end with the system running inside the business, along with a written record of what it replaced.