When Automation Meets Resistance

A few months ago, I was deep in an ops project, trying to figure out how to drive automation adoption—the kind where you dream of cutting hours off repeat tasks and freeing your team up for the stuff that actually matters. Then came the pushback. “It’s too complex.” “Manual is faster.” And the classic—“We’ve always done it this way.” If you’ve spent any time in ops, you know that chorus well.

Whenever I face a new challenge, my first instinct is to automate. I’m an ops enthusiast, and the potential to streamline workflows and save time is irresistible. The moment I hit a process that eats time or bottlenecks a release, I want to reach for a script or a workflow. I wish I could say that always works out—sometimes my urge to build gets ahead of actually listening. The honest truth is, more than once I’ve missed the context—the real-life shoulder shrugs and “but what if it breaks?” talks in the hallway.

“It’s too complex to automate.” That’s the first brick in the wall. It doesn’t just mean the code is hard. It means people see risk, not just hassle. There’s comfort in manual steps, even when they’re tedious, because every command is visible, every error is handled in real time. Complexity, in this kind of conversation, isn’t just a technical term. It’s a signal for fear, for the sense that automation will turn a controllable process into something nobody can debug when it fails.

Then comes inertia—and the work to overcome resistance to automation. That phrase carries a kind of authority in ops, like repetition equals safety. Six months ago, when I first set up the project, I leaned into existing habits, thinking I was respecting tradition. Truth was, I was letting routine stand in for progress.

So here’s the pivot that changed things for me: automation isn’t just about efficiency—it’s about transformation. The win comes when you help people trust the change, not just tolerate the tool.

Diagnose the Real Blockers

Objections to automation rarely center on lines of code or orchestrations. What people actually worry about is risk—who owns what, whether things will break quietly, and how to recover fast. When you start assigning clear owners, documenting methods, and naming technology vendors, you give teams a structure to talk about risk directly. Suddenly, the objections are concrete, and you can work with them.

More than any technical sophistication, the real differentiator is how you build trust in automation. People sign on when they believe a system will handle real stress and bail them out if things go sideways. Even letting folks tweak the output of an imperfect system—just a little—boosts their trust and buy-in. It’s not about perfection; it’s about proving the automation makes daily life easier, not harder or more opaque.

If someone can correct the result themselves, suddenly the bot feels like a tool—not a threat. You can almost see the shift: anxiety quiets, folks start asking for more, and the “let’s wait and see” crowd turns into “can we automate this too?” Invite hands-on adjustment. Commit to quick rollbacks. Trust grows fast when people feel included and not overwritten.

I’ve pushed automations in the past and assumed, job done—why wouldn’t the team adopt what I made? That never works. If you don’t help shepherd people through the new workflow, all you get is a tool nobody trusts or bothers to use. Shipping the code isn’t the finish line. Leading the behavior change is.

Here’s how to drive automation adoption: go slow enough for people to believe what’s changing, and fast enough that they see the win. Small wins build trust, and trust turns skeptics into advocates, paving the way for a culture of innovation.

How to Drive Automation Adoption: The Method for Immediate Wins

Pick a task so painful that everyone agrees it drags—something like repeating the same deployment step or logging tickets by hand. Keep it tiny. The trick is, zero blast radius. If things go sideways, you can fix it instantly and nobody loses sleep.

Before automating anything, nail down how bad the current state really is. Mark the start and finish on this manual process a few times—actually time it, count the steps, note the mistakes. Get your “before” locked, because if you don’t baseline ruthlessly, any win later will look like smoke and mirrors. A timestamp, a checklist, one ugly metric—whatever proves the pain is real.

Don’t drop the baton at deployment. Be there as folks start using your automation. Write docs that are direct and short—no wall of text, just how to survive the first run. Offer to pair with anyone struggling or curious. You’ll see friction you didn’t anticipate, and the fix usually takes five minutes if you’re present. I still, embarrassingly, forget this step sometimes and end up fielding panicked DMs a week later.

When you see the first unprompted adoption—a user runs the tool without you nudging, or someone references stats in chat—close the loop. Communicate automation wins by celebrating out loud. Summarize what changed, document the before/after, and tee up the next tiny step for tomorrow. Keep momentum visible.

Make Change Tangible: A Practical Walkthrough

Let’s stop with theory for a second. Pick one process—even just your on-call handoff. We’ll walk it through the playbook right now.

Let’s get real about that on-call handoff checklist. Old way: open a doc, paste in notes, message the new on-call, double-check the calendar, ping in Slack. It feels fast when you’re in the groove, but add it up over a month and you’re losing half an hour every week—not to mention missed steps after long nights. We automated it: one button to generate summaries, auto-ping the next engineer, archive the doc. First week, total time dropped by 70%.

Yes, the first run took five minutes to learn, but by week two, nobody wanted the old manual doc back. If you ever catch yourself thinking “It’s faster to do it manually,” check the clock after a few cycles—you’ll see the delta, and so will the team.

Default behaviors are stubborn, but you can nudge them. Set your new workflow as “opt-out” instead of “opt-in”—make the easy path the automated one. Put up a visible dashboard so folks see the handoff is done, no more DM chase-downs. And let your early adopters show how it’s done. That on-call handoff I mentioned before—these little visible wins change expectations for what “normal” looks like. The habits shift from there.

Make Wins Compound: Building the Automation Flywheel

Here’s the real magic in automation. Every visible win cuts future skepticism down to size and builds appetite for the next change. When the team sees a process get easier, they start associating automation with fewer headaches, not more risk. It’s a flywheel. The first success makes the next ask simpler, because trust compounds. Suddenly, what felt like a threat—losing control, introducing complexity—becomes a sign that better is possible. That’s the mindset shift you want. Automation isn’t replacing good habits; it’s reframing how we build them.

Keep the momentum. Update runbooks so the automated path is the default, helping increase automation adoption. Circle back and compare how things worked before versus now—a quick sit-down or a post-mortem—so everybody sees the shift isn’t just technical, it’s cultural. The change sticks when the team stops asking “should we automate?” and starts asking “what’s our next win?”

Your move: Identify one task you can automate this week. Start small, show the impact, and get the flywheel turning.

There’s still one thing I haven’t sorted: sometimes, the urge to automate takes over before I’ve fully absorbed the why behind people’s resistance. I’m working on that. Progress, not perfection.