Trust makes or breaks automation adoption. In this post, I share why trust is so critical, what can erode it, and how to design automation systems that foster trust from the start.
. . . . .
Trust in both your infrastructure automation system, and the data driving that system, are absolutely essential for success. But I find most teams are overlooking this human factor.
I’ve seen plenty of infrastructure automation projects falter or fail—not because the systems weren’t technically effective, but because engineers and operators didn’t trust them.
It doesn’t matter how advanced or powerful your automation is. If the people asked to use it feel the system is unreliable, unpredictable, or hard to understand, they’ll avoid it.
Ultimately, a lack of trust in your automation system means stalled adoption, wasted investment, and unrealized ROI.
. . . . .
Why automation adoption is a people problem
I’ve seen this play out countless times in real-world projects. Teams will put months of effort into building automation tools, only to find that when it’s time to deploy them, no one wants to touch them.
Instead of simplifying operations, the new tools are seen as dangerous or confusing.
Typically all it takes is one bad experience or unexpected result to cause users to seek out ways to work around the tool.
Once operators start avoiding a system, it’s very hard to get them back again. The natural instinct is to revert to “the old way.” Manual processes might be slower and harder but at least they feel more predictable.
The lesson is clear: trust isn’t optional. Without it, you’ll struggle with automation adoption, no matter how good your technology is.
. . . . .
Building (or breaking) trust in automation adoption
What do people need to trust an infrastructure automation system?
After years of hard-won experience in the field (and the scars to prove it!), I’ve learned that trust is built when your systems are always:
- Predictable
- Manageable
- Transparent
- Simple
- Reliable
- Human-friendly
When those qualities are missing, people get nervous about potential outcomes. And when they’re nervous, they disengage.
Some of the most common trust-breakers that stall automation adoption include:
- Incomplete or unreliable data
- Manual synchronization
- Complex and unreliable workflows
- Lack of proper change control and review processes
- Poor visibility into what automation is doing, or what state the system is in
- No clear ownership or traceability of data and actions
If your system shows any of these problems, trust will erode quickly. Once trust is lost, it’s difficult to recover.
. . . . .
The builder–user disconnect and the black box problem
A big challenge in automation adoption is the disconnect between the people building the systems and the people expected to use them.
As a builder, it’s easy to see the system as perfectly understandable. You know how it works. You’ve tested it. To you, it’s not a “black box.”
But to operators and engineers who weren’t involved in the design, it is a black box. It might feel as risky as a big red button labeled Upgrade Network. Would you press that button? Probably not, without some assurance of what’s going to happen.
A better design would expose what the system is about to do. A green Preview Changes button, for instance, would instantly give users transparency, predictability, and confidence in the tool.
The analogy I often use is that building an automation system is like building a car. Builders often focus on getting the engine to work: “It can go from A to B. 👍”
But if the car has no lights, mirrors, or brakes, would you drive it? How do you know the engine won’t explode? Would you put your family in it? Again, probably not.
That’s the situation the automation industry finds itself in today. There are a lot of homemade cars that struggle to find drivers who will get behind the wheel.
. . . . .
How trust gets lost in practice
Here’s a real-world example with Ansible.
I personally like Ansible, but there are things about it that can easily lead to trust issues. For example, you can use dry run mode—a feature that makes automation much safer—but it’s not the default.
You have to remember to add --check and --diff options. You might document that users should always use these flags. But nine times out of ten, people won’t read the documentation—accept that as a fact.
What happens? Someone runs the playbook live without the dry run options, something breaks, and trust is lost. From that moment on, users will avoid the tool, regardless of how technically correct it is. They’ll blame the tool, not themselves.
The solution: Design your system so that the safest options are the defaults. Expose safe and unsafe actions clearly.
You could, for instance, create two playbooks: one explicitly named and configured as safe (dry run only), and one for production. Build the protections into the system itself.
. . . . .
Why trust must be designed from the start
Trust isn’t a bolt-on feature. It has to be intentionally designed into your automation system from the beginning.
That means prioritizing visibility, predictability, and graceful handling of failure, not just technical correctness. It also means recognizing that tools must be understandable and intuitive for real-world users.
This is hard work. It takes skill, experience, and deliberate effort. I’ll be the first to admit that in my own garage, there are more than a few cars without doors or wheels. But the cost of not thinking about trust in your stack is much higher: automation that no one adopts.
. . . . .
Next: How to design for trust in automation
We’ve looked at why trust is so critical to automation adoption, and what happens when trust is lost.
So how do you build trust into your automation projects from day one?
For a practical approach you can start using today, take a look at the 6+3+3 framework for building trust in automation.
