> ## Content Index > Fetch the complete content index at: https://mikegarcia.io/llms.txt > Use this file to discover other available public pages before exploring further. # Automate what your attention can't change - URL: https://mikegarcia.io/automate-what-your-attention-cant-change/ - Published: 2026-06-13T19:00:09.000Z - Updated: 2026-08-01T05:19:37.000Z - Description: The work you watch out of habit should run without you. Automation's job: make that true and hand back the attention the watching was quietly costing. - Author: Miguel Garcia - Tags: Automation, Reliability, On-Call, Engineering Culture, SRE Some work doesn't care whether you're watching. The certificate is valid until it isn't. The service is up or down on its own terms, and refreshing the dashboard at 7 a.m. casts no vote in which. You watch anyway, the tab open in your head. The question underneath the watching is the one that matters: whether this is being taken care of without you having to think about it. While you're the one watching, it isn't. Attention is the one resource you spend without tracking. Compute has a bill. On-call hours show up on a calendar. The hours you burn watching an outcome your attention can't move land on a bill or a calendar, and that's the budget you run out of first. ## Only one kind of work pays attention back Work splits by what it responds to. A cheap task can demand judgment, and an expensive one can run on a rule you wrote once. Some work responds to judgment. A failure you've never triaged, a tradeoff with no right answer, the design call where what you notice changes what you ship. Here attention is the lever. Spend more, and the outcome improves. This is the work your attention actually changes. The rest responds to persistence, or to a rule you can write down. A cert renews before it lapses. A failed batch job re-runs after a transient blip, if it's safe to replay (a half-finished non-idempotent job is judgment work). A load balancer drops a backend that stops answering its health check. The result is set by something other than how closely you watch it: a condition you already specified, or another system's behavior. What moves these is a rule firing or another system reacting, not your watching, and a machine never tires of either. One test tells you whether a thing can run without you: does your attention change the outcome? If yes, keep it. That's judgment work. If no, you're holding an open loop. The claim is easy to state and easy to get wrong, because the whole difficulty lives in the sort. You usually can't classify a task the first time you meet it. You learn whether your watching matters by watching it fail a few times. So the trigger is repetition: the second or third time you catch yourself watching the same loop resolve the same way without you. The boundary moves. Work that needed judgment last quarter becomes a written-down rule once you've root-caused it, and a rule that fit last quarter's traffic can quietly stop fitting. Writing the rule is judgment work you do once. The watching never ends. ## Watching feels like working That's the trap: staying on top of things reads as responsible. Keep an eye on the deploy. Watch the replica lag. One more dashboard refresh before standup. Each loop is easy to justify on its own, so they pile up, and none gets questioned, because the attention they consume never shows up anywhere. The cost compounds in one direction. Attention that goes to outcome-independent loops is attention missing from the judgment work that needed it. That's the operational shape of alert fatigue: pages that never needed a human hand wearing down the attention left for the page that does. The expensive part shows up later, in the judgment missing when something ambiguous arrives, because the attention was already spent on things that resolve themselves. ## Closing the loop moves the watch to the machine The effort was never the expensive part. A lagging replica takes a minute to chase; a dashboard takes seconds to refresh. If automation only bought those back, it would barely be worth the build. What it buys back is the open loop, the standing withdrawal you forgot you were paying. When you automate, the watch moves to the machine, and then something has to watch the machine. Get this half wrong, and you come out worse than before. A renewal quietly stops firing while the endpoint keeps serving a cert days from expiry, and all you've done is hide the loop where you can't see it. A closed loop proves itself on the thing that matters, checked from outside: the cert at the endpoint still has weeks of life, the backends still serving real responses. And the check has to prove its own pulse, because a check that died reads exactly like a system that's fine. Silence proves nothing. ## A working loop is one you stop hearing from A ping that says it worked steals attention even when nothing needs you. You start watching for it, or wondering when it's late. That's what a self-healing job does when it pages you to confirm it recovered. An alarm is only half an automation: the work got automated; the watching didn't. You're left listening for the ping, so the loop stays open, and the attention stays yours. The loop is only closed when there's nothing to hold in your head, when the automation stays silent through every case it can handle and draws your attention only on the one it can't. That page is the case the automation couldn't handle. Answering it is two jobs: fix what broke, and, when the case reduces to a rule once you root-cause it, fold it back so it stops reaching you. Skip that second job and the root-causable pages keep coming. The ones with no rule to write are the judgment work you keep. The same holds at scale, with one addition. The individual task leaves your attention entirely, and that's the loop doing its job. The automation itself doesn't leave your attention, because how often it fires is its own signal: a worker that auto-restarts forty times an hour is a closed loop hiding an unresolved failure. But you don't watch that rate any more than you watched the instances. You bound it too, a page when the restarts cross the line, and you move the line when the traffic moves under it. The on-call version of all this is sleep. The condition you used to wake for resolves itself, and only two things still reach you: a loop that ran and couldn't recover, and a rate that crossed the line while every instance looked fine. So start with last week. For every dashboard you opened and page you skimmed out of habit, write down the one condition that had to stay true: the cert valid, the nightly job finished, the dead backend out of rotation. Those are the loops. The ones where your watching never changed whether they held your attention or spent casting no vote. Hand each condition to something that keeps it true on its own and escalates only the case it can't fix. Every loop you close that way is one more thing handled without you, and the attention it returns refills the budget that otherwise comes up empty at the exact moment the work that needs it walks in. So before you open that dashboard again, ask what you're really after. "Is this being taken care of without me having to think about it?"