Measure the Toil Before You Automate It
Toil · June 4, 2026 · 9 min read
Ask an operations team what they would automate first and you get a fast, confident answer. It will be the most irritating task: the one with the awkward console, the one that requires chasing somebody in another department, the one that goes wrong in an interesting way. It is almost never the task that consumes the most of the team’s year — that one is usually so small and so frequent that nobody has ever thought of it as work at all.
The distance between those two answers is why automation programmes in security operations so often finish with an impressive set of integrations and a team exactly as busy as before.
What the word is supposed to mean
Toil has a precise definition and a loose one, and the loose one has almost displaced it. Loosely, toil means work people dislike. Precisely, it means work that is manual, repetitive, automatable, tactical, devoid of enduring value, and — this is the clause that carries the weight — scales linearly with the size of the thing you operate.
The linear-scaling clause is what makes the concept useful rather than merely sympathetic. Work that grows in proportion to the estate converts every future success of the organisation into a future demand on your team. Add business units, add regions, add acquisitions, and the volume arrives whether or not anybody funds the people to absorb it. Work that is unpleasant but fixed in volume is a morale problem. Work that is tolerable but linear is a solvency problem, and only the second one ends with the function underwater.
So the first sorting question is not “does anyone enjoy this?” It is “if the estate doubled, would this double?”
Measuring it without building a bureaucracy
The instinct is to instrument everything: a category field on every ticket, a time-tracking obligation, a dashboard. This fails reliably. People under load do not categorise accurately, the taxonomy is fixed before anyone knows what the categories should be, and within a quarter the data describes the form rather than the work.
Sampling beats census here. A short, bounded tally — a fortnight, everybody, every interruption written down as one line with a rough duration — gives a truer picture than a permanent tracking system nobody believes in. It is temporary, so people cooperate; coarse, so it is quick; and it captures the work that never generates a ticket, which is the work most likely to be invisible in every system you already have.
The unit that matters is not the duration of one instance. It is:
- how long one occurrence takes, end to end, including the wait
- how many occurrences there are in a period
- how many of them arrive as interruptions rather than as scheduled work
- whether the count moves with the size of the estate
Multiply the first two and you get the annual cost of a class of work. Rank the classes by that product and the ranking will not resemble the team’s intuition. Small, frequent, unglamorous items dominate. The dramatic quarterly ordeal that everybody complains about turns out to be a rounding error next to a short lookup that happens dozens of times a week.
The third item matters because an interruption costs more than the minutes it occupies: it also costs the re-entry into whatever it displaced. Two tasks of identical duration are not identical costs if one arrives on a schedule and one arrives on a pager.
The order of operations
Once a class of work is ranked, there is a hierarchy of responses, and automation sits further down it than most programmes assume.
Delete the demand. A surprising share of recurring operational work exists because somebody once asked for it and nobody has since asked whether the answer is still consumed. Reports generated and never read, checks introduced to satisfy a control that has been superseded, approvals whose outcome has never once been “no”. This work has a cost and no reader.
Fix the upstream system so the work is never created. Most operational toil is a downstream symptom of a decision made elsewhere: a naming scheme that makes ownership unresolvable, a joiner process that omits a field the operations team then has to chase, a service that emits an ambiguous condition someone must disambiguate by hand. Every instance of that chase is a tax paid by one team on behalf of a defect owned by another. The fix is usually cheap and belongs to somebody with no visibility of the cost, which is exactly why it has to be measured before it can be argued.
Move the work to whoever generates it, with a path that makes the right action the easy one. Self-service only offloads anything if the requester’s route is faster than asking you; if it is slower, they will route around it.
Then automate, knowing what you are signing up for. Automation converts a recurring labour cost into a permanent maintenance obligation. That obligation is usually worth accepting, but it is real: the automation will break when the systems it touches change, it needs an owner, it needs somewhere to report its own failures, and the mode where it silently stops working is worse than the manual process it replaced, because nobody notices an absent action.
Automation that relocates toil rather than removing it
There is a common outcome in which the work does not go away, it changes shape. A task that took ten minutes by hand becomes a job that runs unattended and costs fifteen minutes of investigation whenever it exits non-zero. The team has traded a predictable, schedulable, comprehensible task for an unpredictable one that arrives as an interruption and needs more skill to resolve.
Two tests catch this early. After the change, who is paged, how often, and does that number appear in anybody’s plan? And can the automation be switched off and the manual path resumed by someone who was not involved in building it? If not, the team has added a dependency it cannot service.
There is a floor, and it is not zero
Not all repetitive work is toil, and the difference is whether judgement is being exercised. Reading an unfamiliar situation, deciding whether something is worth pursuing, choosing which of several plausible explanations to test first — these recur constantly and are not automatable in the relevant sense, because the value sits in the decision rather than the execution. Confusing the two produces the most expensive kind of automation: a system that makes the decision badly, at volume, with an authority nobody intended to grant it. Attack the fetching, the collating, the formatting, the copying between systems, the finding of the thing to look at. The looking should stay.
What the measurement is really for
The reason to quantify toil is not to produce a slide. It is that toil is the best available leading indicator of two things that arrive later and cost more.
The first is capacity. A function whose linear-scaling work is growing faster than its headcount has a date on which it stops meeting its obligations, and that date exists whether or not anyone has calculated it. Measured toil turns it into a forecast that can be argued about in advance rather than a crisis explained afterwards.
The second is attrition. Skilled people leave operational roles for reasons that are predictable from the composition of their week. Nobody resigns over one bad task; they resign after several quarters in which nothing they did had any durable effect. The ratio of work that leaves a trace to work that is merely absorbed is a quantity you can watch move.