Why Automation Estates Only Ever Grow

Open your automation account and count them.

Most founder-led businesses that have been automating for three years have somewhere between twenty and eighty active workflows. The founder can confidently explain about six.

Some have names like Copy of Zap 14. Some were built by a contractor who's no longer around. At least one was built by you at eleven at night to solve something urgent, and you couldn't now say what it fires on or where its output lands.

Now ask the real question — which of these could we switch off tomorrow — and there's no answer available.

The ratchet

Here's what makes an automation estate different from every other asset in your business.

Everything else gets pruned, because somebody can look at it and judge it. An unused tool gets cancelled. A stale document gets deleted. A process nobody follows gets quietly dropped. The judgment is cheap because the evidence is visible.

An automation resists that judgment. To remove one safely you have to prove what would break — and the proof requires knowing what it touches, which was never written down, because it was built in twenty minutes during a bad week by someone solving a different problem.

So the honest answer to should we turn this off is always I'm not sure, and the safe answer to I'm not sure is always leave it.

Building is cheap and reversible-feeling. Removing requires evidence nobody has. That asymmetry is a ratchet, and ratchets only turn one way.

Which means the estate has no mechanism for getting smaller. Not a bad habit — a missing mechanism. Nothing in the system can shrink it, so it grows monotonically for as long as the business exists.

Why nothing gets documented

The second half of the mechanism is about when automations get built.

They're almost never built during a planning session. They're built at the moment of friction — something is annoying, somebody has twenty minutes, and a workflow appears. That origin is exactly right, and it's precisely why nothing gets written down: at the moment of building, the entire design is present in the builder's head, and writing it down would feel like narrating something obvious.

Then the knowledge decays on a schedule. Two weeks later the builder could reconstruct it with effort. Three months later they remember it exists. A year later, or after they leave, it's an opaque object that does something.

What the sprawl actually costs

The cost isn't the workflows. It's four things downstream of not being able to read them.

You stop improving the systems underneath. Renaming a field, restructuring a pipeline, changing a form — all become risky operations, because you can't enumerate what depends on them. So the business stops changing the things automations sit on, and that stagnation gets blamed on the tools.

Silent duplication. With no map, the natural response to a new problem is to build a new workflow. After three years you have several touching the same record for overlapping reasons. Some of them fight. The symptoms are strange, intermittent and extremely hard to diagnose — which is the most expensive kind of bug a non-technical team can own.

Departure risk. When the person who built most of it leaves, the business inherits an estate it can't read. The practical response is a slow, expensive rebuild of things that were already working.

You become the only viable owner. Nobody else can be handed the estate, because handing it over requires explaining it, and the explanation doesn't exist. Automation was supposed to reduce dependency. Undocumented automation manufactures a new one.

That last point is the one worth sitting with, because it's the exact inversion of why you started.

The register, and why it's boring on purpose

What's missing isn't documentation in the full sense. Nobody needs a specification.

What's missing is a register — one row per automation, with five facts.

1. What fires it
2. What it does, in one sentence
3. What it touches
4. Who owns it
5. What would break if it stopped

That fifth column is the load-bearing one, and it's the one that never gets filled in — which is exactly why removal is impossible. A register without it is an inventory. A register with it is a decision tool.

Add a sixth if you want the fastest possible win: date built, and by whom. Anything built more than eighteen months ago that nobody has touched since is either genuinely load-bearing or entirely forgotten, and the register tells you which in about a minute.

Don't do the audit

Here's the part that determines whether this actually happens.

The instinct is to schedule an audit — a day to go through all forty and document them. That audit will not finish. It fails for exactly the same reason the documentation never happened in the first place: it's a project, projects compete with delivery, and delivery has deadlines.

So adopt one rule going forward instead:

An automation isn't done until it has a row.

Then backfill opportunistically. Whenever anybody touches an existing workflow for any reason — fixing it, changing it, investigating it — they add its row before they leave.

The estate documents itself in about a quarter, in the order that reflects what actually matters. Because the things you touch are the things that matter, and the ones nobody has touched in eighteen months are exactly the ones you'll eventually be removing.

Build the systems as you do the work, not instead of the work. The register is the smallest possible version of that instruction.

What "load-bearing" actually means here

The fifth column — what would break if this stopped — sounds like a formality until you try to fill it in. Most people can't, for most of their workflows, and that inability is the finding rather than an inconvenience.

There are three honest answers, and each implies something different.

Nothing would break; some things would be manual again. That's the majority, and it's a legitimate state. These are the convenience automations. They're worth keeping while they work and they need no monitoring, because a silent failure costs somebody twenty minutes.

A client would notice within a week. Onboarding sequences, status updates, anything client-facing. These need a heartbeat — an expectation check saying this should run roughly this often — because the multiplier on a silent failure is every client in the window.

Money or data would be quietly wrong. Anything touching invoicing, anything writing to a system of record. These need reconciliation rather than a heartbeat: count what should have been processed against what was, and alert on the gap. This is the smallest category and the only one where the failure isn't recoverable by noticing late.

Sorting forty workflows into those three buckets takes an afternoon and gives you a monitoring plan for free. It also tends to reveal that the estate is more load-bearing than anybody assumed, which is usually the moment the register stops feeling like admin.

The quarterly question

Once the register exists, run it once a quarter with a single question: what can go?

You'll find candidates immediately. Automations pointing at tools you no longer use. Workflows for processes that changed a year ago. Three that do variations of the same thing.

That review is the only mechanism that makes the estate capable of shrinking. Without it the count only ever climbs, and every increment makes the next build harder to reason about.

Half an hour, four times a year. That's the entire maintenance layer, and almost nobody has it.

Why this is an architecture question, not a tidiness one

It would be easy to read all of this as an argument for being more organized. It isn't.

Automation shouldn't be a tool — it should become a teammate. And a teammate whose job nobody can describe, who can't be reassigned and can't be let go, isn't one you'd have hired.

The deeper version: the moment you let systems carry weight, you start being the architect. But being an architect means being able to describe the structure. An estate you can't describe isn't architecture — it's accretion, which is what you get when you keep making individually correct decisions with no view of the whole.

That's the distinction the Automation pillar turns on. Efficiency asks how can I do this faster. Leverage asks should I even be the one doing this at all. An undocumented estate answers the first question forty times and quietly makes the second one unanswerable, because you can't hand over something you can't explain.

Start this week

If your estate is under twenty workflows, the register is a spreadsheet and an afternoon. Do it now, before it's eighty.

If it's already large, don't audit. Add the rule — nothing ships without a row — and backfill as you touch things. In three months you'll have documented the half that matters, which is the half you were going to touch anyway.

Then ask the question you currently can't answer: what could we switch off tomorrow?