A Ten-Minute Job Rarely Gets Reviewed

Ask an owner about last year’s tax return and the detail comes fast. The hours it took, the weekend it ate, the accountant’s emails arriving outside working hours. Ask the same person what raising, sending and chasing invoices costs them across a year, and notice what kind of answer comes back: a figure drawn from a record, or an estimate assembled on the spot. Where the annual return gets tracked and invoicing time does not, the second answer has very little behind it.

Avoidance would explain a task that gets put off, but this one gets done constantly. One explanation is that no single instance has ever taken long enough in a sitting to be worth thinking about. There are others worth checking: the work may be split across several people, nobody may be recording the time, or it may simply be filed mentally as the cost of doing business. Any of those leaves the same gap. The work runs and runs, and never makes it onto an agenda.

Much of the work that gets examined gets there because one instance hurt enough to produce a moment where somebody said this cannot happen again. A four-day ordeal once a year tends to create that moment. Ten or fifteen minutes at the end of a day is far less likely to, however many times it repeats. The cost is real, but it arrives in aggregate rather than in one sitting, and it can show up somewhere that looks unrelated, such as a quarter with very little selling in it. So the threshold for reviewing a piece of work can end up set by how much one occurrence stung rather than by what it costs over the year.

That ranking then decides what gets built. Advice that starts from the tool treats this as a capability problem, as though the load is simply waiting for the right software. But if the shortlist came out of memory, the build may be aimed at whatever was loudest recently rather than the step that runs a few hundred times a year. The case for building anything rests on what the work is actually costing you, which is why the step is worth counting rather than recalling. Memory tends to rank these tasks by how much one occurrence stung. Counting shows you which ones repeat often enough to deserve a closer look.

Counting also changes what you find. Some of it is a rule running on a schedule, and a rule can usually be written down clearly enough for software to carry it. Some of it is the same information entered twice, once where it arrived and again where somebody needed it, which is closer to the problem of numbers being gathered rather than kept. And some of it is a step producing something nobody downstream reads anymore. Only the first clearly points to a build. The other two may be better solved by changing the flow of the work first.

So alongside what takes the longest, it is worth asking what you do most often without ever stopping to look at it. Take the one at the top of that list and ask what would actually break if it stopped. That one question tends to separate the steps worth carrying by software from the ones that persist because the shape of the work around them has not been looked at.