This article is based on insights from Rob Englund, an independent IT management consultant and trainer who has led DevOps transformations within New Zealand’s largest government organizations. His observations were shared in an interview with Richard Campbell on RunAsRadio.
DevOps Is a Cultural Transformation, Not Just a Process Change
The most common framing of DevOps focuses on speed: faster builds, shorter release cycles, quicker feedback loops. That framing is accurate but incomplete. According to Englund, DevOps at its best creates cultural change so significant that it alters how people behave at work — and not in superficial ways. Engineers who were disengaged, siloed, or openly frustrated become collaborative, creative, and genuinely satisfied with their jobs.
This human dimension is easy to overlook when organisations fixate on tooling and metrics. But Englund argues it is the most meaningful outcome of a successful DevOps initiative: “The biggest reward for me is watching people blossom. There are people who are oppressed by the system, and unreasonable systems create unreasonable people. If you fix the system, most people blossom and turn into a different person. Suddenly, they’re happy and cooperative and creative.”
Why DevOps Transformations Often Need a Trigger Event
Despite those rewards, getting a DevOps transformation started is rarely straightforward. Englund observes that IT leaders find it difficult to position themselves as internal disruptors. Exploratory efforts — a team experimenting with Agile practices here, a new CI tool there — rarely scale into organisation-wide change on their own.
What tends to unlock real momentum is a trigger event: an organisational disruption significant enough to create both executive mandate and workforce openness to change. Examples Englund cites include:
- A major restructuring or split of the organisation
- The arrival of a new CEO who wants to reset the culture
- A technology or delivery failure serious enough to be treated as an emergency
“Once you’ve got the trigger, then it’s a lot easier to get executive support and the hearts and minds of people,” Englund explains. Without that catalyst, change efforts tend to stall in pilot projects without ever reaching critical mass.
The “Big Bang” Approach: A Case Study in Government
Englund describes working with a large New Zealand government organisation that had allowed operational dysfunction to accumulate for years. By the time change was needed, incremental fixes were not an option. The problems were systemic:
- A deeply entrenched cultural divide between teams
- An almost complete absence of automation
- Siloed thinking with no cross-team knowledge sharing
- No meaningful measurement or feedback loops
The incoming CIO recognised that piecemeal improvements would not shift a system this calcified. Instead, he took a decisive, top-down stance: all releases would be cadenced, all code integrated to a central trunk, and everything would ship together on a defined schedule.
This was deliberately different from the Agile ideal of continuous, on-demand releases. The organisation’s legacy systems were so tightly coupled — what Englund calls “spaghettified, massive dependencies and entanglements” — that independent, frequent deploys were not initially feasible. Instead, the initial goal was a six-week release cadence, achieved largely through manual environment builds and manual testing while the automation capability was built in parallel.
Incrementally Shortening the Release Cycle
The organisation’s journey illustrates a practical pattern for teams in similar situations:
- Establish a cadence first, even manually. The discipline of a regular release window creates predictability and forces integration problems to the surface earlier.
- Invest in automation in parallel. Once the release rhythm is established, automation replaces manual steps progressively, reducing the cost and risk of each cycle.
- Shorten the cadence as confidence grows. This organisation moved from six weeks to four weeks as automation matured, with a target of two-week cycles by end of year.
This staged approach is realistic for enterprises with significant legacy debt. It avoids the trap of waiting for full automation before establishing any release discipline at all.
Why ITIL Alone Has Not Been Enough
Englund also addresses why IT service management frameworks such as ITIL have repeatedly failed to produce lasting transformation. His argument: these frameworks are built around the execution of defined processes, not the broader organisational and people change that sustainable improvement requires. Process compliance without cultural alignment produces checkbox behaviour, not genuine improvement.
DevOps, by contrast, forces organisations to confront the human and structural factors — trust, collaboration, shared ownership of outcomes — that process frameworks tend to treat as someone else’s problem.
Key Takeaways for DevOps Practitioners and Leaders
- Expect to need a catalyst. If your organisation is stuck in exploratory mode, identify what trigger event — real or manufactured — could create the executive mandate for real change.
- Address culture explicitly. Tooling and process changes alone will not shift deeply entrenched silos. People and structural factors need to be part of the transformation plan.
- Start with cadence, not perfection. A consistent, predictable release rhythm — even if partly manual — is a better foundation than waiting for full CI/CD automation before shipping anything.
- Measure human outcomes alongside technical ones. Team satisfaction, collaboration quality, and psychological safety are legitimate success metrics for a DevOps programme.
- Decoupling legacy dependencies takes time. Highly integrated legacy systems require a phased approach to frequency increases. Plan for it explicitly rather than assuming it away.
The most underreported outcome of successful DevOps adoption may be the one Englund values most: people who derive genuine satisfaction from their work. That is not a soft benefit — it directly affects retention, innovation, and the organisation’s capacity to sustain change over time.