Remember when DevOps was supposed to break down walls?
It was a movement, not just a methodology. A promise that developers and operations would finally work hand-in-hand, shipping value faster, safer, and smarter. No more throwing code “over the wall.” No more ops folks getting paged at 2AM for things they had no hand in building.
Instead, we got a new title.
“DevOps Engineer.”
And just like that… the wall was back.
The Original Vision
DevOps was born out of frustration:
- Developers couldn’t ship without Operations.
- Operations couldn’t support what they didn’t understand.
- Releases were painful, manual, and filled with guesswork.
Then came infrastructure as code, pipelines, and continuous delivery. Suddenly, a single engineer could deliver a full slice of value—code, infrastructure, monitoring, tests—all the way to production.
For a moment, we were living the dream:
Cross-functional, empowered product teams with shared ownership.
Then Came the "DevOps Engineer"
But instead of enabling developers to own more, we added a middleman.
“Let’s hire a DevOps engineer.”
Which usually meant:
An Ops engineer in a new costume, still the one holding the pager, managing the CI/CD pipeline, and maintaining the Terraform modules.
Meanwhile, app devs kept shipping code and creating tickets.
We recreated the wall—just with shinier tools and cooler job titles.
DevOps ≠ Ops++
Let’s be clear:
DevOps is not a team. It’s a cultural shift.
It’s about shared responsibility across development and operations. Not shifting the burden. Not offloading hard things.
Yet here we are—again—with DevOps engineers doing Ops work, and app devs waiting for green pipelines. Silos have returned, just with new labels.
Enter Platform Engineering
And now we’re seeing the rise of Platform Engineering.
Done well, it’s a game-changer.
Done poorly, it’s DevOops 2.0.
The idea of an internal developer platform is powerful:
- Common paved paths
- Certified infrastructure modules
- Golden pipelines
- Reusable patterns
But let’s be careful.
A platform is not a team that takes responsibility away.
It’s an internal product. A practice. A self-service toolbox built with empathy.
Platform engineering should be inner-sourced, not offloaded.
Built alongside the teams using it, not in a vacuum.
Treat it like an internal cloud with APIs, docs, support, and SLAs.
Not like a vending machine where developers throw a ticket and wait.
Embracing the Cognitive Load
Yes, understanding application development and infrastructure is hard.
And yes, cognitive load is a real problem.
But here’s the thing:
Avoiding it doesn’t solve the problem—it just shifts responsibility.
When developers sidestep infrastructure and delivery concerns, that burden doesn’t disappear.
It lands on someone else’s plate—usually a DevOps or Platform engineer—who may have less context about the app, its dependencies, or its business logic.
We shouldn’t run from the hard stuff.
We should build shared muscle around it.
- Owning infra doesn’t mean being on-call 24/7.
- Writing pipelines doesn’t mean reinventing Jenkins from scratch.
- Understanding how your code hits production doesn’t require mastery—just participation.
We don’t need every developer to know everything. But we do need every developer to care.
And caring means being willing to engage with the system holistically—from pull request to production, from cloud resource to customer value.
The Last Excuse: Gone
Let’s be honest—part of what sustained the silos was the belief that no one could possibly do it all.
- "I’m not an infra person."
- "Pipelines aren’t my thing."
- "I just want to write frontend code."
But now?
AI has leveled the playing field.
With tools like:
- GitHub Copilot filling in code scaffolding,
- Cursor guiding development in real time, and
- Agentic tools like Windsurf orchestrating complex workflows…
…we no longer have the excuse that one person can’t manage the full stack.
AI isn’t replacing engineers. It’s amplifying them.
A single engineer, with the right mindset and tooling, can:
- Build infrastructure as code
- Deploy a service with observability baked in
- Write tests, pipelines, and documentation
- Ship product faster than a team of siloed specialists ever could
We’ve never been more empowered to deliver end-to-end.
Now is the time to lean into true ownership—with AI as our co-pilot, not our crutch.
The DevOps We Were Promised
It wasn’t just about YAML, Terraform, or CI/CD.
It was about empowered teams delivering value with autonomy, confidence, and shared accountability.
We’ve come too far to go back to throwing things over the wall.
Let’s stop saying DevOps and doing Ops.
Let’s build the future we signed up for.
What’s your experience been like? Are you building platforms that enable—or isolate? Have you seen the cognitive load turn into a team’s superpower? I’d love to hear how others are navigating this.
