DevOps: Have We Left Something Behind?

I remember those early days of DevOps vividly. Back then, it felt like we were on the brink of something huge. We weren’t talking about tools or scripts, but rather people and culture. DevOps was about collaboration, breaking down silos, and creating a flow between developers, operations, and everyone in between.

But from the get-go, we saw a dissonance in the community. As soon as DevOps started to catch on, the conversation shifted from culture to tools. Suddenly, it was all about processes, automated pipelines, and scripts. Those of us on the frontlines of the Agile movement—coaches, Scrum Masters, and practitioners—were trying to hold the line. We kept saying, “No, DevOps is a mindset shift, not a toolset.” But, even then, it felt like we were losing that battle. After all, who could resist new shiny tools that promised to end the pain of manual deployments.

And here we are today.

Are we too focused on automation?

Once, I worked with a client who had set up a dedicated DevOps team. The team handled everything related to infrastructure, and they had built a stack of Terraform scripts to manage all aspects of it. Sounds great, right? Everything is automated, consistent, and repeatable.

But here’s where things got frustrating: every time our dev team needed to make a small change, like provisioning a new service or adding environment variables, we had to wait on that DevOps team. And every time, they would tell us, "We’ll update the Terraform scripts and redeploy." Days later, the simplest thing would finally get done.

What’s funny (or not so funny) is that we could’ve done a lot of these tasks ourselves if we had full access to the dev environment. The tools are there, and Infrastructure as Code (IaC) has made it easier than ever for developers to handle their own environments. But, instead, we were stuck waiting.

Here’s where focus on automation can be just a tad too much. Instead of just logging into an admin portal and flipping a switch, we were writing and deploying code for tasks that should have taken seconds or wait for someone to do something that took just a minute or two. And that bottleneck kills innovation. Yes, consistency and repeatability are critical, but do we really need to lock down development environments in the same way we handle production?

Trust used to be the foundation of DevOps

At the heart of this whole debate between tools vs. culture is one word: trust. And this isn’t some groundbreaking revelation. Quite contrary, it’s something we’ve screamed about for decades in Agile and DevOps. It’s the same broken record that keeps spinning round and round. Do you trust the developers you hired to write code that could potentially destroy your business if mishandled? Yes, you do. Then why don’t you trust them with full access to the development environment?

Development environments are supposed to be sandbox spaces—a place to experiment, to innovate, to make mistakes and learn from them. But the more layers of tooling and process we put on top of it, the more we suffocate the very innovation we’re trying to encourage. I’ve seen it again and again—developers coming up with a great idea, only to have it killed by the simple fact that they can’t be bothered to wait for someone from the DevOps team. Innovation gets bogged down because the process takes too long, so they move on to something else. The technology is there, but the trust isn't.

Automation everywhere

If you look around the DevOps world today, it seems like we’ve hit a golden age of automation; CI/CD pipelines, Infrastructure as Code, and container orchestration tools are everywhere. You commit a line of code, hit push, and within minutes, your app is running. This is what we always wanted—fast, seamless deployments happening as often as necessary.

But there’s a strange side effect, the lockdown on what development teams can do in terms of provisioning infrastructure or making changes has gotten tighter, even as automation tools have made it easier for developers to handle infrastructure themselves. Tools like Terraform have made setting up a server or creating a database a simple, repeatable task. But too often, developers still need to go through a gatekeeper, a centralized DevOps team, to make it happen.

And this, to me, creates a barrier to innovation. Sure, the time to deployment has accelerated, but the freedom to experiment in development environments has not changed or even been throttled. Until the mindset shifts—until we fully trust developers to manage their own environments—this barrier will remain.

Trust your teams to unlock innovation

And here we are calling for trust and preaching the same old story as decades ago. The tools are already in place. We’ve achieved what we’ve been talking about for decades—continuous integration, continuous deployment, and the ability to rapidly spin up infrastructure through automation.

But what’s still missing is trust. If you trust your developers to write code that could potentially break your business, why not trust them to handle their own environments? Give them full access to the development environment—let them provision what they need, make changes, experiment freely. And yes, have someone review those changes before they move up the chain to production.

The development environment should be a true sandbox. Let developers innovate without barriers and keep your focus on security when it matters—further down the pipeline.