I like to ask my teams:
What is the cheapest resource in the Universe?
It’s a trick question because the right answer sounds clearly wrong: other people’s time. After all, we pay a lot of money for it so it’s not cheap.
And yet, it must be true given how easily we decide what others should do. Have you ever assigned a task to someone without being absolutely sure that it’s the right work for the right person? Sure you did, and so I did.
Somehow figuring it out by myself was too expensive. So I decided it’s better for someone else to handle that.
Better for me, at least.
I got an email a few months ago. I was late with a payment and now I owed an extra fee for that. It was funny because I set up automated payments, like I always do.
I reached out to the company and apparently their payment systems sometimes failed to process some charges. No, they couldn’t do anything about that. Yes, they will notify me in the future when it happens.
Now I’m getting an email every month saying that your payment might have failed, verify that before we charge you extra for our system being faulty. The original wording is slightly more reasonable, but not by much.
It is easier for them to email each of hundreds of their customers than to check for whom the process has failed. Or to fix their automation for processing payments. My time logging into their portal was free.
Not so long ago I was responsible for a service. It was running fine and meeting all the SLAs. Never bothered me for a second.
Curiously, I was paged every now and then by another team. Allegedly my service was down and was taking their product with it. It was a loud page, the kind that wakes you up at 3am. But every single time it was a false positive, which was pretty easy for me to check because my own alerts were not firing.
The product team had their own monitoring. It periodically checked on my service and when it thought it was down, I got a page. Clearly whatever they had was flaky and unreliable, but they didn’t want to change how it worked. Or maybe they didn’t know how, I never figured that one out. Instead, they wanted me to change my service so it’s more compatible with their detectors.
I didn’t have time for that so I just wrote an automation that sent their pages to trash before they reached me. No one ever complained. I guess they didn’t notice.
I run way too many VMs in my home lab, definitely more than I’m willing to manage manually, so I enabled automatic upgrades on each of them. Most of them even restart automatically on each kernel update (I know, crazy).
The worst thing about automatic updates? Sometimes they fail, not that often, but I’d like to know about that nonetheless. So when I set this up years ago, I made sure that on every failure I would receive an email. It took quite some time to tune it, so it didn’t bother me without a reason, but I figured it out.
Cut to 2026.
After years of OS upgrades, output shifting to stderr, and the good ol’ code rot, I get a bunch of emails every night. Do I read them in full? Of course not. I don’t remember the last time any of them flagged a real issue.
Had I been less lazy, I’d fix it, but for now I automated filtering them straight into trash.
I’m smart enough to write the automation but I don’t want to deal with its output, so I’ll push it downstream to someone else. If they’re smart enough too, they’ll write their automation to resolve it, ignore it, or push further to one more person.
We all tell ourselves this lie.
Good automation is terminal.
The buck stops today with the author of the automation, not with someone else—not even himself five years later.