Developers Aren't DevSecOps Engineers (And Shouldn't Have to Be)

I've watched this exact scene play out at more organizations than I can name. A developer — good at their job, shipping features, nothing wrong with their work — gets handed a Terraform module and a pipeline YAML file and told, in effect, "you own this now." Somewhere in a wiki there's a getting-started doc. Maybe there was a lunch-and-learn a few months back. And the assumption baked into all of it is that this is enough to turn a feature developer into someone who can safely write infrastructure-as-code and reason about a secure delivery pipeline.

It isn't enough. It was never going to be enough. And I don't think that's a controversial thing to say once you actually watch what happens next.

What actually happens when the pipeline breaks

Here's the moment that tells you everything. A developer pushes a change, and the pipeline fails — not on their application code, but somewhere in the deployment stage. A security scan step is blocking the build for a reason the error message doesn't clearly explain. Or a Workload Identity binding isn't resolving correctly, so the pipeline can't authenticate to push an image or reach a secret it needs. To someone with years of DevSecOps experience, this is a familiar shape of problem — you've seen it before, you know where to look. To a developer who was handed this pipeline as an afterthought to their real job, it's a wall.

So they do the only reasonable thing available to them: they go looking for help. First they ask around their own team, in case someone's hit this before. Then they message the DevOps engineer, who's mid-sprint on something else. If that doesn't resolve it, they open a message to security, because the failure is in a security scanning step and nobody's sure whose problem it actually is. A question that started as "why did my build fail" turns into a half-day, sometimes multi-day, scavenger hunt across three teams — not because the developer isn't capable, but because the actual expertise required to diagnose it was never theirs to begin with.

I remember one developer in particular who lost the better part of three days to exactly this. Not because the fix was complicated — once someone with the right background looked at it, it was a five-minute change to a service account's Workload Identity binding. The three days weren't spent fixing the problem. They were spent finding the one person who could look at it and immediately know what was wrong.

Training and documentation don't close this gap

The usual response to this pattern is to invest in more enablement — a better internal wiki, a recorded training series, a DevSecOps 101 course for every developer. I've recommended versions of this myself, and it does help at the margins. But it doesn't solve the actual problem, because the actual problem isn't a knowledge gap that documentation can fill. It's an experience gap.

Terraform, IAM, Workload Identity, secure CI/CD — these aren't things you learn once and then know. They're things you get good at by living inside them, hitting the same category of failure a hundred times across a hundred slightly different situations, until you develop the judgment to look at an error and immediately know where the real problem lives. A developer who's spent their career building application features has a completely different, equally valuable kind of judgment. Expecting a training deck to install years of infrastructure pattern-recognition overnight is expecting something training was never designed to do.

What this actually costs the business

This isn't a minor inconvenience, and I'd push back on anyone who frames it that way. When I've walked leadership teams through the real cost, it comes down to three things.

Multiply that across a growing engineering team shipping regularly, and the lost time isn't an occasional inconvenience — it's a recurring tax on the roadmap. I've sat with CTOs looking at a slipped launch date and traced it back, more than once, to a developer stuck for days on infrastructure they were never equipped to own in the first place. That's not a training failure. That's a structural one.

The fix isn't more training — it's not needing the expertise at all

The organizations that get past this don't do it by turning every developer into a part-time DevSecOps engineer. They do it by removing the need for that transformation altogether. Once the secure, correct pattern for provisioning infrastructure and deploying safely is already built into the platform, developers don't need years of Terraform experience to use it — they just use it. The judgment that used to require a specialist gets encoded into the platform itself, once, instead of being something every developer has to independently acquire.

That's the same lesson from the provisioning bottleneck I've written about before: the organizations that improve delivery speed don't simply hire more platform engineers or run more training sessions. They standardize the platform itself. Once secure delivery becomes a built-in capability instead of a skill every developer has to individually develop, engineering teams spend less time stuck and more time shipping.

This is exactly what Vertro is built to do for teams running on Google Cloud and GKE. Instead of asking developers to become Terraform and DevSecOps experts to safely provision and deploy a service, Vertro provisions the Google Cloud project, IAM and Workload Identity, Secret Manager, and a secure, pre-wired CI/CD pipeline automatically — so developers ship without needing the specialized experience the platform now handles for them.