When organizations adopt DevOps, they often follow a recognizable pattern. A small team in one corner of the business starts delivering high-quality software at speed. The results look good, leadership decides to scale the practice across the organization—and then things stall. Tradition, departmental silos, and cultural inertia push back hard.
Scott Van Kalken, systems engineer at F5 Networks and organizer of major DevOps events in Australia, has observed this pattern repeatedly. Drawing on a career that spans both development and operations roles, he argues that at least two foundational elements are required to break through those obstacles: collaborative team structures and a safe place to fail.
Collaboration: Tearing Down the Wall
One of the core principles of DevOps is that software does not get thrown over the wall between functions. Development, testing, security, and operations teams must understand they are working toward the same outcome—not competing for ownership of a pipeline stage.
Building that shared understanding is harder than it looks. Van Kalken points to a financial services company he worked with that was moving to a GitOps model. The service management team initially viewed GitOps as “uncontrolled chaos”—a reasonable concern from people responsible for change governance.
The breakthrough came through a series of workshops that demonstrated the underlying change management processes had not changed—only the tooling had. Approvals that used to happen on paper now happened in the repository. Service management remained the final gatekeeper; the mechanism for gatekeeping simply became version-controlled and auditable.
The lesson: cross-functional buy-in rarely comes from mandates. It comes from showing people that their legitimate concerns have been accounted for in the new model.
Creating a Safe Place to Fail
Psychological safety—the confidence that raising problems or making mistakes will not result in punishment—is a prerequisite for the iterative experimentation that DevOps depends on. Without it, teams optimize for avoiding blame rather than improving systems.
Van Kalken frames this as an organizational maturity question. A mature engineering culture acknowledges that change carries risk, then puts practices in place to manage that risk—rather than trying to eliminate change altogether.
Several DevOps practices make “safe failure” operational rather than aspirational:
- GitOps and version-controlled deployments: If a release introduces a problem, rolling back to a known-good state is a straightforward, auditable operation rather than a scramble.
- Smaller, more frequent releases: Incremental changes have a smaller blast radius when something goes wrong. A two-line configuration change that causes an incident is far easier to diagnose and revert than a three-month feature release.
- Canary deployments: Rolling a change out to a subset of users before full release limits exposure and provides real-world signal beyond what pre-production testing can offer. Van Kalken notes this technique is equally applicable in DevSecOps contexts, where limiting the blast radius of a security-related release is critical.
On release cadence, Van Kalken makes a practical point that is often missed: increasing frequency does not necessarily mean multiple deployments per day. For some organizations, moving from two releases per year to three or four is a significant and valuable step. The right cadence depends on the organization, its users, and its risk appetite.
Chaos Engineering: The Ultimate Test of Cultural Readiness
Chaos engineering—deliberately injecting failures such as killing containers or saturating network links—is arguably the most demanding test of whether an organization has genuinely embraced failure as a learning mechanism.
The technical objective is to verify that production systems can tolerate partial failures gracefully, providing confidence that goes beyond what pre-deployment testing alone can offer. But the cultural prerequisite is equally demanding: every stakeholder—developers, security teams, business owners—must understand that the goal is resilience, and that provoking controlled failures in a test context is how resilience gets proven.
“Your culture has to be OK with this iterative approach,” Van Kalken said. Organizations that still treat failure as inherently bad will struggle to get chaos engineering off the ground—and will likely struggle with DevOps adoption more broadly.
His prescription for building that culture combines education, awareness, and accumulated experience. People who have seen a fast rollback prevent a major outage, or watched a canary deployment catch a regression before it hit all users, develop a different relationship with risk than people who have only ever experienced failure as a crisis.
Measuring the Right Things
Collaboration and psychological safety can be undermined by the wrong metrics. Van Kalken describes metrics as “probably the biggest things organizations need to change” when adopting DevOps.
Traditional IT metrics—system uptime percentages, ticket closure rates, mean time between failures—measure the health of internal processes. They do not necessarily correlate with what users and the business actually care about.
He uses a straightforward illustration: a customer who ordered a pizza does not care whether the order management system maintained a 99.9% uptime SLA. They care whether the pizza arrived on time. When it did not, the right response is a collaborative, analytical investigation—what specifically failed, why, and what can be changed to prevent recurrence—not a hunt for whose uptime metric to penalize.
Metrics that reward teams for protecting their own numbers create exactly the adversarial dynamics that DevOps is designed to dismantle. Metrics that measure outcomes customers care about give cross-functional teams a common target to rally around.
Practical Steps for Engineering Leaders
Van Kalken’s practical guidance for teams trying to build the right culture can be summarized as follows:
- Get people together early. Bringing stakeholders in at the start of a project—rather than handing off between silos—reduces the risk of teams developing adversarial narratives about each other. Early involvement also increases buy-in: people who helped shape a process are more likely to support its implementation.
- Keep communication open. “If people aren’t talking, you have a bad culture,” Van Kalken said. Breaking the ice between teams with a history of limited engagement can be difficult, but it is a necessary step. Workshops, joint retrospectives, and shared on-call rotations are all mechanisms for building those connections.
- Respond to failure analytically, not punitively. When an incident occurs, the organization’s response signals its actual values more clearly than any policy document. A blameless post-mortem culture, where the goal is systemic improvement rather than individual accountability, reinforces the psychological safety that DevOps requires.
- Align metrics to outcomes. Review whether current performance indicators measure internal process health or external value delivery. Where there is a mismatch, work to introduce metrics that give teams a shared, customer-focused definition of success.
“DevOps is really just a methodology to achieve a better outcome,” Van Kalken said. The tools and automation are means to that end. The culture—collaborative, iterative, analytically honest about risk—is what makes those tools effective.
This article is based on commentary by Scott Van Kalken, systems engineer at F5 Networks, originally reported by devops.com.