By now, we’ve explored how Everything as Code gives structure to our systems and how Immutability helps ensure consistency and reliability. But there’s an underlying truth we can’t ignore – tools and practices alone aren’t enough. Culture is the foundation that determines whether technical initiatives succeed or stall.

Without the right mindset, even the most elegant Infrastructure as Code repository or the most robust immutable pipeline will eventually fall victim to shortcuts, misalignment, or entropy. At Coremont, as with many organisations on a platform engineering journey, we’ve found that culture and the challenges of shaping it, are where the hardest work lies.

In this final part of the series, we’ll explore why culture matters, what challenges often arise, how we’re addressing them at Coremont, and where we see opportunities for growth.

Why Culture Matters

Culture defines how teams think about problems, how they work together, and what they value. When you aim to establish Everything as Code or Immutability, you’re really asking people to change how they build, deploy, and operate systems. That’s a big ask.

For example:

  • A developer used to quick fixes on live systems might struggle with the discipline of writing a pull request, waiting for review, and rolling out through automation.
  • A team that’s used to manual changes in production might feel blocked by a “no-click-ops” policy.
  • A culture where speed is celebrated but quality is overlooked can clash with initiatives that emphasise correctness, review, and consistency.

Culture either accelerates or resists these kinds of changes. If we don’t address it head-on, we end up with a mismatch: great tooling that no one wants to use, or that’s bypassed at the first sign of trouble.

This is why so many transformations stall, not because the technology is flawed, but because the human side hasn’t kept pace.

Cultural Challenges in the Broader Tech Landscape

Across the industry, adopting Everything as Code and Immutability often brings cultural hurdles. These aren’t unique to any one organisation—they’re part of the broader shift from traditional ways of working to more structured, automated, and scalable approaches.

– The legacy mindset

Many engineering teams, especially in established environments, have years of tools, scripts, and habits built up over time. Changing to a declarative, code-driven model requires unlearning well-worn patterns.

This can show up in subtle ways:

  • Requests for manual changes “just this once” because the code path seems slower.
  • Teams duplicating scripts instead of investing in reusable modules.
  • The perception that code-driven infrastructure is best suited for greenfield projects, rather than complex, evolving systems.

– Fear of breaking things

Adopting immutability and automation demands a high level of confidence in the tooling. Without trust in the pipeline, teams may hesitate — leading to environments that are only partially automated.

This fear can be triggered by:

  • A lack of trust in new pipelines during their early adoption.
  • Limited observability, where teams can’t easily verify that changes are safe.
  • Past incidents where automation was involved, even if it wasn’t the root cause.

– Fragmentation of standards

In large and diverse organisations, teams may naturally evolve in different directions. One group might adopt GitOps practices while another relies on ad hoc tooling. This divergence can introduce friction:

  • Multiple teams solving similar problems in incompatible ways.
  • Redundant effort and inconsistent outcomes.
  • Barriers to collaboration, onboarding, and governance.

– The balance of autonomy and alignment

Giving teams ownership over their services is critical to innovation and velocity. But without some common ground, too much autonomy leads to inconsistency and complexity. Finding the right level of standardisation remains a common industry challenge.

Where We Are Today

Coremont continues to embed platform engineering principles across teams, translating vision into day-to-day practice. While no transformation is instant, we’re building on a strong foundation and accelerating adoption in ways that scale.

Foundations in Place

  • Shared vocabulary:Terms like pipeline, merge request, immutable artifact, and declarative configuration are now part of everyday conversations across teams, enabling consistent communication and alignment.
  • Embedded support:Our Platform SRE team works directly with service teams, providing tailored guidance and hands-on support to integrate platform practices effectively.
  • Demonstrated impact: Projects such as Clarion have fully embraced automated and immutable deployments — resulting in faster recoveries, reduced incidents, and growing developer confidence.

Scaling Success

  • Strengthening resilience: Teams are increasingly relying on automated pipelines, even in high-pressure scenarios — showing growing trust in platform standards and tooling.
  • Broadening alignment: Platform conventions are being adopted across more teams. To support this momentum, we’re expanding access to reusable templates, reference implementations, and shared tooling.
  • Deepening enablement: We continue to invest in onboarding, documentation, live training, and real-world examples to help teams adopt new practices with clarity and confidence.

Additional Aspects: Enabling Cultural Change

What have we learned about making cultural change stick?

– It starts with empathy
We must understand where teams are coming from. Change is hard, especially when it feels imposed. We’ve tried to engage teams early, listen to concerns, and co-create solutions rather than dictate them.

– Education matters
Training sessions, documentation, brown bag talks, and pairing on real-world problems have all helped lower the barrier to entry. We’ve found that when people see the benefits in action, such as how a proper pipeline saves time in the long run, they become advocates.

– Celebrate wins
We’ve made a point of highlighting success stories in internal forums. When a team moves from manual deployments to a fully code-driven pipeline and sees fewer incidents as a result, that’s worth sharing.

– Make the right path the easy path
We’re investing in tooling and defaults that make the desired practices the path of least resistance. If the platform makes it easy to do the right thing say, to provision infrastructure through code and pipelines, people are far more likely to follow that path.

– Stay flexible but clear
We encourage experimentation and improvement, but we also draw clear lines where consistency matters. For example, all production changes must go through a pipeline, but how teams design their pipeline stages can vary if they meet core requirements.

Conclusion

Culture is the invisible thread that connects all our technical work. Without a culture that supports Everything as Code, Immutability, and automation, those practices won’t deliver their full value.

At Coremont, we’ve made strides in shifting mindsets; cultural change doesn’t happen overnight, it’s an ongoing process of listening, learning, and adapting. We’ll continue to refine how we support our teams, align on standards, and balance autonomy with coherence.