Two recurring manual tasks each cost your team about an hour a week today. One's frequency grows in proportion to the number of services you run; the other is fixed no matter how large the estate gets. Why does SRE's definition of toil treat those differently, and which do you attack first?

## The criterion that does the real work Of the criteria that define toil, "grows at least linearly with service size" is the one that turns an annoyance into an argument. Manual, repetitive and low-value describe how the work *feels*. Scaling with the service describes what it *does to you over time*, and that is what a manager can be shown on a chart. The distinction is the same one you would draw about algorithmic complexity, applied to human time. Some operational cost is O(1) in the size of the estate: the weekly ops review, the monthly key rotation for one shared credential, the quarterly audit form. Some is O(n): a certificate renewal per service, an access grant per customer, a manual release per deployable, a capacity check per cluster. Both cost an hour today. Only one of them has a slope. ## Doing the arithmetic out loud The reason to carry the numbers is that they change the decision. Suppose the O(n) task is one hour per week across the estate you have now, and the estate grows 50% a year: ``` year 0: 1.0 h/week (~52 h/year) year 1: 1.5 h/week year 2: 2.3 h/week year 3: 3.4 h/week year 4: 5.1 h/week (~265 h/year, ~0.13 FTE) ``` At a doubling rate it is far worse — an hour a week becomes sixteen hours a week in four years, which is not "a nuisance", it is a hiring request. Meanwhile the fixed task has cost exactly 52 hours a year the entire time. And this is one task. A team typically carries several O(n) items at once, and they compound, which is why teams that never fix the slope find that adding services stops being possible long before the infrastructure runs out. The tell in a real organisation is a launch queue: new services waiting because operations cannot absorb them. ## The decision, with its cost Attacking the scaling task first is the right default, but state the cost honestly, because the fixed task is usually the cheaper win. Structural fixes to O(n) toil are rarely a script. Per-service certificate renewal is fixed by automated issuance and rotation being the platform default, not by a better renewal runbook. Per-customer access grants are fixed by self-service with an approval path, not by a faster ticket template. That is weeks of work touching systems other people own, with a negotiation attached. The fixed task, by contrast, is often an afternoon. So the practical answer is about *priority*, not sequence. Take the cheap fixed win if it is genuinely an afternoon and it removes an interrupt — interrupt reduction has value beyond the hours. But do not let a queue of cheap wins substitute for the structural fix, because that is the failure mode: a team that spends two years automating easy things while the slope quietly eats it. ## When the scaling task is not the priority Three honest exceptions, and being able to name them is what separates a considered answer from a recited rule. **The growth curve is flat over your horizon.** If the estate is not growing — a mature product, a system being sunset in a year — then O(n) with a constant n is just O(1), and the slope argument evaporates. Check the actual growth rate rather than assuming it. **The scaling factor is not service count.** Sometimes the multiplier is customers, regions, tenants or data volume, and those grow at completely different rates. "Scales with growth" means growth of the thing that drives the task, and getting that wrong inverts the ranking. **The fixed task is a risk, not just an hour.** A once-a-quarter manual production change that nobody remembers how to do is worth automating or documenting on risk grounds even though its time cost never grows. Time is not the only axis. ## What the interviewer is checking That you distinguish the cost of work today from its trajectory, and that you can defend a prioritisation with an estimate rather than a feeling. The weak answer is "automate both, obviously" — true and useless, because the team has capacity for one of them this quarter. The strong answer names the growth rate, does the multiplication, picks the one with the slope, and says out loud what it costs to go after the harder target first.