Simon Clayden specializes in creating and executing technology strategies that deliver real business transformation. With a career in financial services spanning 25 years, he believes the way to tackle technology complexity is to be a systems thinker and ask ‘why’.
In the past five years, he has been the driving force behind AXA UK’s tech shifts in the areas of the digital workplace, customer experience, and artificial intelligence.
It's been quite a journey. I can't believe it's been 25 years. So I started in customer service and customer operations. I came from a background of dealing with customers every day and trying to help them. And that taught me a lot that gave me an excellent foundation for understanding the kind of customer journeys before I realized what customer journeys were.
From that, I started to drift into project management and program management just because I liked taking minor problems and trying to fix them, certainly from the customer's point of view. And someone, somewhere, saw some talent in me on the IT side because I was able to bring this view.
I was able to understand what's happening in operations, and what's happening from the customer's point of view and talk to the IT guys about it in a language they would understand. This is what we need over here. So how can we find a way to deliver the outcome and help both sides build that big picture?
One of the first things that I did was back in 2009. It was not long after the iPhone had launched. So I designed the UK's first insurance iOS app. There was a race. I didn't know it; there was a race between another organization and us. But we managed to cross that line first, which was great.
The biggest thing I learned was that we didn’t understand the ‘why’. I driven to be the first to launch an iOS app. And the first person that used the app was my wife. So she crashed our car, and we got a notification. The engineering team thought I was still testing the app. They didn't know it was a real claim.
You're from Australia. You probably can get this more than I. When you're dealing with understanding IT change it's like riding a surfboard. If you go too soon, you miss the wave. If you go too late, you crash and burn. You've got to find that point of understanding - what's the right point to set off.
So that's what I try and do. A business architecture view often helps both sides. To understand when are we going to surf that wave? And where are we trying to get to?
We're a large organization that has hundreds of millions of customers. But it also seems like just as many products and systems to deal with. So there is definitely a fine balance between getting too far into the detail and having that big picture. So I hope what I brought was that ability to stand back and help others understand what's going on around us. Not just what’s happening inside the organization context, but what's happening outside of the organization.
When I was bringing in people, I worked a lot with recruiters. What sort of person are you looking for? What sort of skill set? It was more important to me that they had that ability, to ask the ‘why’ question. And you can start to annoy people by continuing asking ‘why’. But the more you do that, the more you dig in and help the other person understand. Hopefully, take them on that path to understand what's driving the change and what destination they are trying to get to.
Often, I was surrounded by execs who were fascinated and focused on the delivery, the box being unwrapped as the outcome. So how do you know what the value is? You've got to know ‘why’ you're on the journey as much as what the journey is.
Yes, and the whole Shingo Institute approach, the Kaizen philosophy. Also, with GE and with Six Sigma. Often, you're surrounded by excellent people that know the engineering side of it, but you've got to help them as much as the business goes on that journey. So they definitely needed that skill set. Just keep asking ‘why’ until you get clarity.
One of the things that I created in one of the organizations I worked with is a business design authority. It was a forum made up of business people and technology people that kicked the tires on change requests, new project requests, and investment requests and made sure that whatever was being considered went all the way back to a strategic objective. And this authority would give guidance and direction to these change teams and help people make informed decisions.
Not successfully all the time. It was certainly more complex than I thought it needed to be. And why I say that is because I was a member of the global architecture review board.
What I found was that people were coming in with requests that just said, we want to implement technology X or Y. There wasn't that reason ‘why’; there wasn't the outcome. And how are you going to measure that change initiative at the end of it? What's happening at a process level? How are these people going to use the technology?
Yes. We got into a system replacement; it was looking at claims operations and replacing system X with system Y. So we got into about 18 months of that transformation project, and it wasn't delivering the features and functionalities that the business needed.
So we paused. And it's rare that you pause on a program where you're spending millions of pounds or dollars. And we then took the time, and this is big learning; we should have done this at the start: stop and understand what's happening at a process level first.
Because you're right, I often describe people using the technology as ant trails, and they weave their way on a path that works for them, avoiding obstacles and barriers along the way. And that's what people do with systems.
Suppose you don't sit with people who are using the technology. You're never going to understand them. So we did that. We paused for a few months, looking at that process level. It was time spent back on the floor with the end-users, and we learned a lot from that.
Exactly. And you will reap the benefits in terms of time saved on the program project ultimately, if you invest just a small amount of time at the start to do that properly and if you're agile. Time spent in the real world is going to reap the rewards if you do.
Because it's hard work and because it's difficult to take a process and map it out clearly. And there will be so many left and right turns that can happen in that process. So I think it gets too big for people. If you don't have the right knowledge and background experience to do that work in that black belt, Six Sigma background.
And that was a lot of my time, and my team's time was spent doing that heavy lifting, doing that dirty work, holding the pen, going along with people, capturing all of that, and building that knowledge base.
I would ask this question a lot. Where is the process map? Oh, we haven't got a map. It's not written down. So what you need to do is go and ask Mike; Mike's got that. It's in his head.
What happens when Mike leaves? Once he goes, we're going to lose all of that knowledge. So again, you only get that with hindsight. You only get that when something goes wrong, like that claims transformation example that we had to press pause and if we just did this and maintaining those sorts of views of what's happening at a process level, what's happening with your customer journey, making sure that's all understood, It becomes less effort over time because you've got that knowledge mapped out and you're just maintaining and updating it as you go.
Yes, it helped on so many of our large-scale transformations.
I've worked on automation and AI projects, and you were then struggling with the immaturity of the technology and the immaturity of the skills and the ability to use the technology. So bringing just that ability, that vision, and my expertise in helping visualize what's going on across that higher operating model is where organizations need to invest more effort and time to get it right.
I love the customer journey mapping approach. The flip side is, just as important, the employee journey, but they're the same thing. From that, you can visualize what is happening across your business, why it's happening, who's doing it, when they're doing it, and what systems and technology they're using.
But you also, if you're then maintaining it, if it's a living document, you are capturing the hurdles that users or customers are facing throughout that. And we then can go, okay. So let's focus on why is that a blocker? How can we fix that? How can we simplify that and work your way through gradually incrementally improving the customer journey?
I remember one of the businesses invested with an outside agency specialist in creating customer journey maps. They did an excellent job; an entire wall was dedicated to a customer journey map.
I went back to that office over three or four years; the map was in the same place, untouched. It was the same for about four years. There is no way that the products were the same, that the way the systems were working was the same, the systems changed, yet, and the map was the same. So the output is not the outcome.
You've got to keep that document alive and use that to inform and drive where you're heading in terms of the transformation.
I think equally as frustrating for me is people asking me what's the easiest way we can make this happen. Are you invested in what you're talking about? If you're looking for the easiest, rather than describing it as the best way, how can we make something better? So again, it sounds like common sense, but a lot of the conversation that I have is just digging into. Okay. You say easy; do you mean better?
Yes, often. About 2018, people started to get very excited about automation for the first time. And I had people coming to me at that point saying; we want an automation program. We want to pilot this. And there were people on the business side describing it as a way to drive down costs. What they were really talking about was headcount reduction.
That was the only way in their mind. They were going to drive down that cost. We can replace people through automation. So I had to spend a lot of time exploring and helping with back-to-the-floor exercises while exploring what was going on and the real value of automation programs.
Automation, software, robots, whatever you want to call them. They don't replace people. They give time back. They give productivity back. That's what we learned; it's not that we don't need Simon anymore. We're actually freeing up more of Simon's valuable time by taking away those tasks that he doesn't need to do.
I agree as long as those additional layers are not increasing complexity, I think that you have to be careful about what you're introducing and why. Be really clear on where do customers want to interact with your organization online? Where do they still need to talk to a real person? Being clear on those sorts of basic choices, you then understand that and create something that works truly end to end.
There was this data transformation program that I worked on. We were looking at building master data management, MDM. We had customer data stores already, but we didn't know what was in them. People were fixated at the time on cross-selling, and upselling. And they spent a huge amount of time looking at the potential of Mike having home insurance and can we sell him health insurance as well?
The value came from understanding more about Mike as a person. Can we retain Mike? And that then suddenly unlocked huge potential and huge discussions.
And also the potential for understanding Mike and Simon and using that to help with the regulation that was coming along because we were talking about a time when GDPR was front and center. How are we going to manage that? How do we manage consent while you can do that in this MDM technology that we've just introduced because you can capture as much as you want about Mike in there and record consent at a customer level as well?
And when I think about startups, there are great companies in Insurtech. I've had conversations where traditional or incumbents are at risk from startups. Thinking they are going to come and eat our dinner. And I don't think the future is there.
I think the future is going to be one of working together. So how can we take the startup mindset? They can turn out something quickly. They're great at prototyping, but they specialize in a niche, but then they work with the traditional guys that have got scale, understand the regulation, and have a huge customer base. Let's bring the two together to offer something new and unique in terms of features.
Isn’t that what happens when those that have thought about their core technologies and their integrations better than others will be free to connect and collaborate with vendors and partners all around the world because their systems are capable of keeping up with that sort of strategy?
Yes, you're preaching to the choir. Legacy is costly to maintain. About two-thirds of the budget is usually just running existing operations. So we've got one-third left to try and do something new to transform. And there's this view that there's not enough. There's not enough money, but I think it's that traditional mindset of thinking we're going to build in-house.
We're going to do this ourselves. I think the future is a partnership. Work with these great new companies that have expertise. They've got a great product in that niche area that can add that value to what you already have. But what they lack is scale. You've got it.
But if you don't have that big picture view of how your organization works, the systems, how they work, and how they interact with the processes, you can't have that really basic conversation with any third-party company about where the value is in a potential partnership.
I think we're in a different world now after COVID, everyone is looking for flexible working, and companies are in an increasingly shallow pool of well-skilled people.
Suppose we can use technology to augment people's skills and knowledge. And it's almost as if you've given them an exoskeleton suit to make them better. Better people. It's not that we're all competing with each other for the best people.
It's leveled the playing field through the smart use of technology. The best engineer ever within the IT department uses the technology to give you that boost. So that's where I think the future is.
Author: Monica Dumitriu