DevOps Was Never "Not About Technology": It Was About Putting Technology Back in Its Place

Introduction

Over the years, I've lost count of how many times I've said some version of: "DevOps is primarily a cultural change."

And if I'm honest, that message has occasionally backfired.

More than once, peers or customers inferred that technology wasn't really "my thing." That I was more interested in soft skills, facilitation, or organisational psychology than in hard systems, pipelines, and infrastructure. Nothing could be further from the truth.

I am deeply, mechanically, unapologetically technological. I learn technologies the way some people eat their cereal in the morning: routinely, methodically, without much drama. Tools don't intimidate me. Complex systems don't scare me. I enjoy them.

But after years of watching organisations fail DevOps transformations, I learned something the hard way: technology is rarely the hardest part. And when it becomes the centre of the conversation, we usually miss the real problem.

The Misunderstanding: "Culture Over Tools" as Anti-Technology

Somewhere along the line, "DevOps is a cultural change" got interpreted as "technology doesn't matter." That was never the claim: and frankly, it's a dangerous misreading.

Technology absolutely matters. Architecture matters. Pipelines matter. Automation matters. Poor technical decisions will sink you faster than any cultural misalignment.

But here's the uncomfortable reality:
most organisations are far better at buying tools than at changing how they work.

So when we emphasise culture, it's not because technology is secondary. It's because technology is easy to acquire and hard to integrate meaningfully.

I've walked into enterprises with:

• Best‑in‑class CI/CD tools
• Cloud platforms configured by experts
• Security scanners everywhere

And yet delivery was still slow, fragile, and tense. Not because the tech was wrong: but because it was layered on top of unchanged behaviours, incentives, and decision paths.

DevOps as a Mentality Retrofit

At JPSoftWorks, we often describe DevOps as a mentality retrofit.

Not a rewrite of everything. Not a revolution. A retrofit.

You're taking an existing organisation: with its history, constraints, power structures, and scars: and asking it to:

• Reduce handoffs
• Share responsibility for outcomes
• Trust automation over heroics
• Make risk explicit instead of political

That's not a tooling problem. That's a thinking problem.

DevOps challenges deeply ingrained assumptions:

• "Ops keeps prod safe."
• "Security reviews happen at the end."
• "Speed and safety are opposites."
• "Governance lives outside engineering."

Until those assumptions are surfaced and redesigned, no amount of YAML will save you.

Technology Must Fit People and Processes: In That Order

This is where my stance often gets misunderstood.

I care deeply about technology. But I refuse to treat it as neutral.

Every tool encodes assumptions:

• About who decides
• About who owns failures
• About how work flows
• About what "good" looks like

If those assumptions clash with how people actually work, the tool becomes friction, not leverage.

That's why we insist on:

1. Understanding decision paths before designing pipelines
2. Clarifying ownership before enforcing automation
3. Designing governance rules before encoding them as policy-as-code

When technology fits people and processes, it disappears into the background. When it doesn't, it becomes the thing everyone blames.

Why Technology Feels Easy: and Change Doesn't

Here's a truth most technologists recognise quietly: learning tools is finite.

You read the docs. You experiment. You break things. You fix them. Eventually, you understand the system well enough to reason about it.

Organisational change isn't like that.

People don't version‑control their habits.
Incentives aren't declared in configuration files.
Power dynamics don't fail fast with clear error messages.

This is why DevOps transformations stall:

• The pipelines are ready
• The platforms are live
• But decisions still funnel through old bottlenecks

The work that remains is human: and therefore messier, slower, and less predictable.

Failure Modes When Culture Is Ignored

We see the same anti‑patterns repeatedly:

• Tool-driven DevOps
  Teams adopt new platforms but keep old approval chains.
• Hero-centric operations
  Automation exists, but people still save the day manually.
• Security as interruption
  Controls are bolted on because trust was never designed in.

In all cases, technology didn't fail. It was simply asked to compensate for unresolved organisational tension.

Where Automation Actually Helps Cultural Change

Ironically, automation: when done right: supports cultural change instead of replacing it.

Automation:

• Removes ambiguity
• Makes expectations explicit
• Shifts conversations from intent to evidence

When a pipeline enforces a rule consistently, it stops being personal.
When governance is encoded, it stops being negotiable.

That's not dehumanising. That's stabilising.

But automation only works when the underlying agreements exist. Otherwise, it just accelerates conflict.

The Real Challenge: Reframing the Conversation

The hardest part of my job isn't explaining Kubernetes or IAM or CI/CD patterns. It's helping leaders and teams realise that the technology was never the main event.

The main event is:

• How decisions are made
• How risk is owned
• How failures are absorbed
• How accountability is distributed

Once that's clear, the technology conversation becomes refreshingly straightforward.

In Closing...

So yes: DevOps is a cultural change.
But not because technology doesn't matter.

It's because technology works best when it's designed in service of people, processes, and accountability: not as a substitute for them.

I'll happily talk tools all day.
But if we skip the mentality retrofit, we're just automating yesterday's problems.

If you've ever felt that tension: where the tech is solid but the organisation isn't ready to let it work: share your experience. And if you want help aligning technology with how your teams actually operate, we're always up for that conversation at JPSoftWorks.