Automate what you have decided. Augment what you are still deciding.
The useful line between automation and augmentation is not how clever the software is. It is whether the decision underneath the task has stopped moving.
Most arguments about what software should take over are really arguments about how good the software is. That is the wrong axis, and it produces automation that breaks and augmentation nobody uses.
Two different offers
Automation and augmentation get bundled together because they are sold by the same companies in the same sentences. They are structurally different offers and they should be evaluated differently.
| Automation | Augmentation | |
|---|---|---|
| What it removes | The doing | The searching and the drafting |
| Who decides | The rule, once, in advance | You, every time |
| Payoff shape | Small saving, very many times | Larger saving, fewer times |
| Failure looks like | Silence: it stopped and nobody noticed | Noise: a bad suggestion you can see |
| Requires | A decision that has stopped changing | A person still making the decision |
| Ongoing cost | Maintenance | Attention |
The row that does the most work is the last but one. Automation is a bet that a decision you have already made will keep being the right decision, made unattended, many times. Augmentation makes no such bet, because a person is still in the loop deciding.
The stability test
So the question to ask about a task is not whether software could do it. Increasingly the answer to that is yes, and it is not informative. The question is whether the judgement inside the task has settled.
Three questions, in order
- Has the rule changed in the last six months? If it has, automating it now means encoding a rule that is still moving, and you will discover the drift by finding the damage.
- Would you notice within a day if it stopped? If not, the failure mode is silent, and silent failures are how automation turns from a saving into a liability.
- Is the exception rate under about one in twenty? Above that you have not automated a task, you have created a queue of exceptions plus a new system to maintain.
These are deliberately conservative. That is because the costs are asymmetric: an augmentation that does not help wastes a little of your attention, while an automation that quietly does the wrong thing for two months produces work you now have to find and undo.
What automation actually costs
The saving from automation is easy to calculate and usually correct. The cost is not on the same page as the saving, so it gets left out.
Maintenance
Every automation is attached to at least two systems that will change without asking you. Interfaces move, permissions expire, formats drift. Something you set up and forgot is something that will fail on a date you did not choose.
Silent failure
The dangerous automation does not stop. It carries on with a subtly wrong input, producing plausible output, for as long as nobody checks. The cost is not the downtime; it is the period of confident wrongness before discovery.
Lost visibility
Doing a task by hand is also how you notice it is changing. Automate it and you keep the output and lose the signal, which is why automated processes tend to drift out of fit with reality without anyone feeling it happen.
None of this argues against automating. It argues for automating fewer things, more deliberately, with a way of knowing they are still running. In practice that means a rule we would apply to any automation worth keeping: if you would not notice it failing, add something that would notice. A weekly summary you actually read is enough. Nothing is not.
Where augmentation earns its keep
Augmentation is a worse deal on paper. It saves less per use, it requires you to stay present, and it produces output you have to check. In exchange it does not require the underlying decision to be stable, which turns out to cover most interesting work.
The tasks where it pays are the ones with a wide search space and a cheap verification step. Producing a first draft you will rewrite. Getting six candidate approaches when you would have thought of two. Turning a mess of notes into a structure you then correct. Reading something long and telling you where in it the part you need is. In each case the tool is doing the expensive-to-produce and cheap-to-check half of the work.
The inverse tells you where it fails. If verifying the suggestion requires you to do the work anyway, or if a wrong answer is expensive and not obviously wrong, augmentation is not saving you anything. It is moving the effort from producing to auditing and adding the risk that you audit less carefully than you would have produced.
The dangerous middle
The failures we would expect to see most often are not at either end. They are tasks that look stable and are not.
A task looks stable when the rule has been the same for a while, the exceptions are rare enough to feel like noise, and nobody has recently had to think about it. All three of those are also true of a task whose rule is about to change for a reason nobody has told you about yet, and the automation you build on it will keep applying the old rule faithfully and silently. This is where the phrase “it worked fine until” comes from.
Three markers we would treat as warnings, none of which are about the software:
- The rule lives in one person's head. If nobody has written it down, it has probably been changing gradually and the change is invisible.
- The exceptions are handled informally. A one in twenty exception rate that someone quietly absorbs is not a one in twenty exception rate. It is an unknown rate with a volunteer.
- The output goes somewhere nobody reads immediately. Automation into a place with a slow feedback loop maximises the window in which a silent failure can run.
A sequence that works
The ordering we would defend, which maps onto the five stages we use to describe a workflow stack, is that automation comes late and never first.
-
Do it by hand, and watch yourself do it
You cannot automate a process you cannot describe, and describing it accurately almost always reveals that it is not the process you thought. This step is not preparation for automating. It is the step where most of the saving is found.
-
Remove the steps that should not exist
Deleting a step is free, permanent, and better than automating it. Automating an unnecessary step makes it cheap to run and therefore permanent, which is the opposite of what you wanted.
-
Augment while the rule is still moving
Where judgement is still involved, put the tool beside the decision rather than inside it. You keep the visibility, and you find out what the rule actually is by watching which suggestions you reject.
-
Automate only what has stopped changing
And automate the narrowest possible version of it. A small automation that handles the clean case and hands you the exceptions is more durable than a large one that tries to handle everything and fails in a way you cannot see.
-
Give it a way to be noticed
A notification, a log you read, a weekly count that would look wrong. Then review it on a schedule, because the rule that was stable when you encoded it will not stay stable, and you have just removed the mechanism that would have told you.
Read as a whole, the argument is not that automation is risky and augmentation is safe. It is that they answer different questions, and the question is not about the tool. It is whether the thing you are about to hand over has finished being decided.