Protocol
Protect improvement time from recurring operational work
Keeping the queue moving and reducing tomorrow's queue are different jobs.
When it fits
- Recurring support tasks consume the time needed to make those tasks less necessary.
When to avoid it
- Google's published allocation target is not a universal optimum. Maintain essential coverage and examine individual overload; a comfortable team average can hide it.
Why it matters
Identify recurring operational work that leaves the system essentially unchanged and grows with demand. Measure its burden, then agree protected capacity for a specific lasting improvement. Do not label every unpleasant task as toil or assume that buying another automation tool removes the underlying work.
Steps
- Track a representative period of hands-on recurring work separately from elapsed waiting time.
- Agree a local capacity boundary and choose one improvement that could reduce the recurring burden.
- Check actual workload after the change, including maintenance and exception handling.
An example
Repeated manual export corrections consume support time. A validated input rule removes one recurring cause instead of merely making the correction checklist prettier.
Check your result
Protected time produces a measurable reduction or a clear finding that the attempted improvement did not help.
Keep this limit in mind
- Google's published allocation target is not a universal optimum. Maintain essential coverage and examine individual overload; a comfortable team average can hide it.
Connected ideas
Useful withAgree what reliability loss will pause ordinary changes
Evidence and sources
Google SRE defines toil as recurring operational work with little enduring value and uses explicit allocation limits to protect engineering work.
Not all repetitive or disliked work is toil, and Google's allocation target is an organizational policy rather than a universally optimal percentage.
Eliminating Toil · Toil Defined; Why Less Toil Is Better