When I am handed a list of work to automate, I look at what to remove before what to add. Everything on the list usually looks plausible. It repeats, it takes effort, it appears to follow rules. But two or three of those items become a headache later if you let them in. Spotting which ones is about half the job of setting the scope of a build.
I did not always work this way. I used to receive a list and tell people we could do all of it. Which was true — we could. It took a few rounds of being burned to learn that what you can do and what you should do are different things. I now use four criteria for cutting, and every one of them is a scar.
One more thing: the list is usually longer than the real work. Once automation comes up, every annoyance anyone has been carrying surfaces at once. That is not a fault. But annoying and well suited to automation are different qualities, and if you take the list as given and build all of it, half will go unused.
The first is work whose rules are about to change.
There was a task that came round every month and took real effort — a textbook candidate. It was all but decided to be in scope. Then I asked, almost in passing, how long the rules had been the way they were. It turned out the client’s own policy was mid-revision and would change again within six months. A list does not record that. A list records the name of the task and how long it takes.
Had we built it, we would have built it twice. But rebuilding is not really the expensive part. The real cost is the months where the rules have changed and the output still comes out under the old ones. A person notices something is off. A system does not doubt itself; it carries on. And those months of output are usually never reviewed again. By the time someone finds it, what needs fixing is not one system but every document that went out in the meantime.
The second is work that happens once in a while.
I was once asked to automate a task done quarterly that took two days each time. It was genuinely hard — he told me it cost him a weekend every quarter. The problem was what came after we built it.
An automation you use once every three months is broken in some small way every time you open it. In the gap, a form changed, or the person responsible changed, or a linked file moved. If opening it costs you half a day of repairs, you have saved nothing. And after three months you no longer remember how to use the screen either. What runs often stays alive by being used; what runs rarely dies of neglect. So for that one we went with a well-made checklist instead. It only took two days down to a day and a half, but it does not break.
The third is work whose rules nobody can put into words.
Ask how a decision gets made and sometimes the answer is "I just know when I see it." That does not mean there is no expertise. There is — it simply has not been put into words yet. With people who have done something for fifteen years, the judgement is usually in exactly this state.
Automate that too early and you are not discovering the rule, you are inventing one. I did it once. The criteria would not come out clearly, so I picked a line that seemed reasonable to me and built it in. A few weeks later it was running as though it had always been that company’s standard. The frightening part is that if it is wrong, nobody finds out. Everyone starts asking the system, so the original you would have compared it against is gone.
For work like this I reverse the order. First we collect actual decisions that were made. Ten recent ones has generally been enough. Ask, case by case, why it went that way, and three or four criteria come out as sentences — criteria the person did not know they had. Automation comes after that.
The fourth is work where efficiency is not the point.
Some customer-facing correspondence is worse for being faster. There are places where a reply that takes a day and visibly came from a person beats one that arrives in three minutes. That is especially true with long-standing customers. I have watched people be quietly disappointed by a fast answer.
This is not a technical question but a question of what the company lives on. Ask, and founders usually know which kind it is. It just does not make it onto the list, because the list sees work as frequency and hours and cannot see whether that piece of work is where a relationship is made.
Having written all this, I notice I have only talked about cutting — and raising cuts is not an easy thing to do from the selling side. A smaller scope is a smaller invoice. I could not bring myself to say it the first few times either. But one feature that gets built and never used costs more afterwards. If one thing is unused, nothing else is trusted; when one part is wrong, people start checking the rest. So now I lead with what to cut in the first meeting.
Cutting is not discarding, though. Work we cut stays on the list with a note about the condition for revisiting it. Add it once the rules have been revised; add it once ten decisions have been collected. Without that note, cut work is simply forgotten — and six months later the question comes back as "why was that never done?" If the reason for cutting is not written down, I will not remember it either.
There are exceptions. Some work has to go in even when you know the rules will change, because leaving it out ties up a person for hours every day. In that case we build it, but separate out the part that will change, so that when the rules are revised we swap one piece. Rebuilding the whole thing and swapping a piece are completely different jobs. The catch is that this requires predicting where the change will land, and that prediction is wrong often enough. Making sure a wrong guess costs only one piece is the best I can currently do.
One thing runs through all four. The cost of automation does not end when you finish building it; it accrues over the period it runs while wrong. Build effort goes on the quote. This cost goes nowhere. Which is why the decision to cut earns more than the decision to add. What you did not build cannot break.
So when we set scope, these are the four I check first.
One. Is there any chance the rules for this work change within a year? If so, cut it. Adding it once things settle is not too late.
Two. How many times a month does this come round? If it is once a quarter, a checklist beats an automation.
Three. Can the person making this judgement state the criteria as sentences? If not, we collect cases first.
Four. If this got faster, would the customer be pleased or sorry? If sorry, a person keeps doing it.
Only work that passes all four goes in. Which makes a first build smaller than people expect. I have been told more than once that the smallness is unnerving. But the ones that started small went further in the end. The real risk in a first build was never too few features; it was an unused feature slipping in and making the whole thing untrustworthy. Starting small also makes the second round easier to raise. When the first thing is actually running, the next scope is a discussion rather than a pitch.
Whether these four are the complete list I still do not know. It started as two, and one got added each time I was burned. When a fifth arrives, I will add it then.