DevOps adoption isn’t just about introducing new tools or practices.
It’s about setting a new tone in the organization.
When a DevOps transformation begins, something subtle but important is happening beneath the surface:
the organization is being asked to operate from new principles.
If those principles aren’t modeled, practiced, and socially reinforced, adoption stalls — no matter how good the tooling is.
Why a Dojo Changes the Dynamic
Calling an enablement center a dojo is not cosmetic.
A dojo carries an implicit contract:
- You don’t teach what you can’t do
- You model the behavior you expect others to adopt
- The more experienced you are, the more responsible you are for others’ learning
There’s a martial attitude embedded in the metaphor.
Practice matters. Embodiment matters. Responsibility increases with mastery.
At SAP, we didn’t start by deciding to build a dojo.
We arrived there by recognizing what the transformation demanded.
Transformation Is a Shift in Principles
A common misunderstanding is that transformation means rolling out new patterns.
In reality:
Transformation is a shift in the principles that shape behavior and culture.
The moment you try to change principles, pattern thrashing begins.
Teams attempt new approaches.
Old reflexes surface as antipatterns.
Friction increases.
This isn’t failure — it’s feedback.
The system is revealing what it’s optimized for.
A Root Principle That Exposes Reality
One principle surfaced repeatedly in our work:
Progressive exposure to risk, with automatic rollback.
It’s an attractive idea.
It’s also unforgiving.
The moment a team tries to apply it to a real application, capability gaps emerge:
- Deploy and release are tightly coupled
- Observability is insufficient
- QA feedback arrives too late
- Rollback exists in theory, not in practice
These aren’t mistakes.
They are capability gaps revealed by the principle.
You can’t mandate your way out of them.
Why Enablement Had to Be Modeled
This was a turning point for us.
If we were asking teams to operate differently, we had to operate differently ourselves.
So the enablement center was treated like a product:
- An agile backlog
- Clean user stories
- Real code
- Pull requests
- Simple pipelines
- Open, innersource-first
This wasn’t about sophistication.
It was about credibility.
Engineers could see we lived in the same system they did — not in slide decks or wikis alone.
The First Circle: Where Adoption Begins
Adoption didn’t start with a program.
It started with a circle.
An open, recurring space where people could:
- Be curious
- Ask questions
- Get unstuck
- Hear stories from peers
This attracted innovators and early adopters first — and eventually skeptics.
That mattered.
Resistance isn’t a blocker.
It’s a signal.
Those conversations surfaced real constraints long before they showed up in roadmaps.
The Role of the Belt System
Momentum accelerated when we introduced a belt-level program.
Not as hierarchy — but as responsibility.
- Entry-level belts lowered the barrier to engagement
- Visible symbols sparked curiosity and conversation
- Higher belts carried an expectation of peer mentorship
Advancement wasn’t about status.
To progress, you had to take responsibility for someone else’s learning.
That principle reshaped the social fabric more than any single workshop.
Storytelling as an Adoption Mechanism
Every engagement followed a deliberate rhythm:
- A shared story at the front
- Real work in the middle
- A retrospective on the back
When it made sense, we captured the learning in writing — blogs, summaries, shared artifacts.
But with one rule:
People had to recognize themselves in the story.
When they did, the story became theirs.
They told it to peers.
Adoption spread horizontally.
When stories are extracted or reframed for someone else’s benefit, trust erodes quickly.
This part requires care.
What Actually Made It Work
Looking back, the success of dojo-style DevOps adoption wasn’t about scale or tooling.
It came from alignment:
- Principles were explicit
- Patterns were practiced, not prescribed
- Adoption was treated as a social system
The dojo created:
- A safe place to practice new principles
- A way to surface resistance early
- A steady drumbeat that kept learning visible
That combination carried the transformation forward.
The Core Lesson
If there’s one lesson I’d carry into any DevOps adoption effort, it’s this:
You can’t ask people to change how they work unless you’re willing to model that change — visibly, consistently, and in the open.
Dojo-style DevOps adoption works because it turns transformation from a rollout into a shared practice.
That’s where real change begins.
⛩️🌿
