Toil

The concept exists to make a specific category of work visible and countable, because it is otherwise absorbed silently until a team has no capacity for anything else.

The defining characteristics: it is manual, repetitive, automatable, tactical rather than strategic, devoid of enduring value, and — the decisive one — it scales linearly with service growth. That last property is what makes it a structural problem rather than an annoyance: a team spending 20% of its time on toil at current scale will spend 40% at twice the scale, and eventually all of it.

Examples: manually approving routine access, restarting a service on a known alert, running the same report, provisioning through a ticket, applying the same configuration change per environment, and triaging an alert that never indicates a real problem.

The practice is to measure it as a proportion of team time and cap it — a common target being below 50%, with the excess treated as a signal to invest in automation rather than to hire.

The distinction worth preserving: not all operational work is toil. Incident response, design, capacity planning and postmortems are strategic and valuable. The test is whether doing the work today makes it less likely you will do it again tomorrow. If not, it is toil, and the correct response is to remove the need rather than to become efficient at it.