Jonathan Fletcher

Hi, everyone. Lovely to be here.

Before we start, could I ask you all if you would stand up for me, please?

Thanks. Could you put your hands on your head for me, please? Come on. And give me a silly face.

Okay, right. Thanks, everyone. I can't believe you've just done that, but sit down.

The point of doing that stupidly was just to say: don't follow what everyone tells you. There's going to be a lot of guys up here talking about DevOps. I'm going to talk about what I've done at Hiscox. That might be relevant. That might not be relevant. There isn't a right way of doing it, as far as I'm concerned.

So take out of this conference little bits and take them back, is what I hope you'll get from this presentation, because we can't even decide on a definition of DevOps. So if we can't do that, then how can we tell you the right way of doing it?

So, let's make a start.

Me: Jonathan Fletcher. I've been an architect in Hiscox since 2012. I've been a dev. I've worked in ops. I've done various jobs that sort of led me to this thing called DevOps and gave me some empathy between these different types of challenges.

Hiscox are an insurer. We specialize in all kinds of different areas. So we insure space rockets. We insure footballers' right feet, as well as traditional insurance like home and that kind of stuff. We turn over about two billion a year. We've got lots of offices in various countries around the world, major hubs like London, Paris, New York, Maidenhead.

Some of the challenges facing Hiscox at the moment is really growth. The business is growing at an enormous rate. In the US, we've grown 30% this year, and actually we've done that for the last four or five years. Growth for group overall this year, in really tough market conditions, is 10% up. Share price when I joined three or four years ago was two pounds, three pounds. It's now 10 quid.

And my favorite quote from Robert Hiscox, so this is the guy with his name above the door, so you kind of have to listen to what he says: "I bore my colleagues that we should be an IT company with insurance attached." So this is from an older gentleman, should we say. So him to say that, that's quite an impactful thing. The impact of IT on insurance is massive, and his acknowledgement to the business that we really need to change.

A couple of years ago, we approached a management consultancy to start really looking at us as a department, and how we work with the business, and where we're going to go forward. And they brought up four main things.

Increase our speed to market. So how do we get products out the door? And then once they're there, how do we increase that pace of change? Not only that, we need predictable and reliable change, because one minute you tell me something's going to be two weeks, then it's going to be a month, then it's six months. That was a real problem for us. And also, the teams were badly aligned, which created ownership problems and delivery accountability.

So let's start our journey of DevOps at Hiscox. Now, if you haven't seen Lord of the Rings, this talk's not going to make a lot of sense. But if you haven't seen Lord of the Rings, you probably shouldn't be working in IT. Door's at the back.

So let's start our journey at the Shire.

The Shire is a green and pleasant land. Everyone thinks that what they're doing at the moment is nice and it's very serene, and everyone's very happy. They don't really know about the impending doom that's walking around the corner soon.

Me, I see myself as Frodo. I started as a solution architect in 2012. I was doing in-place upgrades of stuff, nothing to do with DevOps. And after about three or four months, generally a bit frustrated. Why is everything so slow? Why is everything so expensive? There's got to be a better way of doing stuff. Generally frustrated is a polite way of saying grumpy old git.

I think that's one thing I take forward, is that continual desire to do things better. And that frustration led to approximately a million PowerPoints I've written over the last couple of years. So I've tried to talk to the CIO and CTO. That was my routine: there's a thing called DevOps. There's some ideas around continuous delivery and Agile, and we should do this, basically, and continually reinforcing the message with those guys.

But I started with those two. That director is now the CIO. Head of architecture's now CTO.

And to start with, so this is back in 2012, I proposed three things: an IT reorganization of our org structure, some technical leadership, and investment in automation. So the technical leadership, we had a head of group development, we had a head of group architecture, but no real person over the top that was creating that technical leadership and that vision for where we want to go in the future. And that's why we now have the CTO.

Largely, it was an ambition to increase pace of change, but actually, as we started pulling that thread, what we found out is that we've had to just reboot the IT team. It's become an in-place tactical thing to try and create a better pace of change, actually has led to pretty much redesigning the whole IT environment.

Hiscox is a fairly federated business. We've got multiple business units based on geography, and our capabilities largely looked like this a couple of years ago. So we had group capabilities that met all the demands of those individual business units. Their goals and their incentives are based on a group basis rather than that of the BU. And the business units, some of them want more money than other business units. Some have got different appetites for pace of change than others. So trying to teach them through one group capability and deliver seemed the wrong thing to me.

So today it looks a bit more like that. One of the first things we did was to federate IT into those different BUs and geography, with infrastructure running across all of those units. Each business unit won't want their own Citrix setup, for example. And then the team I run, which is platform services, again spreads across the company.

So I run an evil DevOps team, which people sigh and tell me that that's wrong all the time, but it works for us.

Why did we create this? Really, it was about the growth of the business is challenging us to do things in a better way. It's not about just getting more and more people. You don't scale and make things faster by adding endlessly more people. We've got to work a bit smarter, and that's what this team tries to help us with.

Platform services helps to break down the silos between the different teams. So if you're a purveyor of change, if you work in an infrastructure team, if you work in an application team, if you work in a test team, we try and help you pick up some tooling, pick up some ideas. We evangelize things like DevOps. We try to empower these end users to become self-sufficient.

For example, we'll talk to a development team about continuous delivery. We help them provide the tooling, get them up to speed, and then they become self-sufficient. So we don't actually use the platform ourselves. We don't do deployments and things for people, but we train our end users in how to use these tools and these ideas.

What we've commonly found is teams are so busy doing the day-to-day change, change that text box from pink to green and do this business change, they haven't got enough time to change the wings of that airplane whilst it's going along. So we try and help shortcut that process.

If you want to do this yourself, and I've seen this in a few different places, just be careful about creating another silo because you don't create a silo issue by creating another silo. It's bad. It's not just bad, but Jar Jar Binks bad. But I think having a team that evangelizes DevOps and ideas and concepts and toolings is a really good thing.

My team runs loads of stuff. We've got loads of testing tools, CI tools, version control tools. That's not even half of them. I've got them coming out my ears, and I think a challenge for me next is to try and consolidate some of these things out.

And I know some of the other guys have talked about autonomy for teams and letting them have a tool selection, but also that creates its own problems, certainly from a cost point of view. So rationalization in some places, I think, makes sense.

The first DevOps thing we did at Hiscox was a program of work called DaVinci. We started that a while ago. What we did was replace our home insurance platform. So that was a mix of policy admin, our billing, our claims process systems, our websites, our underwriting rules, vendors, everything changes. The biggest program of work we've ever done at Hiscox. I heard rumors it was a 100 million pound project, which for us is very, very substantial.

It's a mix of off-the-shelf products, largely Java, SQL Server, and Windows. And my team kind of came late to the party, really.

What they did was they spun up a project and, "Right, we're going to change our policy admin system. We're going to change the way that we manage insurance, and we're going to spin up a project to do that." What'd they do? They used the same process they've always used: waterfall, manual deployments, manual testing, and actually very little thought around once the project stops, what does BAU look like? What's the team going to carry on adapting this website and all this infrastructure and all these insurance products? So no real thinking about how to transition from project to BAU.

This is kind of where we stepped in and said, "Hang on a minute. Once you go live, you've bought this platform for a pace-of-change point of view and to quickly adapt it, but you've got no one to actually make those changes. So why don't we start here?"

Everyone says you should start small with DevOps and grow that success. This is the biggest change project we've ever done at Hiscox. So why did we do that? I just couldn't think of any other way to do it. And that's a bit embarrassing to tell at a DevOps summit, but that's the truth. It's like, we couldn't have done this any other way. Nothing very clever.

I talked about this BAU team, and this is the change team that takes over the project and runs that day-to-day change.

Now, we call this purple people. So this is a mix of the red of IT people and the blue of the business people, and we try and blend these teams together. You often call these product teams, but actually it's a mix of the two. What we're trying to do is align the incentives of IT to that of the business, have them work in the same room at the same time.

Our methodology around these purple teams is that they are largely autonomous. They largely have the autonomy to lead their own direction. We try to really encourage cross-skilling between different skills inside that team. They're aligned to business units. They have cradle-to-grave responsibilities, i.e., you come up with the idea, you develop it, you run it, you support it. You do the whole length of that journey.

It consists of all the people you need to make the changes. So there's no having to wait for a DBA that's only available for three months' time because he works in another team. You've got all the people right there around the same table at the same time to make those changes. And those goals and incentives of all those different people inside that change function are aligned to the product rather than of some other group.

One of the big things we did was we did some deployment automation, which was a great success for us. This was an easy, logical starting place in terms of technology choice.

Before, we had eight people involved in release. Now, maximum of two people. It's a button, right? It's pretty easy for us to do a release. We were doing two deploys a day. Now we're doing an average of 50 a day. Three or four hours to deploy something, takes 20 minutes now.

Beforehand, before we started, they had five different environments, sys test, UAT, all those kind of things. Now they have 31, so managing that becomes really hard. So 50 deploys a day probably for a lot of big companies isn't much, but for us, that sees change from two days a week to 50 a day. That's pretty substantial.

So in terms of numbers, we're talking about a 97% reduction in the cost of release and an 89% reduction in the cost of the time taken to do a release, which is fantastic. Those numbers down there are two applications and number of releases by month. We've done 5,000 in the last six months. Again, just shows the level of change, the step change that we can now do.

That's great. Everyone likes a stat. What did other people think?

Beforehand, we had a six-week change cycle. That's now a two-week change cycle. We've got 40% fewer IT resources because of that consolidation from all the systems into one platform. We doubled the online conversion rate in the first two weeks.

And I just love this email, and I think I send this to my mum every day and say, "Please be proud." "You guys rock." So that's from the CIO to the CIO, who is my boss's boss. I report to the CTO. CTO reports to the CIO. So that's a good thing. I'd like to put that in my annual review every year. Just put that on the front. So that's good.

This is just a blatant showing-off slide. I'm sorry, but this is a guy, one of my team, outside St. Paul's on a Boris bike doing a release in the afternoon on his way back home, which is just a cool thing to do.

I'm not sure what to call it. Boris bikes. Chicken bikes? I don't know.

Mistakes along the way. Now, I have made a few whoppers.

When we first started, we were going to try and influence different people around Hiscox IT, and I went in there and I said, "Do you know what your problem is? Your problem is testing. Your problem is this. Your problem is that." So rather than coming up with a solution with them, I told them their problem was that, and all that's going to do is get people's backs up and get change resistance.

I assumed everyone else is like me, so I underestimated the time and effort that it would be to introduce cultural change. I thought all developers are desperate to do the new and latest and greatest and change how they do stuff. I thought everyone wants to do that. That's not true. That's really not true. Some guys are very happy doing the same thing the way they've done it for 20 years, and who's this idiot coming along and telling me there's a new and better way of doing stuff? That requires effort.

I occasionally fought fire with fire. So if someone said, "Don't tell me how to do my job," I'm like, "Well, I know how to do your job better than you." And it escalates, and that's the wrong way to influence people. You don't just go harder. I think that's a bit of my Essex background kind of clashing with people.

We struggled to change the wings of the plane when it's in the air. So everyone's got a day job still. You're trying to change the way they do releases, the way they do testing, all this kind of stuff. They've got a day job to do. It's very hard to influence that kind of change when you've got that normal everyday churn of stuff to do.

We probably started too big. We actually went out and talked to too many people at one time. Just not a very good idea.

I spent an awful lot of time influencing up the chain, CTO, CIO, all those million PowerPoints, very little on the ground floor. Again, probably should have been a bit cleverer there, a bit cuter.

I always assumed that DevOps would be a groundswell movement. I couldn't see that happening where I was, so kind of went up the chain to push it, to make people tell that's what we're going to do, which introduces problems.

We've introduced large amounts of new tech, processes, new team structures, and I get really frustrated about how long it takes to adopt these changes. I'm like, "Come on, get there faster. Pull this in. Want this more." And that's a big effort. And if you are a change agent in your company, that can be a problem because it is exhausting, right? Because you're always trying to push things forward when people don't want it, or they're slow to adapt, and you just need to keep the faith.

So along the way, Frodo on his journey to Mordor, he encounters a few of these Uruk-hai, these nasty-looking orc people. And you're going to get lots of guys and gals that are going to resist change. Some people love it and embrace it straight away. Some people need time. They need to go through that change curve. Takes a bit of time, a bit of influencing. Keep talking to them. But some people are never going to get there, and they're going to make things difficult.

And I think someone said it yesterday: if you can't change the people, change the people. So we've had to do that in a few circumstances. It's not where I want to be. I'd rather bring everyone on that journey, but sometimes that's just not going to happen.

So why would you do this? If you're thinking about starting DevOps in your company, why would you put your head above the parapet? Because it's going to get shot down. You're going to get beaten up. It's a hard slog sometimes.

Well, I got a promotion out of it. That's cool.

That visibility across all of the different silos in both IT and the business is fantastic. So you really get your name out there, and you'd be able to say to the business, "These are some of the metrics. This is some of the return on investment we've got from some of these ideas." That's a really good thing for your career.

That's led to increased funding for DevOps-related stuff, projects, tooling, and people. That's a continuing investment because of the success. The more we evangelize that, the more we go out and talk to people, the greater that investment becomes, and starts to snowball.

But most of all, it's about trust. So what I personally have got from this is that I'm entrusted now with really big decisions. I'm entrusted with some of the strategy of our IT, and that's not because I'm having to go and talk all the time about the benefits, show ROI, do tons of PowerPoints. It's like, this guy's delivered before. He knows where we're going to get to. I trust him. Let's get on and do it. And that's a really great place to be, where people trust you rather than you really having to force it on them.

But that said, I'm a fraud.

What have we actually done? We've done Dev. We haven't done Ops. We've done continuous delivery. We've done test automation. But where's the Ops side of this? And I see this a lot with presentations. People always talk about developers and CD and CI and pushing stuff through the pipeline. Actually, what about the other half of Dev? What about the Ops?

My favorite quote is from Werner Vogels, who said, "Stop spending money on undifferentiated heavy lifting." Everyone nowadays can run a data center. There's no competitive advantage of you running your own data center unless you do some ultra-low-latency, very particular thing that you need to go and do. For most people, there isn't a benefit. There's not a competitive advantage to you spending time, effort, and money running your own data center.

So I think for us, glory in DevOps happens the closer we get to Mordor, and my Mordor is moving us to the cloud. It's a scary place. There's lots of those change resisters in this kind of world.

We're moving to Azure.

Cloud at Hiscox: we did an analysis between Microsoft Azure and Amazon AWS, the two leaders in the Magic Quadrant. We did proof of concepts in both. We selected Azure over AWS. We're primarily a Microsoft house, so it was a more natural fit for us.

We're also very passionate about PaaS over IaaS. So thinking about not running VMs and then the software stack on top of it. I want all that abstracted away from me. I want to give that all to Microsoft. I just want to deploy an application into there. So that really is something we're really trying to push: PaaS over IaaS.

The Azure support feels a lot better than AWS for us anyway, from an enterprise point of view. AWS felt a little bit, you take the standard contract, you take our standard terms, you get stuck in a queue. We'll get round to you when we feel like it. Microsoft, because we've got that enterprise relationship with them, there seemed to be more of a play there and better suited to an enterprise.

And then hopefully, when Dev and Ops, we've brought these two groups together using the same tools, processes, working in the same team, then hopefully, I think the thing called DevOps will happen. So they're both going to be using the same technologies, both working in Agile, both working with things like continuous delivery. That will really bring those two guys together, and actually then this magical, mystical thing called DevOps, I'm hoping, will happen.

We have a team at the moment. So part of my role at the moment is trying to get some applications that exist in the cloud.

We had a long think about what the types of skills would be needed in that team, and we wrestled with this for a long time. So we've made a decision. We're not actually going to put VMs up there. We're not going to manually configure stuff. We can do everything through infrastructure as code. And I think that move to the cloud infrastructure really changes the focus point of what skills are needed in your teams.

For me, attitude is the first thing we looked at. I went to a presentation yesterday with Tom Clark, who said there's two things he looks for in a team, which is intelligence and kindness. For me, attitude, the right attitude is the right thing. If you've got the right attitude, you'll learn the tech. The tech's the easy bit, right? So attitude first, and that beats that automation skill, and I think that beats those specialist infrastructure skills.

Actually, talking about roles inside of a team is less relevant. It's about having the right attitude and the right level of adaptability to work in that environment. If you're dealing with Azure, you're dealing with an API. A lot of that stuff is hidden, but you do need to know a little bit more around some of the DevOps stuff. You do need to know a little bit about what everyone else is doing.

And this idea of T-shaped people. So you're kind of broad in lots of different areas, but you've got to specialize in one skill. So no longer are you just the database guy. Everyone does a little bit of everything. In our team, I've got the guy that specializes in networks doing database deployments, because it's automated. He understands it. He's got empathy for other things that are going on around him.

T-shaped people, not Mr. T. It's different.

So the cloud team consists of a core team at the moment. We've got a guy that specializes in things like permissioning and server-based stuff, a network guy, a guy that's come in that's done a lot of Azure stuff before, a Scrum Master. We've got a software developer in test writing loads of tests against a continuous delivery pipeline in Bamboo, and a product owner, which is me.

And then what we do is we bring in application development teams into this team when we're doing a migration. So the idea is they come in, they learn about how Azure works. We can bend and configure the app to work in PaaS. We can get out there, and then they can become self-sufficient. They can go back to their jobs, and they now can know how to build their own environments up, deploy them, release them, make themselves sufficient. And there are a load of other guys that we call on when we need expertise into that team.

We've been really conscious of a couple of things. Again, what I've heard from a lot of companies, they've done largely lift and shift into the cloud. They've taken VMs. They've put them in the cloud, and actually all they've moved is from one data center to the next. They've not really got those benefits of scale, resilience, pace of change, all that other kind of stuff.

That's really not where we want to be, and we're doing a very deliberate move of applications where we can bend them and move them into the cloud and get those kind of benefits from them. We want Microsoft to do the heavy lifting for us. I don't want to patch stuff. I don't want to worry about SAN disk space. I don't want to worry about backups. I don't want to worry about any of that kind of stuff. Let them do that. Let's concentrate on the really high-value tasks.

Everyone said to me to begin with, and again, this is my change resistance for myself, "You've got to do a cost analysis." And no, cloud isn't about cost. It's about resilience and about pace of change. It's to steer away from cost. But if you're anything like us, you've got to go through this kind of working out what is the difference between on-prem and cloud from a cost point of view. And we put tons of effort into doing this. Without it, we wouldn't have got anywhere.

I still hate the fact that we want to do it. I want to sell the other benefits of cloud. It shouldn't just be a cost benefits case. There are lots of other benefits. But it's something you're probably going to have to do because the man that holds the money ultimately is going to ask you that question.

Moving to infrastructure as code is akin, I think, to an infrastructure guy becoming a developer. That's a massive cultural shift and skill set change for people. So don't underestimate the effort that is required to go and do it. You can't just go to an infrastructure guy that's been building servers manually one day, you're a developer, off you go, and he changes automatically. That just doesn't happen. It takes a long time.

Some of the guys on the team have been doing this now for 18 months and are still just about to get there. They're picking up the ideas of BDD and CI, and it's all very new to them. Get an infrastructure guy using Git, they're like, "What the hell is that?"

What is infrastructure as code? So just very quickly, not teaching you to suck eggs if you already know this, but I see infrastructure as part of an application.

If you think about it, an application depends on a version of a firewall. It depends on a version of a server or a database. All these things are dependent on each other. They can't stand alone.

So how do we do that? It really means writing code that allows us to manage applications, configurations, and automate that provision of infrastructure underneath the applications, and doing it in a way that you can version that and put that as part of the application.

It's not about writing scripts. So again, the infrastructure guys, "Well, I write PowerShell now. Why is that not infrastructure as code?" Well, it's not because you're not using version control. You're not using design patterns. You're not doing small releases. You don't know about immutability and idempotence and all these kind of software development engineering principles that really separates infrastructure as code from just pure scripting.

This team are writing a lot of this code to try and move us to the cloud. And actually, one thing we've been struggling with is we want to federate some of these applications, this infrastructure, out to the different development teams around the business. How do we do that?

So if we release a new template for JBoss or IIS, how do we make sure that they get that template? Because we can publish it. We can put it up on Bitbucket or GitHub, and they can go, "Well, that's great, but I don't want to take that change because I'm too busy to do my day job."

So what we've been thinking about, I call it the engineering triangle. What I want the cloud team to be is almost like a software-as-a-service type offering. So stuff that we're going to change to people's applications and running infrastructure without you ever even noticing. And the more that we can do of that means we're not going to be beholden to the change cycle of the application team.

I don't want us to be in a place where the cloud team is waiting for applications to do an upgrade that might happen in six months, and then we help them do it. I just want to change stuff underneath, patch stuff, keep stuff moving all the time. So the more I can do, I can push onto teams will increase the pace of change for the cloud team.

The stuff they can pull in. So they might go, "Okay, we've got a release next week. We can pull the new version of templates down to us." And that's a better way because we're not having to get involved in that. They can pull that from us.

And then right at the top, the stuff we're going to have to do together. So if we're changing a fundamental bit of our cloud platform, and that's going to take down all of the applications, then we're going to have to work with you together on that. And that's, again, not a place I really want to be in because that's where you're going to kill the pace of change.

So, nearly finished.

If you're starting on the DevOps journey, my plea to you is to be more like Frodo. You do need to be brave. It's a hard slog out there. It helps having a buddy along the way. I had a really good project manager help me along this route. In those dark times, you can talk to someone and say, "Look, what's going on here?"

You need to be restless about making the world a better place, I think. You're always trying to push your company forward. You're always trying to do stuff better. But the rewards are absolutely worth it. This is a chance to really become the guy that made things better in your company. That's a really good place to be.

But mostly, you don't need to be that clever. I'm not. I'm really not. I've got a D in general studies. I'm not brain of the year.

And why is that? Because all you need to do is copy these people. All the design patterns and all the stuff is out there. I didn't invent Agile. I didn't invent DevOps. I didn't invent continuous delivery. None of that stuff is my original thinking. All of these guys have done it. So read it, understand it, take what's relevant, and then bring it back to your companies, because it's about putting your head above the parapet, being brave, and going for it. You'll get the rewards if you're ambitious enough.

So I'm done. I just think, just to finish off, help that I'm really looking for. Massive talent shortage in the marketplace. I'm recruiting now. If anyone wants a job, talk to me.

And then anyone else who's been through this infrastructure-as-code kind of paradigm shift. If anyone's got any experiences of the cultural shift and the challenges and how they've solved that, again, really keen to understand that from you.

So thanks for listening. Appreciate it. It's another insurance chat, but thank you very much.