DevOps Was Never a Method. But it Was a Discipline.

DevOps Feels Artisanal... Until It Doesn't

If you read enough about DevOps, you'll find thousands of definitions.

Some focus on culture.
Some on automation.
Some on pipelines.
Some on speed.
Some on security.

At JPSoftWorks, it took us years to stop chasing definitions and start building discipline.

Because the hardest part about DevOps isn't understanding what it means.

It's making it yours.

At first, DevOps feels artisanal.

You try things. You adopt tools. You adjust processes. You debate culture. You introduce automation. You react to incidents. You celebrate wins.

It feels organic. It also feels chaotic.

Over time, we realised something uncomfortable:

We were not lacking information.
We were lacking structure.

Not rigid methodology.
Structure of thought.

But from that discomfort, we knew that something had to change. And it was quickly replaced with a new hope.

Doing the Right Thing, at the Right Time

Early in our journey, we started to say:

"DevOps is about doing the right thing, at the right time."

That sounds simple. Almost naive.

But it hides a hard truth:

You only know the right thing after you've made your system visible. You only know the right time when you understand constraints. You only know the right intervention when you measure impact. You only know whether it worked if you revisit it.

What we eventually discovered is that DevOps is less about speed and more about sequence.

Right order. Right emphasis. Right feedback.

And above all: small steps. Reversible.

Why DevOps Isn't a Formal Method

Agile has ceremonies. ITIL has processes. SAFe has diagrams. ISO has controls.

DevOps has… conversations.

And that's why it frustrates people.

Because DevOps isn't a method you install. It's a discipline you cultivate.

Its nature is adaptive.

DevOps must adjust to:

• Your people.
• Your risk tolerance.
• Your governance constraints.
• Your technical landscape.
• Your maturity.
• Your culture.

This is also why DevOps is cultural.

Because once you start making work visible, limiting WIP, exposing constraints, mapping competence, measuring objectively, and formalising feedback: you are not just improving flow.

You are changing how people think.

Let's face it. Technology is cartesian. But adopting technology, isn't always. Bias and preferences often come to play. So we can't make this about technology first. We need to focus on the people that need it, to make the best choices.

The Six Tenets Were Not Accidental

When we began writing this series, we didn't invent a framework.

We reverse‑engineered what had actually worked for us.

1. Visibility: because invisible work destroys trust.
2. Work in Progress: because unfinished work hides risk.
3. Constraints: because effort does not equal throughput.
4. Competence Mapping: because hero culture is structural fragility.
5. Objective Measures: because opinions don't scale.
6. Formal Feedback Loops: because learning must be ritualised.

None of these are tools. None of these are platforms. None of these are certifications.

They are habits.

PDCA is the ancestor of systemic improvement. Plan Do Check Act, was the revolution of improvement of quality in manufacturing. In some ways, it is what we are doing here.

DevOps Is Cultural Because It Reorders Responsibility

Once visibility increases, blame decreases.

Once WIP is limited, multitasking stops being heroic.

Once constraints are exposed, urgency loses its emotional charge.

Once competence is distributed, ego softens.

Once metrics are objective, debates calm down.

Once feedback is formal, learning compounds.

Notice the pattern?

Each tenet is meant to reduce ambiguity. Each tenet should reduce ego. Each tenet reduces hero dependency. Each tenet increases psychological safety. Each builds on the other. It is meant as a virtuous cycle.

That's cultural change.

Not motivational posters. Not slogans.

Structural clarity.

Technology Was Never the Hard Part

We've written before:

DevOps was never "not about technology." It was about putting technology back in its place.

Automation, pipelines, infrastructure‑as‑code, observability: these are powerful.

But they are not mysterious.

Technologically inclined people can learn tools quickly.

What they struggle with is:

• Shared ownership.
• Letting go of hero status or ego.
• Accepting constraints.
• Working within WIP limits.
• Being measured transparently.
• Revisiting decisions.

Technology becomes natural when the intent is clear.

When people understand what the system is trying to support, automation stops being "magical" and starts being obvious.

Collecting Practices Is Easy. Knowing Why Is Hard.

There are volumes of good practices:

• CI/CD pipelines.
• Shift‑left security.
• Chaos engineering.
• SLO‑driven reliability.
• Platform engineering.
• Guardrails over gates.

The problem isn't scarcity of advice.

The problem is selection.

Which practice solves which constraint? Which automation supports which behaviour? Which metric reinforces which habit? Which ritual reinforces which learning?

Without clarity, DevOps becomes a buffet. With discipline, it becomes a sequence. And eventually, a ritual you own.

Psychological Safety Was Not a Side Effect

One of the biggest surprises in our journey was this:

Psychological safety did not emerge from kindness. It emerged from clarity.

When:

• Work is visible,
• Flow is controlled,
• Constraints are named,
• Competence is shared,
• Metrics are objective,
• Learning is formal,

People stop fearing ambiguity.

Fear decreases when systems are legible.

And once fear decreases, collaboration improves naturally.

Small Steps Beat Big Transformations

We have never seen a large‑scale DevOps transformation succeed because of a grand announcement. Though it helped clarify the intent.

We have seen incremental improvement succeed because of:

• Visible, deliberate experiments.
• Measured adjustments.
• Honest reflection.
• Structural reinforcement.

Small steps create momentum. Momentum creates confidence. Confidence creates adoption.

This is not glamorous.

It is effective.

As it has been often said, you need to learn how to walk, before learning to run. And here we are proposing, you should be ready to fly.

DevOps Is About Harmonising Dev and Ops: But Not Just That

The phrase "harmonising Dev and Ops" is accurate but incomplete.

It's not only about developers and operations teams.

It's about harmonising:

• Speed and stability.
• Autonomy and governance.
• Automation and human judgment.
• Innovation and compliance.
• Risk and reward.

This harmonisation does not happen accidentally.

It happens when the system is structured to support it.

As creators, we aren't naturally inclined to structure, perhaps ironically. So we need to take a step back and take a broader look at what and who we are working with here.

The Habit of Doing the Right Thing

When people ask us what DevOps really means, we no longer start with pipelines.

We say:

It is the habit of doing the right thing, at the right time, for the system. And yes, we are part of it.

Sometimes the right thing is slowing down. Sometimes it is automating. Sometimes it is redistributing competence. Sometimes it is saying no. Sometimes it is measuring. Sometimes it is reflecting. It just depends, when.

DevOps is not speed. It is timing. Sequence.

What We Are Really Proposing

This series was not a checklist.

It was a foundation.

A way to:

• Make work visible.
• Protect flow.
• Expose bottlenecks.
• Diffuse knowledge.
• Measure objectively.
• Reinforce learning.

If you do these six things consistently, the rest becomes contextual.

Tools will change. Cloud providers will change. AI will change. Regulations will change.

The discipline remains.

Closing Insight

DevOps was never about copying Silicon Valley. It was never about buying a toolchain. It was never about renaming your teams. And it's certainly not about Kubernetes.

It was about building a system that improves itself.

Not through hype. Not through heroics. Not through ideology.

But through disciplined, visible, incremental improvement.

It took us years to realise that. Despite all the knowledge being out there.

It doesn't have to take you as long.

If you want to discuss how to lay that foundation where you are: without theatrics, without dogma, but with measurable progress: we're always open to the conversation.

References