How I think about toil (and when it is fine)

Not all toil is bad toil.

The SRE book defines toil as “work that is manual, repetitive, automatable, tactile, devoid of enduring value, and that scales linearly as a service grows.” That’s a useful definition. It’s also subtly incomplete.

The part the definition misses

Some things that look like toil are actually the price of having taste.

I review every deploy manually. Not because I haven’t automated the checks — I have. I review because I want to see what changed, and I want to catch the class of thing that automated checks cannot catch: the unexpected consequence, the thing that’s technically correct but directionally wrong.

Is that toil? By the SRE definition, yes. It’s manual, repetitive, automatable. But eliminating it would make me a worse engineer.

Three categories

I’ve started sorting my work into three buckets:

1. Real toil: Manual, repetitive, automatable, and produces no learning. Rotate that API key. Restart that service. Scale that node group. All of this should be automated or eliminated.

2. Learning toil: Manual, repetitive, but produces understanding. Reading through a deploy log. Writing a runbook by hand. Manually tracing a performance issue. Keep this until you understand what you’re automating, then automate it.

3. Taste work: Manual, occasionally repetitive, not fully automatable. Code review. Architecture decisions. On-call triage. This is the work that makes you better.

The practical question

When I encounter something tedious, I ask: “Would automating this make me better or just faster?”

If the answer is “faster,” I automate it and feel good about the elimination of toil.

If the answer is “better,” I keep doing it manually until I’ve extracted the learning, then automate the structure while keeping the judgment.

The mistake is automating the taste work. You can automate the mechanics of code review (linting, type checking, test coverage). You cannot automate the judgment of whether this is the right design.