Why the best engineers have an extremely low tolerance for unnecessary work.
It’s funny how the same story keeps repeating itself in engineering.
When SRE started becoming more visible outside Google, I was already working as a Unix and Linux sysadmin. Back then, SRE was nowhere near as widely known in the industry as it is today.
Even though my title said sysadmin, I always did a lot of development. Shell scripts, KornShell, Perl. I studied the subject, read the books, took the courses, and taught it too.
And I remember saying something that probably sounded strange at the time:
One of the reasons I was good at my job was because I was lazy.
I simply couldn’t stand doing the same activity over and over again.
If I had to do something once, fine. But the second, third, or fourth time, my brain immediately went to the same place: why am I still doing this manually?
That’s why I started automating so much of my work. Years later, when I began studying SRE more deeply, I realized something interesting: what I’d been doing almost instinctively was actually a core part of the SRE mindset.
SRE practically gives you permission to be lazy.
Lazy about the right things
To be clear, I don’t mean lazy in the sense of not wanting to work. And it’s not procrastination either — procrastination defers the work, and it comes back tomorrow, usually bigger.
This is the opposite. You pay more upfront so the task stops existing: four hours today to delete it from every future week. I mean being lazy about repeating work that a machine could perform for you.
One of the central concepts in SRE is eliminating toil: manual, repetitive, automatable operational work that scales with service growth and creates no lasting value. Toil isn’t “work I don’t enjoy.” It’s work that’s structurally disposable — a human executing a solved problem.
And once you name it, you can’t unsee it.
If I need to apply the same patch to dozens or hundreds of servers, why would I do that by hand? If I need to provision servers repeatedly, why would I log into a console and click the same buttons every time?
I’ve worked with AWS for many years, and I genuinely can’t remember the last time I created a server manually through the console. It’s probably been around seven years. Even for a throwaway test, my instinct is Terraform, the AWS CLI, CDK, or some other form of automation.
Creating it manually just feels like toil to me.
Automation doesn’t mean less work
Here’s the important clarification.
When I say automation lets you work less, that isn’t really true. In practice, you may end up working even more. The difference is that you work on different things.
You stop spending your time repeatedly executing a problem that’s already been solved, and you spend that capacity solving a new one.
This is something the industry has often sold incorrectly around DevOps, CI/CD, and automation. For years we heard: “With DevOps, we’ll need fewer people.” “With CI/CD, everything gets faster.” “Once the pipelines exist, there’ll be less work.”
That’s not exactly what happens. What changes is the nature of the work.
You no longer need someone pressing the same buttons every day. You need someone who can build, improve, maintain, and evolve the systems that press those buttons. The skills change — and so does your delivery capacity.
Without automation, maybe you deliver 1x in your first year. Two years later, after getting genuinely good at that manual process, maybe you’re at 1.1x or 1.2x, because you learned to press the buttons a little faster. There’s a hard physical ceiling on that model.
Automation creates leverage. Now you deliver 2x, 3x, 4x — not because you learned to do the manual work four times faster, but because you stopped executing every individual unit of work yourself. You built something that repeats it for you.
That also changes the kind of engineer you become. You stop being the person who knows the sequence of steps and become the person who can turn that sequence into a system.
Being honest: laziness paid off
I’ll be very honest with you, because this isn’t just a nice theory I like repeating.
Back in 2018, while I was at IBM, I got tired of the same deployment work being done by hand across three completely different platforms — VMware, AWS, and Power. Same steps, different consoles, over and over. So I built a set of automations to handle it.
It wasn’t a heroic project. It was me being lazy in exactly the way I’ve been describing: refusing to keep executing a problem that had already been solved.
That work ended up selecting me as one of the few engineers worldwide to receive the Best of IBM award.
Best of IBM, Bahamas, 2018 — and finding my name on the honoree wall. Old pictures, but the lesson aged well.
I’m not telling this story to brag about a trip, but because of what it says about where value actually sits.
Nobody gave me that award for executing deployments faster than everyone else. The recognition came from removing the need to execute them manually at all. The manual work was invisible — expected, unmeasured, absorbed by whoever was on shift. The system that replaced it was visible, reusable, and kept paying out long after I stopped touching it.
That’s the leverage difference in one sentence: executing work gets you through the week; eliminating work compounds.
But don’t automate blindly
This doesn’t mean automating everything.
Automation has a cost. It takes time to build (at least doing it right — though AI is making that part easier), test, and maintain. And bad automation can cause damage at a scale a human doing the task by hand never could — that’s exactly why release engineering leans on canaries, gradual rollouts, and instant rollback. The blast radius of a broken script is the whole fleet.
So maybe the question isn’t “Can I automate this?” A better question is:
“Is this worth automating?”
You can put rough numbers on it — compare the recurring cost of the toil against the cost of building and owning the automation:
If a task takes five minutes and happens once a year, doing it manually may be the smartest engineering decision available. Being lazy also means not spending three weeks building automation to save five minutes.
That said, frequency isn’t the only variable. Some tasks deserve automation even when they’re rare, because a human doing them under pressure at 3 a.m. is the actual risk. Failover, restore-from-backup, and cert rotation qualify. Runbook automation there isn’t about saving minutes — it’s about removing the human error path from incident response.
The better question: does this work need to exist?
And there’s an even better question:
“Does this work need to exist at all?”
Sometimes the best automation is no automation. You change the system and remove the need for the task entirely.
That gives you a progression worth internalizing:
Don’t repeat. Automate. And before automating, ask whether you can eliminate the work entirely.
A ticket queue for provisioning becomes a self-service platform (level 2). A service that needs manual restarts every Tuesday becomes a service that doesn’t leak memory (level 3). Level 3 is almost always the better investment — and almost always the one nobody has time for, precisely because everyone is busy doing level 1.
This mindset doesn’t have to stop at infrastructure, either.
Think about meetings. I still like jotting a few keywords in my notebook by hand. What I don’t want is to spend another thirty minutes afterward rereading everything, extracting action items, creating tickets, and turning discussion into tasks. The meeting ends, the transcript already exists, and I can pull the relevant parts out and turn them into structured work.
Again, this doesn’t mean the engineer disappears. Quite the opposite. Judgment stays human. Decisions stay human. What we’re removing is the mechanical work surrounding those decisions.
The takeaway
That’s exactly what I mean when I say SRE encourages a lazy engineering mindset.
It isn’t about doing less work. It’s about having an extremely low tolerance for unnecessary work. It’s about looking at a repetitive task and asking, honestly: why am I still doing this?
A good engineer becomes extremely efficient at performing a task.
A better engineer finds a way to never perform that task manually again.
And the laziest engineer of all asks the best question of the three:
“Why does this task exist?”
This week, pick one thing you did more than twice. Decide whether to automate it, or delete the need for it. Then tell me which one you chose — I read every reply.
Want to go deeper on toil, automation, and SRE practices? Check out the trainings at mugnos-it.com.
Cheers,
Douglas Mugnos
MUGNOS-IT 🚀
Written by Douglas Mugnos, reviewed by “douglas-agent” 🤖
