This article draws on reporting originally published by Computer Weekly and insights shared at the DevOps Enterprise Summit (DOES) London 2017.
Why Enterprises Struggled to Embrace DevOps
For years, the conventional wisdom held that DevOps was a startup game. Large enterprises, the argument went, were simply too encumbered by bureaucracy, legacy technology stacks, and waterfall-era processes to benefit from the agile software delivery practices that smaller, faster companies had adopted. Any attempt to transplant those practices into a Fortune 500-scale organisation would founder on the weight of its own complexity.
That narrative has not aged well. What critics framed as permanent structural barriers have, in many cases, become the very reasons enterprises are now motivated to change. Slow release cycles, products that lag behind competitors, and customer expectations shaped by consumer-grade software experiences have forced the hands of even the most conservative IT leadership teams.
Yet adoption at scale remains hard. As more enterprises commit to DevOps transformation, a clearer picture of the real barriers has emerged — and they are less about technology than they are about people, culture, and organisational structure.
Safeguarding Competitiveness: The Business Case Driving Change
Enterprise IT leaders have grown increasingly frustrated watching competitors ship features faster, iterate on customer feedback more quickly, and build software cultures that attract better engineering talent. Lengthy, rigid development cycles are no longer just an operational inconvenience — they are a competitive liability.
The evidence that DevOps can work at enterprise scale is no longer theoretical. Gene Kim, co-author of The DevOps Handbook, has pointed to a broad base of real-world case studies spanning large, complex organisations — including those in highly regulated industries such as financial services and healthcare — as proof that the transformation is achievable.
“If those organisations with a reputation for being conservative, even within the IT population, can get on board with this, it just gives us more evidence that it really can be done. If you look at The DevOps Handbook, we have 48 case studies that show how these organisations have applied these principles… and 12 are based on unicorns such as LinkedIn, eBay, Google and Amazon — but the rest of these [success stories] are coming from large, complex organisations that look like the rest of us.”
— Gene Kim, co-author, The DevOps Handbook
The Maturity Model Trap
One persistent barrier is senior leadership’s reliance on software maturity models to assess and fund DevOps programmes. These models often codify progress as a series of discrete levels — level one through five, for example — and tie resource allocation to achieving those levels. Once a team reaches the top level, leadership assumes the work is done and funding may be withdrawn.
This is fundamentally at odds with how continuous delivery actually works. Nicole Forsgren, then CEO of the DevOps Research and Assessment (DORA) consultancy, warned that this framing is one of the most dangerous misunderstandings in enterprise DevOps adoption.
“The challenge with maturity models, particularly ones that are codified, is that it can become institutionalised and set in stone in ways that are difficult to break because suddenly you have a target — and once you reach that level, you’re done. Then the organisation might decide you’re done, and the resources that readily flow to support that initiative might disappear too.”
— Nicole Forsgren, CEO, DORA (at time of original reporting)
Senior leaders must understand that a product entering production in a DevOps model is not “finished” in the traditional waterfall sense. It is the beginning of an ongoing cycle of measurement, feedback, and iterative improvement. Framing DevOps success as a finish line rather than a continuous loop undermines the entire model.
The Grassroots vs. Top-Down Adoption Dilemma
DevOps adoption in enterprises tends to start in one of two ways: it bubbles up from engineering teams who have experienced the benefits first-hand, or it is mandated from the top after leadership has seen what competitors are achieving. Both approaches have characteristic failure modes.
When Leadership Leads: The Allianz Example
German financial services group Allianz is a frequently cited example of top-down DevOps adoption. After a visit to Silicon Valley, senior management instructed each of the organisation’s business units to deliver an app using DevOps practices within twelve months. The deadline was met three months early, in August 2016.
However, the initiative was not without friction. Andrea Hirzle-Yager, Allianz Deutschland’s head of IT, spoke candidly at DOES London 2017 about pockets of resistance — particularly within the security and compliance team, and between development and operations groups that were unfamiliar with how to collaborate effectively.
The resolution was straightforward, if not simple: get everyone in the same room.
“It was amazing to see that once they were all sitting there together and actually talking about what needed to be done, so many of the issues disappeared. Some of it was just a misunderstanding of what the person actually needed.”
— Andrea Hirzle-Yager, Head of IT, Allianz Deutschland
Scaling Across Borders: The BBVA Challenge
Spanish multinational banking group BBVA faced a different order of complexity: scaling DevOps across 35 countries, multiple languages, and varying cultural contexts, with a 12,000-strong IT and service delivery organisation. Brian Timmeny, BBVA’s global head of advanced engineering, DevOps and engineering processes, described how the organisation addressed this through localised leadership structures.
“We set up our centres of excellence across the countries and set up competency centres, which assist with scaling DevOps in each of the countries to give that local touch of execution and ensure [they feel like] we’re there on the journey with them.”
— Brian Timmeny, Global Head of Advanced Engineering, DevOps and Engineering Processes, BBVA
The lesson from both examples is that organisational alignment — not just technical tooling — is the hard part of enterprise DevOps. Without deliberate structures to surface and address local concerns, top-down mandates will stall in the middle layers of a large organisation.
Motivating Non-Movers: Dealing With Resistance
Rob England, a New Zealand-based IT management consultant, offered a practical taxonomy of the types of people found in any DevOps transformation effort, drawn from his “Surviving DevOps” talk at DOES London 2017:
- Innovators and early adopters — enthusiastic, immediately engaged, and visibly active. Their enthusiasm can create a misleading impression that the whole organisation is moving.
- The ambivalent majority — talking the talk, broadly compliant, but not genuinely committed to the new ways of working.
- Conservatives and laggards — resistant, slow to understand the change, and potentially a drag on progress if not engaged properly.
England cautioned against the hard-line “if the people don’t change, change the people” approach as a first resort, arguing instead for understanding why individuals are resistant before attempting to move them.
“If you align yourself with a particular technology, your career lifetime is limited. The same is true of every technical role. All of us must reinvent, grow up and move on, but the pace at which things are happening now, particularly the pace at which DevOps transformations are sweeping through organisations, has put terrific pressure on individuals to move on.”
— Rob England, IT Management Consultant
To stimulate self-reflection in reluctant team members, England recommended a direct line of questioning:
“I tell them to look me in the eye and answer these questions: will your work be better in a year, will you be producing better results, and will you be having a better time in a year? If they can’t say yes, they are not continually improving — so the whole fundamentals of continuous improvement are just non-existent.”
— Rob England
Using Exemplars to Shift Team Culture
England also advocated for the deliberate use of “exemplars” — individuals who already embody the skills and behaviours the organisation wants to develop — as change agents within resistant teams. These individuals can be hired externally or transferred from high-performing teams into lower-performing ones, with the explicit purpose of modelling the behaviours expected during transformation.
This approach works because it makes the desired behaviour visible and tangible, rather than abstract and aspirational.
Altered Behaviour Takes Time: Setting Realistic Expectations
Technology can be transformed quickly. Processes can be redesigned in weeks. But changing the culture, habits, and mental models of thousands of people across a large organisation is a slow, iterative process — and senior leaders who expect overnight transformation will be disappointed.
“We can transform technology in an instant and transform process fairly quickly, but the rate of change of people — of culture, of behaviours and organisations — and getting senior management to understand can be challenging.”
— Rob England
For individuals who genuinely cannot or will not adapt, England’s advice was humane: help them exit gracefully rather than forcing them out abruptly. The goal is a transformation that brings people along — or at minimum, does not harm those who are left behind.
“You know that saying: you’re either on the bus or off the bus, and that’s fine — but let’s make sure no one goes under the bus.”
— Rob England
Key Takeaways for Enterprise DevOps Leaders
- Reframe continuous delivery for executives. Products that ship in a DevOps model are not “done” at release. Leadership must understand and fund the continuous improvement cycle, not just the initial launch.
- Avoid treating maturity models as finish lines. Codified maturity frameworks can become an obstacle when they signal to leadership that investment can stop once a level is reached.
- Align the whole organisation, not just the eager teams. Pockets of resistance in security, compliance, or operations can block progress even when development teams are fully on board.
- Localise DevOps leadership in large, distributed organisations. Centres of excellence and competency centres give global transformations a local face and execution capability.
- Engage resistors rather than marginalising them. Understanding the root cause of resistance — fear of irrelevance, confusion, or genuine disagreement — is more effective than mandating compliance.
- Use exemplars to make change tangible. Embedding high-performing individuals in struggling teams creates a visible model of the behaviours you want to spread.
- Be patient with cultural change. Technology and process can be changed quickly; people and culture cannot. Plan transformation timelines accordingly.