This article is based on an interview originally published on InfoQ, covering Jonathan Fletcher’s talk at the DevOps Enterprise Summit London in June 2017.
Cloud Migration as a DevOps Catalyst
Hiscox CTO Jonathan Fletcher used his talk at the DevOps Enterprise Summit (DOES) London 2017—titled “Sorry Mr(s) Ops, We Hadn’t Forgotten You – Part Two of the Hiscox Story”—to argue that DevOps is no longer a nice-to-have: it is a matter of business survival. Building on his 2016 DOES talk, Fletcher detailed how moving to a cloud-first strategy became the forcing function that pushed Hiscox toward a genuinely end-to-end DevOps model, one that finally brought operations teams into the picture alongside development.
Early Wins—and a Blind Spot in Operations
Fletcher was candid about a pattern familiar to many enterprises: early DevOps gains concentrated entirely inside development teams while operations remained in a traditional, siloed role. Hiscox’s development-side improvements were significant:
- Number of people involved in a release reduced from eight to two
- Deploy frequency increased from two per week to fifty per day
- Deployment time cut from four hours to twenty minutes
Despite these results, IT operations had been largely overlooked. The continuous delivery pipeline existed within the development boundary. Recognising this blind spot led the team to ask how DevOps principles could be extended to ops—and that question pointed toward cloud adoption as a structural answer.
Choosing Azure and Embracing “Move Fast, Fix Later”
Hiscox selected Microsoft Azure as its cloud platform, a decision Fletcher attributed to the company’s existing investment in Microsoft technologies, combined with the observation that AWS and Azure were the clear market leaders at the time. Neither vendor was technically disqualified; the decision was ultimately driven by reducing switching costs and leveraging existing organisational familiarity.
Fletcher acknowledged an initial preference for re-architecting applications before moving them to the cloud—the instinct to avoid a “lift and shift” approach without exploiting cloud-native benefits. That position evolved pragmatically: Hiscox shifted to a strategy of moving as quickly as possible and refactoring afterward. The target set at the time of the talk was for three of Hiscox’s largest systems—collectively transacting hundreds of millions of pounds of business—to go live in Azure by the end of 2017.
The 2020 Vision: IT as Strategic Advantage
Fletcher outlined a longer-term ambition: by 2020, Hiscox aimed for IT to be a source of strategic, competitive differentiation rather than what he called a “subservient order taker.” The financial model underpinning this was also evolving—rather than building and owning infrastructure, the goal was to rent IT services (SaaS and cloud platforms), allowing expense costs to flatten even as the business grew.
Q&A with Jonathan Fletcher: Key Themes from DOES London 2017
InfoQ spoke with Fletcher in more detail following his talk. The following exchanges cover the practical and cultural dimensions of Hiscox’s DevOps journey.
On the “IT-Less IT Team” Concept
InfoQ: The audience loved the ‘IT-Less IT Team’ phrase—what are the steps needed to get there?
Fletcher: From an IT point-of-view it’s about aligning tools, processes and ideas in IT and getting on a common platform. Then getting deeper integration with the business and federating IT out to the business—then removing IT as an entity and embedding IT skills into the business’s value streams. At Hiscox there is a group budget for IT that, with cloud, we are pushing back into the business as a discretionary spend.
The move to cloud and consuming things rather than building them will also make this happen naturally. Using SaaS and doing due diligence to ensure it’s the right product is a different skill set from designing and building it ourselves. It will reduce our IT touch points.
Fletcher also made a broader cultural observation: as digital literacy becomes universal across generations, the concept of a discrete “IT department” becomes increasingly anachronistic. IT skills will simply be part of what competent business professionals possess.
On Breaking the “Not My Job” Anti-Pattern
InfoQ: You highlighted ‘not my job’ as a classic DevOps anti-pattern. What’s the strategy for changing that behaviour?
Fletcher: It’s a cultural thing—we need to be focused on being a single team and all share the attitude that it’s everyone’s responsibility to get it over the line. Silos create handoffs. The Agile Manifesto helps with this in that the basis of it is that we are not individual parts but part of a greater team.
On the Connection Between Cloud-First and DevOps
InfoQ: You say that cloud-first is accelerating the DevOps revolution—what is the connection?
Fletcher: You can do cloud without doing DevOps, but whether you should is the question. You are potentially just moving the problem. What moving to cloud gives you is more time to tackle the way you deliver and make improvements around speed, quality, security and performance.
This is an important nuance. Cloud adoption is an enabler, not a substitute, for organisational and cultural DevOps practice. Organisations that migrate infrastructure without changing their delivery model simply replicate on-premises dysfunction in a different environment.
On DevOps as Competitive Advantage
InfoQ: You say DevOps is critical for businesses stealing a march on their competition. Why?
Fletcher: It’s around the changing role of IT. IT used to be a subservient order taker from the business but it’s becoming a two-way conversation. We need to ask questions like: if a process that took eight hours only takes twenty seconds, what does that mean for the business? Insurance in particular is about understanding risk, which is essentially a data problem; if we can understand the data problem we can serve our customers better.
On Why DevOps So Often Stays in Development
InfoQ: Many organisations at DOES face the challenge of DevOps being done in dev only, with ops left behind. Why does this happen and how can it be remedied?
Fletcher: The focus on dev happens because there is more obvious value in changing the development cycle—businesses want to get more change out of the door. The theory of continuous delivery gets people excited about change velocity, as does the appetite for Agile, which also came from a software engineering perspective. We need to take the ops teams on the same journey: help them move away from waterfall, get to automation, use lean tools and Value Stream Mapping. It’s the same approach—but it’s a bigger jump for ops, as they are unfamiliar with these ways of working. Things that help are training, cross-skilling, mentoring and coaching—giving them the skills to just get on and do it.
On the ITSM vs. ALM Tension
InfoQ: What was the most valuable insight for you from DOES this year?
Fletcher: ITSM versus ALM is the big one for me—it’s driving lots of conversation about how to tackle the technology and process problem where these two worlds are so unfamiliar to each other. Who wants to write a user story when they raise a support ticket?
The ITSM (IT Service Management) versus ALM (Application Lifecycle Management) divide remains one of the most persistent friction points for organisations trying to achieve true DevOps integration. Development teams operate around stories, sprints and backlogs; operations teams work with incidents, changes and service requests. Bridging that tooling and process gap is as much a cultural challenge as a technical one.
Key Takeaways for DevOps Practitioners
- DevOps without ops is incomplete. Early delivery-pipeline wins are valuable but leave organisations exposed if operations teams are not brought into the transformation.
- Cloud enables but does not replace DevOps culture. Moving to the cloud without addressing organisational silos relocates, rather than resolves, the underlying problems.
- “Move fast, fix later” can be pragmatic. A phased migration—lift and shift first, re-architect later—may be the only realistic path for large enterprises with time-sensitive transformation goals.
- The ITSM/ALM gap is real and largely unsolved. Organisations should invest explicitly in bridging incident-management and development workflows, not assume the tools will converge on their own.
- IT’s role is shifting from cost centre to value creator. The longer-term argument for DevOps investment is not efficiency—it is competitive differentiation and the ability to ask fundamentally different questions of business processes.