Two Villages and a Very Professional Wall
There were once two villages in a valley.
On one side lived the Developers.
They wrote code. They shipped features. They believed progress was measured in commits per hour.
On the other side lived the Ops tribe.
They guarded uptime. They feared outages. They believed progress was measured in how little changed.
They were not enemies. But they were not friends either.
The Developers would build something magnificent and launch it over the wall with confidence:
“It works on my machine!”
The Ops tribe would catch it, stare at it quietly, and reply:
“That is… concerning.”
Between the villages stood a large wall. A very capable wall.
- The wall had departments.
- The wall had KPIs.
- The wall had separate leadership, separate objectives, and separate bonus structures.
Developers were rewarded for speed. Ops were rewarded for stability. These goals rarely shook hands.
At the top of the wall, the chiefs sometimes met:
Chief Trumpur of Delivery and Chief Ronald of Infrastructure.
They would nod seriously and discuss improvements.
Occasionally someone proposed making the wall bigger.
“Just to clarify responsibilities.”
And so more tickets were added; more processes; more approvals.
Sometimes one tribe suggested the other should pay for it. This arrangement was considered professional.
Inside each village, unity was also… aspirational.
Among Developers:
- The Backend Guild spoke in APIs and schemas.
- The Frontend Circle debated pixels and state. They met frequently for “alignment” and usually left slightly less aligned.
Across the valley, Ops had its own clans:
- CloudOps spoke in regions and availability zones.
- SysOps guarded servers like ancient relics.
- Database Administrators believed — not entirely unfairly — that everyone else was reckless.
Each group possessed sacred knowledge. Each quietly suspected the others did not understand how fragile everything truly was.
Then one day, a prophet arrived. He spoke strange words:
- Agile.
- Collaboration.
- Shared ownership.
- Continuous delivery.
And most shocking of all:
“Why not remove the wall?”
The villages gasped.
- Workshops were held.
- Slides were presented.
- Arrows pointed in both directions.
Eventually, the wall fell. From its rubble emerged a new tribe:
DevOps.
It was a beautiful name. A new era had begun. But demolition is easier than integration.
The wall disappeared. The distance did not.
People stayed where they had always stood — only now without bricks to blame.
Questions replaced stone:
- Who owns the pipeline?
- Who approves production access?
- Who responds at 3am?
- Who broke this?
Old Man Ronald would sometimes sigh:
“At least when there was a wall, we knew whose fault it was.”
And slowly, quietly, new fences appeared. They had modern names:
- Platform Team
- SRE
- Infrastructure Service Team
The wall was gone. The instinct to rebuild it was not.
DevOps as a Concept vs DevOps as a Renamed Silo
Let’s leave the valley for a moment. A while ago, we were hiring.
We needed people with experience in CI/CD, monitoring, Infrastructure as Code, and cloud environments. Not wizards. Just engineers who understood that software does not end at git push.
What we found was… instructive.
Candidate 1
- Had “CI/CD experience” on their CV.
- It turned out they had mostly worked with Ansible playbooks.
- They had never written application code.
- They did not know what a build lifecycle looked like.
- Cloud? No.
- Monitoring? Not really.
Conclusion: In their previous company, they ran playbooks. That was the job.
Candidate 2
- Listed themselves as “CloudOps – Mid Level.”
- When we asked what that meant, the answer was: “I’ve set up EC2 instances.” Which is fine.
- But that was the extent of it.
- No discussion of networking.
- No IAM.
- No scaling considerations.
- No CI/CD integration.
Conclusion: Cloud meant “launching machines.”
Candidate 3
- Had “DevOps Engineer” in bold.
- Impressive stack. Impressive terminology.
- After a few questions, it turned out their role was mostly maintaining a Jenkins instance someone else had designed years ago.
- They could restart it. They could update plugins.
- They had never written a pipeline from scratch.
- They had never debugged a failing deployment across environments.
Conclusion: The pipeline worked. What it actually deployed was someone else’s concern.
One thing common across all interviews:
Limited participation in development, little exposure to the product lifecycle, and sometimes only a surface-level understanding of the system itself.
And this is not about mocking individuals. It is about what happens when we turn a philosophy into a job title.
The mirror image exists on the development side. For many developers, infrastructure means writing a docker-compose.yml file and hoping it requires zero understanding of networking, ports, certificates, or what actually happens once the containers leave their laptop.
Abstraction is useful. Blindness is not.
The original idea of DevOps was not to create a new role. It was to stop pretending development and operations were separate problems.
Code decisions affect operations.
Operational decisions affect code.
- Logging choices influence monitoring.
- Framework capabilities influence observability.
- Infrastructure shapes authentication, scaling, and resilience.
- Application design determines how deployments succeed — or fail.
A developer does not need to become an infrastructure specialist.
An operations engineer does not need to become a feature developer.
But neither can be blind to the other side.
Because there is no “other side.” The system is continuous.
And yes — foundations matter.
A developer should understand what a pipeline is doing when it runs.
Not necessarily how to rebuild Jenkins from scratch, but what stages exist, why tests run where they run, what a deployment actually means, and what can go wrong between commit and production.
And yes — sometimes that also means being able to tweak a Jenkinsfile, adjust a pipeline configuration, or make a small change to a CloudFormation template. Not as an infrastructure expert, but with enough understanding to know what the file is for, what it controls, and why the change matters.
Otherwise, code is written in a vacuum and surprises appear later — usually at 5pm on a Friday.
The same applies in reverse. Operations should understand what is being deployed well enough to recognise when the platform is solving a problem that the application already solved — or could solve more simply.
They should also understand what the application actually does. Not every line of code, but which modules are critical, which services carry business risk, and how configuration changes might affect behaviour.
Infrastructure decisions make more sense when you understand the system running on top of it. Some modules deserve deeper monitoring because they are business-critical. Some alerts matter more than others. Some failures are noise; others stop revenue.
You don’t need to be the person who wrote the feature.
But you do need enough context to understand what you are keeping alive.
This is not about everyone knowing everything. It is about everyone knowing enough.
Because without shared foundations, collaboration becomes ticket exchange.
And ticket exchange was exactly the wall DevOps was supposed to remove.
DevOps (Now With New Paint)
To be clear: I am not saying real DevOps does not exist.
There are certainly companies where shared ownership actually happens. Where developers understand how their software behaves in production, and operations engineers understand the applications they support. Where pipelines, monitoring, deployments, and code evolve together instead of being negotiated through tickets.
Those places exist. They are just… less common than the conference talks might suggest.
And there are engineers who naturally work this way — people who move comfortably across domains, ask questions outside their specialty, and try to understand systems as a whole instead of protecting a narrow slice of responsibility.
This is not a claim that DevOps failed everywhere. It’s a claim that many organisations kept the exact same structure… and simply changed the name.
- The wall stayed.
- The tickets stayed.
- The handoffs stayed.
Only the org chart changed. What used to be Development and Operations became something else but...new name, same queue.
And honestly, I don’t particularly care what we call it. Call it DevOps. Call it Platform Engineering. Call it Deployment Happiness Engineering if that helps morale.
But if work still crosses organisational borders as requests instead of shared responsibility, then the wall is still there — just painted a different colour.
And if the plan now is “the AI will handle it,” just remember: AI outputs are just your inputs… with confidence added.
In conclusion: now everyone agrees the wall is gone… while quietly adding new bricks: more ownership boundaries, more approval layers, more specialised silos.
We demolished the wall in theory. Then rebuilt it in Jira.
Top comments (0)