The short answer: yes. But it requires a different kind of mindset.

The challenge of the monolith

Monolithic systems are often large, complex, and the result of years of evolution. A single change in one part of the system can trigger unexpected side effects elsewhere. So we test again. And again. Until finally… no one dares to release.

The result? Long waiting times. Risk-averse behaviour. Frustration among users and teams. Still, more and more organisations want to apply DevOps principles, even in these monolithic landscapes.

Why?

Because the promise of faster feedback, true ownership, and higher customer satisfaction is just as relevant here. Perhaps even more so.

What Gene Kim and Steven Spear teach us

In The Unicorn Project and Wiring the Winning Organisation, Gene Kim shows that acceleration and improvement do not depend on technology alone. They are the outcome of social and organisational design.

He describes three essential principles:

• Simplification: reduce complexity so work becomes manageable and changeable.
• Slowification: take time to slow down intentionally, reflect, and build robust solutions.
• Amplification: strengthen signals from the system, including errors, feedback, and opportunities, so teams can respond faster.

In a monolithic context, these principles are not optional. They are survival tactics. The more complex the system, the greater the need to simplify, slow down deliberately, and listen carefully to what the system is telling you.

The three layers of organisational change

Gene Kim also describes three distinct layers where improvement can occur:

• Layer 1 – The technical object
  The level of direct work: writing code, running tests, fixing defects.
• Layer 2 – Tools and instruments
  The structures that support the work: build pipelines, test automation, monitoring systems.
• Layer 3 – The social circuitry
  The often overlooked layer: how people collaborate, share knowledge, discuss failures, and challenge assumptions.

DevOps transformations often fail because the focus stops at Layer 1. You introduce CI/CD or new tooling, but if people still need manual approvals (Layer 2) or do not feel safe to speak up (Layer 3), the system remains stuck.

In a monolith, changing Layer 1 is often difficult. The code is old, large, or tightly coupled. Upgrading Layer 2 can also be slow and costly. But Layer 3, the social circuitry, is where you can begin right away:

• Change the conversations you have.
• Review incidents together, not to assign blame but to learn.
• Ask questions without judgement.
• Take ownership of the whole, even if you can only change a part.

Connecting to the Five Ideals of Gene Kim

• Locality and simplicity
  Simplify and assign ownership per domain. Even within a monolith, local decision making builds autonomy.
• Focus, flow and joy
  Flow does not just come from automation, it emerges from collaboration. Limit work in progress, protect focus, and joy follows.
• Improvement of daily work
  Improvement should be part of everyday work, not an afterthought. Create moments to slow down and learn. Your system becomes safer and smarter.
• Psychological safety
  This is the foundation of Layer 3. Without safety, people hide problems instead of solving them. There is no sustainable DevOps without this.
• Customer focus
  In a legacy environment, the customer can feel far away. By amplifying feedback through metrics, support channels, or real user stories, you reconnect teams with purpose.

So how do you start?

DevOps in a monolith means:

• Creating domain level ownership, even within a shared codebase.
• Investing in test automation and build pipelines to rebuild trust in change.
• Building time for reflection: stop running, start improving.
• Strengthening the social wiring between teams instead of protecting silos.
• Having the courage to simplify, even when it feels risky.

And maybe most importantly:
Focus on the layer where you do have influence.
Not every organisation can move to microservices overnight, but every team can begin improving collaboration, ownership, and flow, starting today.

In the end

DevOps is not a final destination. It is a way of working that helps deliver value faster, more safely, and with more joy. Even in a monolithic environment, teams can grow in ownership, collaboration, and continuous improvement.

The journey does not begin with tooling. It begins with behaviour. Not with microservices, but with people. And that might be exactly what your system and your organisation need right now.

Get in contact with Connected Movement.