Marsh McLennan’s CIO Paul Beswick on fostering IT velocity

Thank you so much for having me, Mary Fran. It's such a pleasure to be able to do this in person as well, isn't it? It feels so amazing. I just want to keep calling attention like, look, look, look, we're in person. We're around a table here in Needham, Massachusetts. It's very exciting.

It's something that I've given my career to, actually. I started as a summer job out of university originally, and as you noted at the beginning, I've been here for 25 years now. I was very fortunate that my first year as CIO was the year we celebrated our 150th anniversary, when we got to ring the closing bell at the New York Stock Exchange, and it was probably our most successful year ever over the course of that 150 years. So while it's been an incredibly challenging environment in terms of keeping ourselves operating efficiently and dealing with the fact that everybody's been remote, it's been a remarkable period of time for the firm as a whole across all of those businesses.

Why I was persuaded that I wanted to be a CIO. I was talked into it. So I was with Oliver Wyman since I left university, and I worked in a lot of different areas, but early on I started to focus on the retail sector. The retail sector is still an area that's enormously fascinating to me because it's such a low-margin, highly competitive business. Those thousands of daily decisions, a little bit better, that would allow you to eke out a few more tenths of points of margin and allow you to be successful and survive in an incredibly competitive marketplace. That got me interested in that whole area. Over time, the capabilities that we'd built within the retail practice, which I ran in North America for about eight years, started to show that they were more generally valuable to a lot of our clients in many different sectors. So we created a team that was called Oliver Wyman Labs, really focused on data engineering, data science, decision-making tools in a lot of different sectors. I started to find myself being drawn closer and closer into this technology space because we all know no business really succeeds now without having figured out how to bring technology to the way that it operates in an effective manner. So I ended up doing some consulting work for my predecessor in this job, working on what the technology strategy should be for Marsh McLennan, right at the end of which I was persuaded that perhaps I ought to see if my cooking tasted as good as I thought it did, and come on and try and lead that transformation by actually taking on the role.

I worked with a number of ex-CIOs in my digital practice, of course, who experienced exactly that. It was a real challenge for them, and I'm certainly enjoying the rather more direct path between strategy and execution. The great fear when you leave consulting is that you end up losing the variety that you have within consulting, but I certainly have not found that to be a big problem for us. There's an enormous amount of stuff going on. It's fascinating. It keeps me interested. I'm having a lot of fun with it.

Yes, so it's a broad scope of responsibility, and I'm blessed that I've got a very strong team who take care of the day-to-day aspects of that on so many fronts all the time, and that allows me to focus on some of the more long-term transformational parts of the role. But there's a lot that happens within an IT organization that is... Yeah, we're keeping the lights on. I think almost it downplays too much quite how much discipline, focus, and care is taken to make sure that keeping the lights on is easy, and how complex business processes are.

Absolutely. I've increasingly been coming to the view that applications are a problem in terms of the way that they shape how IT... It's not worth senior management spending their time on small things, and therefore in order to get something to happen that involves technology, you have to make it a big enough problem with a big enough prize to get the attention, to get funded, and to go somewhere. So you tend to bundle a lot of things together to create something that is big enough, like an omnibus bill for IT. And because you do that, for a lot of people within the business, this might be the only chance in the next three to five years to get all the things that they want to happen, so they have to throw it in as well. The answer to that, when you're tackling a broad scope of things in one go to a deadline and under funding pressure, of course that is an expensive thing to do. It's also a thing that locks in a level of capability that is very hard to change later, and so what you achieve now slows down what you can achieve later because you have to unpick all the compromises you made along the way. And of course now it's big, expensive, risky, so you have to pile in risk mitigation and governance around it, and that makes it bigger and more expensive and in some ways riskier. So I slightly facetiously sometimes call this approach pre-paying for failure. Unfortunately, you also pay for failure on the back end as well. So we've been looking at trying to find a different way to go about this that comes back to what we're actually trying to model. We're actually trying to model... and leap up a staircase from the bottom to the top in one go. I can go step by step by step. So we're working on trying to create a framework that lets us do that systematically across our business.

It's an enterprise architecture framework, but it's supported by a choice of technologies within our stack that are designed to help us get there, and it's supported by starting the process of changing how we think about how we fund projects and how we agree what's going to go forward and how we release funding for them. That's quite different to how we've done it before. Now we're at the early stages of this. We certainly haven't mastered this yet, but I've seen some good early wins.

Fairly independent in terms of the way they operated. We've long had a shared infrastructure organization since about 2006, and that's done great things in terms of raising standards in how we manage infrastructure, how we handle security, and driving a lot of cost out. But other than that, the businesses effectively operated reasonably independently. Over time, we've been coming closer and closer together, both from a commercial perspective and looking for ways to leverage that expertise for the benefit of clients more systematically, but also from an operating model perspective. Technology has been one of the areas we've probably had more dramatic shift in the last little while than anywhere else. The role that I stepped into that was previously my predecessor was a sort of coordinator of the different IT functions rather than a leader of the combined group, and that's really put us in a much better place to leverage our scale to deal with basic things like standardization, reuse of technology, managing our negotiating leverage, and so on. But the four businesses camouflage the real complexity of the business. Trying to manage four businesses in four different sectors and find an effective way to build a technology organization to support that is fairly difficult, I would think. But actually when you look at it, there's all this complexity under the surface as well. It's a huge matrix, absolutely. And it's one of the reasons that as we've built the strategy for MMC Tech, while we are now one team, we've been very, very clear this is not a centralization strategy.

No, I think the combination centralization is a trap. And in many ways, one of the most difficult things that I find in my role is failing to understand the complexity and the variation that's within all those different organizations, which is too complicated for any central team to master on its own. We have to have real partnership with all of those parts of the business down locally in each of those areas, otherwise we're going to be delivering stuff that doesn't meet their needs.

Absolutely. They must have a hard time saying that to you, though, because you've been out working... Yes, but I think because I've worked for so many different companies in my consulting career, because I've been a customer of this organization within Oliver Wyman for 23 years before I was involved in leading it, I think I've got a pretty good level of sensitivity as to how this is all experienced when you get to the front line of the business. And that's the important thing: we don't win or lose in the marketplace without technology directly with clients, with what you deliver against our competitors. The quality of what we deliver, and technology is a massively important enabler of that and of our operational efficiency.

Yeah, and I think that's a dangerous way of thinking.

Yeah, so I think innovation, you're right, it's a very fuzzy word. We all like to feel we're doing it, but innovation for the sake of it isn't something we're in the business of. I never even know what people mean when they say that. Innovation for the sake of it is... I mean, if you're doing primary scientific research on things, fair enough, but I'd call that R&D. And we have lab groups within the organization. Technology can change how you operate, whether it's external disruption or what opportunities you can find for yourself. But I think of my role very much as perhaps my most important responsibility is to raise the speed limit of the business as a whole and to find ways to sort of ungum what can often be slow bureaucratic processes, what can be slow expensive ways of doing things, and replace them with faster and more nimble ones. And the structure that we've created is designed to enable that, so that we are leveraging our scale... strategy to develop our sort of operating system, our platform as a service, which embeds our controls, our processes directly within it, so that someone picking up a new project doesn't have to spend the time worrying about how to meet those controls because they're fundamentally built into the platform. I've given a challenge to my team, which we've hit once but we'll hit it increasingly often as we go forward: we need to be able to conceive a project on Monday and get it into production on Friday of the same week. And everything that's getting in the way of our ability to do that is something we need to be focusing on engineering out. Now, we won't do that for most of our projects, clearly. You can't build an application in five days, but you can take on a step in a process and make it better if you've got a scaffolding that you can hang it on that allows you to just make that step better.

Well, absolutely. So that group is right in the heart of figuring out how to meet that challenge, and they're both helping our development teams all around the organization, bringing them better coaching and structure around the translation of our architectural strategy into the toolkit that we give people to be tightly linked. So if we say that our strategic platform for deploying stuff is, we call it OSS2, it's fundamentally Kubernetes-based, and our code repository is GitHub, the tools need to be there so that when someone can get a repo on GitHub, they can get it quickly, it comes with the deployment pipelines automatically that get you to that platform, and that platform embeds within it the security controls that we need so that the development team doesn't have to spend a lot of time... The team who are building and own the platform is a really important one for being able to build that capability out. They're also doing things like building out template projects, so again you can pick up something that is a secure, standards-based, deployable project. I shouldn't say application, but I know because we were trashing applications just a little while ago, you can get up and running within an hour or so, actually deployed. Now it doesn't do what you need it to, it's an empty shell if you like, a secure empty shell that deploys, but it's more than a PowerPoint presentation. And so then you can do what you need to inside that, and you have all the toolkit and the standards-based approach, and so it gives you a...

So the talent story over the pandemic has been interesting. What we haven't seen is... We had in the height of the pandemic that we didn't have. So if you sort of stack the two years, it's sort of like over that entire period of time, we've probably had less attrition in total than we would have done in a normal two years. But that's not to say it's not a problem, it's not to say we're not worried about it. Making sure you have the best talent and hang on to the best talent is obviously enormously important for us. It's a very competitive marketplace. It's certainly a tough marketplace to hire in right now. There are some places where we're having to build pipeline ahead of demand to make sure that we've got people ready to go when attrition inevitably happens, to make sure we're in good shape. That's particularly true in India, interestingly. But I think the other thing is... I think we've made some progress, but we have further to go. We're able to sketch a career path for them that shows them where they're going, not just now but two years from now, five years from now. What are the things that they can see their career developing into? Because if you don't provide an internal outlet for people's ambition, you either get unambitious people, which is not going to drive the type of organization we want to be, or you lose them. And so one of the good things about the creation of MMC Tech as a structure has been actually there are more career paths available now than there were when you were within one business's IT organization or within one of the constituent entities, because people can move into different areas of the business and then come back. I know that can be... I see others often talk about that, but then they find it difficult to practice it because they're losing a really talented person. Everyone finds it hard to let people go. I actually think we've been pretty good. My leaders of my various teams have been actually remarkably good about lateral movement between teams, and what they get for it is good. It's certainly created problems, but it's all been done in the right spirit. It certainly happens.

So early days, but we're starting to build up a program that we really haven't had for a long time, again outside of India. It sort of comes back to that point about career. If you're going to offer people careers and you're moving them up, then you have to replace from the bottom of the organization rather than just sort of uniformly throughout the entire pyramid. And so it's necessary for us to bring people in at early stages in their careers, let them grow their careers with us, and we get a lot of talent, a lot of energy that way. But importantly, it also creates a system where we're focusing on people being able to grow their careers over the long run, rather than your career grows only by moving somewhere else. And that is a very stultifying effect in industries where the only way you can advance is to leave.

Aha, that's kind of... that should be right up your alley. Yeah, so I think partly by choosing where you're writing the narrative. So I'm not attempting to write the narrative of how Mercer best competes in its career segment. That's a narrative to write. Our job is to help them bring the technology to play in the right way. We actually ran a bottom-up exercise to canvas the entire organization about what they thought was important. And perhaps not to a great surprise, but encouragingly, what came back was the kind of things that you'd want to hear. They recognized we needed to be stronger together, that we needed to be agile, that we needed to be risk-aware, that we needed to focus on technical and operational excellence. And I'm going to have to remind myself because I can always... perfectly okay, I'm working from notes, you're entitled to as well. And of course I've missed... rally around that because it came up organically. It's not completely divorced from what was already the foundational cultures, codifying what was reality. And then our shared mission, as opposed to our separate missions, our shared mission is around raising the speed limit, around being a better organization delivering better technology faster and cheaper to our businesses, and everyone has that challenge.

Right. Well, so a big focus in upcoming things is to simplify. And one of the things that gets creepingly complex over time are policies and controls and governance forums and all that sort of stuff. It's important, but it's also not what gets most people particularly excited. We've recently created a policy council to review and manage all of our policies across technology. The first one they've gone after is information security policies. As part of that, we moved from ten different documents of 130 pages in total to one document of 12 pages. It clarifies what's needed, it draws the connection back to the controls better, it's more accessible and digestible, and therefore much more likely to be consistently followed without... and earlier in the process rather than being caught later and causing more time and rework when we get to that stage. And we're working through more and more policies like that on a systematic basis. But also anything that isn't the direct delivery of value in the form of features within the applications we're building or within the projects we're delivering.

The aim here is to be clear: we can't afford to simplify everything. No, that's why legacy and technical debt is still existing, because it would be so horrendously expensive if we try to replace the organization loose on any technology that happens to take their fancy this week. And I know because I still play around with stuff myself, it's very easy to get excited by something because it looks cool and new, and the organization is thankfully full of people who get excited by things like that. You actually want those people, you want those who are experts in Kubernetes. But we can't streamline the sort of... follow this, then you can pretty much get down to writing the capabilities you need, putting the features in, you don't have to worry about the other stuff because it's taken care of. So for instance, if you deploy on OSS2, our strategic platform, all the security is built in. You don't have to spend separate time figuring out how to scan your code and make sure that the firewall rules are right and all that sort of stuff. It's all dealt with. Interesting, because if you do something else, then you're sort of on your own. Not everything, so that's the golden path, the simple straightforward easy way through. And the key is to tell people that that's what it is, and they have a choice. You don't have to do it, but if you don't, you're on your own. It's like you're in a forest and there's a road paved straight through the middle of it. Your goal is to get to the other side of the forest. Do you want to just follow the road? I want you to just follow the road, that's the easiest way. There may be reasons why you can't. You maybe need to take a detour. There's maybe something like... a good example is you might need to be able to connect from some service that runs in our DMZ to something on the internal network. We don't allow that, so you've got to find a way to allow that communication to happen that's secure. So that happens often enough that we want to say there's a path here. It's not a road, it's a path. We've designed a preferred approach for this, we've pre-approved it. Use that, don't invent something new. You want to stop people blundering off into the trees, like that moment in horror movies where the girl decides to run into the dark forest rather than toward the light.

Yeah, let me be clear that our vendors provide us many really important things. We're not throwing them under the bus.

There are traps here because what tends to happen is these things have a gravitational attraction and they suck features into them, and so they get more varied and more complicated over time. And when that happens, they're harder to unpick later. I'd like to start from the assumption that pretty much every decision we make today we're going to regret five years from now. And so starting to think now about how we're going to unpick this decision when something better comes along is a useful discipline. But I think that discipline is useful, and it also explains why I think there's a danger in the sort of black hole application, whether that's an application you're building that's sucking in new requirements, or it's something that you've bought that you keep trying to customize around rather than saying it fits in this box. What I need in terms of differentiated experiences and agile improvements and enhancements to this for my processes should sit around it, because those are the things I'm much more likely to change. If I buy the right application, it'll last me for a long time if I don't try and do too much with it. Task runners, those sorts of things. An assembly of those things is inherently easier to change. Yes, that makes sense, and given I will probably want to change them all in the next five years at some level, or at least want the ability to, then that's an important part of doing it. Plus, back to the point about funding these projects and what the funding models are, taking on one of those is a relatively small, easy to agree to project. You're not signing on to the omnibus bill.

Yes, so I think I mentioned earlier one of the things we do in our development center of excellence is we have an agile coaching capability that we've built up to help support those teams. But you can't do agile in isolation. The technology teams can want to, but if they don't have the enabling technology to move at the speed they need to, which we've talked about... to make sure that we aren't simply trying to align with business strategy is to show possibility to the business and to show what technology can do for them. And the examples that we have in some of our labs areas, skunk works projects we do from time to time, or even just a great project from business unit A that we're showing off in business unit B, that shows the speed that you can move at when you get things right and the impact that it can have. I think it helps the business understand the value. Agile has a little bit of a bad name in some places because you can end up with this perception that it's an excuse not to have figured out up front what it is you're going to do and how, and it's just a free-for-all because you're so busy having stand-up meetings and that kind of stuff. It's not the highly disciplined process that it has to be. And so showing the wins, showing the things that you have turned around in a few days... So we had to build a sanctions tracker for tracking Russian sanctions to make sure that we weren't violating any of them. One of the teams in my corporate information solutions area managed to knock something up in about four days to do that. So that's significant. Monday to Friday. And it is being used.

I feel like we've been talking about the talent crisis and the talent challenge and the shortages for the entire time that I've been an editor and a journalist in technology. It goes back forever. And it may be like the problem of, you know, what's wrong with the public schools. Everybody's always got something to say about that, and I feel like that happens with technology too. One of the... I want to pivot over. You had another example that we talked about briefly about how you're leveraging things that happen in different areas of MMC Tech, and one of your examples was the team at Mercer leading the charge in the reorganization and the development teams.

Oh yes. Behind it, and so just sharing across the strengths of different areas and having it be better taken advantage of everywhere else has been great. Mercer had been going through a transformation of their development team into a pods and squads model. They've also been leading the charge on what they call metered funding, where more projects start as a quick rapid test and learn phase before getting access to the money to actually sort of fully develop them. A lot of ideas then get killed at that first stage, so we don't spend on the wrong things. And that's significantly sped up, and that's now being cut across into Marsh and Guy Carpenter. And I think that's a great example of turning something that is a theoretical construct into something that is already demonstrated. So where we have things that have areas that have led like that, it's great. One of the other things we've done: Oliver Wyman had a team that supported end-user computing that was separate from the main group within a global infrastructure area. That's obviously enormously important for consultants because they live on their laptops. That's right. That's why you made the point at one juncture we were talking that you're not trying to create self-driving cars. This is advice and consulting. So those teams... process where someone would lose access for a while can now be run in the background, and the user only loses access for about eight minutes. Because those teams have been able to collaborate and bring that expertise to everyone, that's impacting 82,000 people. That's a lot of minutes that adds up, and that's a lot of people feeling very happy thoughts.

I think that organizational change is a tool within transformation. The way we are organized to deliver against our goals is an important part of it. So simply changing the reporting lines of the business unit CIOs to go into the enterprise CIO changes the ability to create a sense of shared team, a sense of commonality of approach, that you'd think shouldn't make as much difference as it does, but it does. Similarly, we've pulled a lot of our database management into a group that does a lot of the same things that were already being done by many of the same people within the businesses when that capability sat there. But by putting it in a group, by having them focus on that alone, it changes how people think about the relative importance of that. And so we're getting a massively different level of innovation in how that stuff is being tackled, simply because it is in a group and that is their sole area of responsibility. So that's driving a lot more automation into areas that were lightly automated before. We're changing our resourcing model with respect to what we do and what vendors do. That's proved to be a driver of... that have well-defined goals that align with where your transformation is trying to take you are an important aspect of getting there.

Well, it's the people who do the work, yes. And the system is as much about how you get all those people to work together as it is about the technology itself.

I think the pandemic has taught us that we can move much faster than we thought we could. It's forced us to accelerate digital transformation, and it's shown that with the right focus and collaboration, we can achieve a lot in a short time. It's also highlighted the importance of resilience and adaptability, both in technology and in our people.