Technology isn’t the barrier: rethinking actuarial transformation

What’s really holding actuarial teams back from getting value out of modern technology? 

In this episode of Risk Reimagined, Technology isn’t the barrier: rethinking actuarial transformation, Steve speaks with Adrien, a career actuary who has spent years working at the intersection of actuarial practice, platforms, and AI. Together, they explore why the biggest challenge today isn’t access to tools, but how organisations collaborate and operationalise them. 

Adrien shares real examples of when transformation worked, and when it didn’t, highlighting the role of trust, early collaboration between actuaries and technologists and iterative delivery over long, siloed builds. The conversation also looks at how AI is changing the pace of development, shortening feedback loops and making actuarial insight more accessible across the business. For listeners navigating technology change, this episode offers practical perspective on what actually drives successful actuarial transformation and what gets in the way!

Mixed & Edited by Next Day Podcast

info@nextdaypodcast.com

Transcript

Abel, Steven 

Hello, this is Stephen Abel from Oliver Wyman Actuarial. I'm a global partner in technology and data, and I am joined here by Adrien, one of our luminaries that thinks long and hard about actuarial technology and actuarial solutions. Adrien, do want to introduce yourself and tell me a little bit more about your background and what brings you here today?

Adrien 

Sure, I'm Adrien. I've worked in the actuarial space for my whole, my entire career. I didn't set out to kind of modernize actuarial solutions, but it's something that I became passionate about throughout my career. And I'm here to essentially discuss this with you. I work for Oliver Wyman and I obviously sit within your team. So it's something that is very much critical to the work that we do every day.

Abel, Steven 

So what possessed you to become an actuary in the first place? And then I'm going to ask a second question, is after taking all those exams, what possessed you to start thinking about actuarial technology?

Adrien 

That's a, it's a very good question because it was very random. Actually, I was at university. did accounting and finance. Then I followed that up with a master's in finance and you know, the typical path would have been to go to a big four or to an investment bank. Um, and it wasn't until maybe the last few weeks of, of my masters that somebody from Towers Watson came in and actually did a presentation at the university. I'd never heard of what an actuary did before then. 

I got interested by what he was saying and then I applied to Towers Watson, having already had jobs lined up with some of the big fours and the process was quick and then I just, yeah, I thought this was for me and I joined Towers Watson and that's how I got onto the actuarial path. So it was very random, very last minute, but I have no regrets. 

I then obviously took a number of exams at the beginning, but the, my focus then, you know, initially my work was very much traditional reserving work. That's what I spent a lot of time doing. But as I was doing it, I would get quite frustrated with some of the manual processing involved, the limited amount of time that I would actually be able to spend thinking about my, the judgment I would put into my work. And so that's where like that frustration started to build. 

And I realized there is so much more that could be done to improve processes, automate certain reserving and actuarial tasks. And so my first instinct wasn't even transformation. It was more, you know, automation at a small scale and mostly for myself and my team where I worked. So it was really just about trying to reclaim time, time to think. That's when I started to think bigger about, you know, how could we use technology better in the actuarial space?

Abel, Steven 

Tell me more about actuarial platforms. And I'm going to anchor on your statement that you could get more control over your life. Isn't the experience of using an actuarial process, doesn't that involve giving up some control? Just tell me more about that balance and how you think about that.

Adrien 

I guess what do you mean by giving up some control? Control over the technology or?

Abel, Steven 

Yeah, so if you have a solution that's used by multiple people, I'm not even just gonna name a platform, let's just say you have anything that's used by multiple people, invariably you're gonna have compromise. Whereas if you have your own spreadsheet, if you have your own thing that you've built, you don't have to compromise at all. You have exactly what you need and it's like a hand in glove. 

So tell me more about why solutions, whether they're vended solutions or other solutions that are shared between actuaries, are better and how you think about that balance between hyper-personalized and customized versus using a solution that might be shared amongst friends, other actuaries.

Adrien 

Yeah, that's a very good question. I was lucky to start at Towers Watson. Towers Watson at the time had just acquired EMB, so probably had the most modern suite of actuarial solutions available in the P&C space. We used Rescue for reserving, for example. And I think there is, when you look at how people would use Rescue and the amount of spreadsheets that they would use around it, even within Towers Watson, but also all of their clients.

You quite quickly realize that actually they weren't necessarily using the spreadsheets for additional flexibility. If you want a lot of the functionality that they would use, that would use in the spreadsheets were already available in the tool. A lot of it was just the way you would use the tool wasn't necessarily as quick or as efficient as if you just had an Excel spreadsheet. Also, actuaries tend to be a lot more comfortable with a spreadsheet. And if they did want to do a bit of a side calculation, they could. 

And then they would they would ultimately bring all of those numbers back into the solution. I don't think when you look at the calculations that the actuaries have to do, a lot of it can be automated. There are very few use cases where the calculations are so bespoke that you need all of that additional flexibility.

I think, you know, where actuaries do come in is where you do the expert judgment. So when you make selections and make judgments, but a lot of actuarial solutions, they don't have anything, you know, nothing is prescribed in the platform. A lot of it is, you know, you already have a lot of flexibility within the platform of how you want to, you know, do your work, what methods you want to use. 

Now, of course, you might have some methods that aren't included in a certain solution and you may need to go outside, but I think those use cases are small. I wouldn't say the, I don't think the actually loses control. I think, yes, they lose the flexibility of being able to do kind of side calculations, but is that really what you want? You lose auditability, you lose traceability of where your results come from. 

So I think the good thing about having a platform is that if you leave an organization and somebody else comes in, they know exactly what's been done. They can trace where their results come from and you know when you do reserving those results are really important for financial reporting you need to be able to trace how the numbers have been calculated you need that transparency so I do think that although you know certain as actuaries we have a mindset that we do want that flexibility we want to be able to do side calculations it can actually complicate the process and you also lose a lot of governance around it.

Abel, Steven 

Okay, so you're in this ecosystem where you're using modern technology, you have auditability, you have efficiencies. Why change? Why leave? You're here at Oliver Wyman. Why did you come here?

Adrien 

I came here because I think like modern technology has changed from when I look at early in my career to early in my career to you know what's available today. I don't think at the time you know technology was still very much changing very regularly but systems were quite monolithic they were quite siloed.

I would say nowadays with modern technology that's no longer a barrier that you can have an ecosystem that brings together a number of tools and they quite easily integrate and talk to each other. think, you know, technology is no longer really a barrier and therefore, you know, I used to work a lot for vendors and now at Oliver Wyman, the great thing is that I don't necessarily work for a specific vendor. And so there is that, you know, I can look at the range of options, whether those are vendor solutions or self builds. 

And I think that's what's really interesting because the way I would like to help clients is not really about making the right decision around which technology to use because like I said, don't think technology really is the barrier whether you go for a self-built solution or a vended solution. There are a lot of good vendors out there. There are a lot of people capable of building their own solutions. There's a huge amount of open source technology that can be leveraged. 

So I don't really think technology is the challenge. How I would like to help our clients is really about how do you operationalize that technology? How do you implement it and get it into place so that it really becomes useful for the business, useful for the actuaries, and for insights from actuarial work to be much better distributed and shared across the organization.

Abel, Steven 

So are you saying that now it's less about, okay, what technology do I pick? And it's more about how do we get the technology to work?

Adrien 

That's right. think the majority of insurers and our clients have accepted that now we live in a world of cloud platforms, scalable compute, APIs, analytics, toolings. Those are no longer bottlenecks. They all exist. So I think it's about how do we put those into practice? How do we implement them so that the actual results are better shared across the organization?

And I think in the past, what we would have is very much siloed functions, even within the actuarial functions, the pricing actuaries, the reserving actuaries, the capital actuaries would all be siloed. But there's a huge amount of insights that can be shared across just those three. But then if you think more widely across the enterprise, you've got finance, underwriters, you know, there are places where a lot of the movement of data between the reserving team and the finance team was still being done by, you know, sending across some CSVs.

In today's world, that should no longer be a, know, everything should be automated. But it's more than just that. It's just once you remove these silos and you've got much more democratized data or insights, those can then be shared a lot more widely with other teams. And so then the actuarial team can start focusing a lot more about, you know, all of that data and all of these outputs that I've put together.

How do I translate that into something that the business can consume and can use to then make better decisions?

Abel, Steven 

So let's imagine two worlds, and I have two different questions for you. If you're in an organization that has achieved this objective, we've broken down silos, the technology's working, what advice or what opportunities or problems should those listeners be thinking about? Where technology is no longer a barrier, where they have broken down the silos? 

And then I'm going to ask the other question for if there are listeners that might be struggling with their ecosystem. But let's answer the first question first, that you're in this happy, actuarial universe, your technology is not a barrier. What are the things that your clients are thinking about that are in that space?

Adrien 

I think if you're in that space, you're managing to capture a huge amount of data. You're able to run that data through a number of models. So I think the question that you then start to ask yourself is, what do I do with that data? I would say, if the technology is in place, I think the team as well, when we talk about technology, technology is one thing, but usually to get the technology in such a good place. Your teams would be a lot more mixed. 

So you'd have, know, actuaries sitting alongside engineers, sitting alongside data scientists, and all working together and trusting each other. So once you've got that kind of operational model and you've got this huge amount of data and outputs, you can really start, you know, building the right dashboards to inform underwriters in terms of, you know, what risk selection they should make at renewal to inform like, you know, senior management.

What are the proactive decisions they can make to stay ahead of their peers and their competitors? So you've got all this, or which reinsurance should I be buying at the next renewal? All this information can be used widely across the company, the business. The challenge is you're going to have a huge amount of data. And so what they should really be focusing on is what do I do with that data? What is the key information I should be extracting and sharing with my various departments? With my leaders in order to get the right business outcomes.

Abel, Steven 

I don't want to come back to that because I'm hugely interested in the topic of innovation and data, but let's circle back to if someone's listening to this and they'd said, boy, that sounds great, but for some reason, maybe the technology I'm dealing with is frustrating or the data's not even fit for purpose to do my day job and I'm spending most of my time doing that. What advice would you have for those listeners?

Adrien 

So usually when it comes to sort of enterprise data platforms and system, that's often done at an enterprise level. So it's very difficult for an actuarial team to be, you know, I'm gonnabring in a data lake house and I'm gonna completely transform how my data is captured. So the first thing I would say is like, is a program, a data program or data transformation program happening at the enterprise level? 

And if it is, I would highly recommend the actuaries to get involved as much as possible to understand what can be leveraged for their specific needs and to make sure that their requirements are also captured as part of that program. A lot of the time, what you end up with is IT teams and data teams working together and they're not quite sure what the actuaries are doing. And so all they know is like, I think what they need is this information because that's what's been provided in the past. And that's all you're going to get going forward, even though you're going to have a new shiny technology at an enterprise level that's not going to be leveraged properly by the Actuarial team. 

Definitely the first thing is if that's happening, the Actuarial team should be, you should get involved as much as possible in that program to see, you know, specify your requirements, collaborate with IT, collaborate with the data engineers to make sure that you, you know, you don't just get what you used to get going forward, but you can leverage that technology to get much better data, but also then to be able to bring your outputs back into the system to then share those more widely across the organization. 

If that is not happening, even at a very small level, I would say start experimenting, start looking at just within the actuarial function, between the capital modeling team, between the reserving team, between the pricing team. What can you do better today? You don't need to think too much at an enterprise level. You can start small. doesn't need to be you know, a big bang transformation to start with, but it's about looking at what are our current frustrations and kind of identifying what those are and looking at low hanging fruits and what could be done. There's a huge amount of open source technology out there that can, you know, that can be leveraged more, you know, the more especially the more junior actuaries. And we're seeing that through our graduates and our graduates and our more junior consultants.

They are very Python proficient. They're very coding proficient. They understand to a certain extent that technology. I would, essentially I would encourage them to kind of fail fast. I would encourage them to experiment. I would encourage them to try and find solutions to those existing frustrations. So it doesn't have to be, you know, a big bang transformation to start with. It could just be small iterative steps and you'll be surprised how quickly, you know, you allow somebody to just start experimenting and innovating how quickly things can change.

Abel, Steven 

So it's about engaging both with the technology around you and the people around you. Tell me about a time where that's worked really well for you personally. And then on the flip side, tell me about a time where you might have struggled with that?

Adrien 

I mean, there's one project that we're currently working on with a reinsurance client where I would say the way we collaborate together is very strong. There's a lot of trust between both teams. We really operate as one single team. And that team is made of, know, actuarial modelers internally, pricing actuaries. We've got the client's reinsurance pricing team. Some of their most senior pricing actuaries on that team. 

We've got the client's IT team and their engineers. We've got our own sort of engineering lead internally and all those people are just working on that same project. And, you know, from the start, we've had regular weekly sessions where what I've been really impressed with, especially compared to some of the previous projects I've been involved with, is just the level of collaboration and trust.

You know, the design sessions that we'd have, the building of a prototype alongside the client's IT team and the communications around that and the teamwork around that has been really strong. And I think the key element there is trust, know. It's trust, also the willingness to collaborate. So think, you know, the pricing actually is on the client's side.

They're based all over the world. You've got in Europe, you've got UK, you've got US business, Latin American business, and they all do things quite differently today. They had a number of raters, all local raters that had a lot of shared functionality, but ultimately were maybe built slightly differently or use slightly different underlying methods. And you could see that they have bought into the project as well. 

So they are also talking within themselves and looking at what is, you we want things to be more consistent. And so there's no infighting. It's trying to find like, is the right methodology to use globally and where there are differences, we will, you know, we will account for them in the build, but those should be the exception rather than, you know, rather than the core functionality. And so I think that project as we've been working through it, I think has been very successful because there's a huge amount of trust and collaboration between the teams.And people are engaging with IT and engineers just as much as we're engaging with the pricing actuaries.

Abel, Steven 

Tell me about a time where you might have struggled.

Adrien 

I was involved in a big project, was an IFR 17 transformation for a client in my previous role. That was a three, four-year program, which involved a huge number of systems changing and being upgraded on the client side. But one of the key areas they were looking at was obviously the reserving side. And so as part of the reserving transformation work, there was a rebuild of the database. 

And there was also a rebuild of all of the reserving methods, tools, if you want, that would calculate the reserving numbers. And ultimately that would also then feed into an IFRS 17 calculation engine that would have to be built and then post things back to finance. In this particular project, I think the challenge was we had the kind of database was being built independently of the actuarial calculations, logic, and so, and a lot of it was down to time pressures, but ultimately it meant that at the start of the program, there weren't much, there wasn't a huge amount of collaboration between what I would call like the database engineers, the database developers, and the actuarial team.

And so what eventually happened is after obviously six months of build on one side and six months of build on the other side came system integrations testing and everything fell over. And that for me is an example where it's not necessarily the unwillingness to collaborate, but it's also time pressure. So it's potentially just the project planning and the realities around trying to do those two builds in parallel were always going to be a challenge.

But the great thing as well about this program is that both teams then started working a lot better together. Because when we got to system integration, SIT systems integration testing, there was no point in pointing the finger at one or the other. was clearly nobody else, nobody's own fault. Everybody was to blame. And so the idea was, let's talk about how do we solutionize this.

And yes, it meant extending the project timelines and the plan, but then we started working a lot more closely together. We started collaborating and things started to fit into place. And yes, it took probably a lot longer than was initially expected to get to a final point where the users could start using the system. But we got there in the end. And then from then on, we then continued with the IFS 17 engine and what needed to be upgraded and improved in the database. 

And that became a lot more efficient working together and the program director on that specific program, you know, it was very clear that, you leave your badge at the door, we work as one team, we collaborate, and I think it was initially the lack of collaboration that caused the first hurdles.

Abel, Steven 

So tell me about a little bit before and a little bit after in that moment where the program shifted. In the beginning, the leader of the program say, no, I don't want you to collaborate? Or how is it working before? then what shifted in that moment to cause collaboration to occur?

Adrien 

It's not that the program director was saying don't collaborate before. think she would have encouraged collaboration. I think it was more about the time pressures to deliver. think it was probably unrealistic from the start to be able to complete the work in the timeframe that was provided and perhaps more upfront challenge or just being realistic at the start would have been the sensible thing to do.

It's not always easy to communicate to somebody that we think it's gonna take longer. You try and be optimistic when you plan potentially that could have been more contingency. But I would say like the real shift is that when things didn't quite work together, this is when we started testing the systems and how they integrated together.

And it was clear that the issues were around the dummy data was not necessarily of the right format. The way we would expect to bring in the data from the database into the software solution wasn't quite fit for purpose. But I think the only way we would solve it is that it wasn't necessarily this part of the system is the problem. was, you know, data and data contracts, need to align on that. How the interface works, we need to align on that. And then how we can make the best use of the data and make sure we don't overly capture, like we don't capture too much data into the software solution, otherwise it would slow things down. We need to work together on that. And I think both sides agreed to that. So I think it started to, this is how the collaboration started really.

Abel, Steven 

I'm going to pause you here. What caused, what was the moment that caused you personally or both sides to say, this pressure is too much. This thing that we're doing isn't working the way we want it to work. Describe those circumstances, sort of this magical moment where the teams are not working together and then make a decision, make a new contract to say, hey, we're gonna collaborate. Tell me more about what happened there.

Adrien 

I think it got to a point where we're in the SIT cycle and the client has lined up a considerable number of resources, of BAU resources to do user acceptance testing on the back of SIT. And we're a week or two away from that. And we realize that is just not going to happen. I think there's no magic in that moment. I think it's just the realization of this isn't going to happen. We need to re-plan.

And therefore, we went through a replanning exercise and said, realistically, how long is it going to take to solve the current challenges that we have, complete SID, and then be able to complete UAT. And so I think that's the moment, if you want, where people kind of got onside. 

And that's the moment as well, as soon as we start replanning, and we're a bit more realistic in terms of where we want to get to and how long it's gonna take us to get to it, then suddenly that pressure's a bit off and you can start collaborating a lot better because the time is there and yeah, like I said, you just have a weight lifted off your shoulders.

Abel, Steven 

Okay, so we have a moment of crisis where there's a realization that without something changing, success won't be reached. What advice would you have for a company or an individual embarking on a new kind of transformation or implementing a new kind of technology? Should they wait until systems integration testing and some crisis to occur or how would you do that maybe differently? Or how would you do that now with a client?

Adrien 

I think six months is a long time in technology and leaving teams to independently build something for six months without necessarily sharing the progress of the build, what the build is looking like is not something I would recommend. I would definitely say that nowadays with technology, it's very quick to prototype. It's very quick to get users engaged. 

It's quick to get other stakeholders or other systems engaged. So I think like realistically every two to three weeks, you should be able, you should be in a position to demo what you've built, what the system might look like, how the system will integrate. So I think it becomes a lot more engaging and collaborative because you can a lot quicker show progress a lot more quickly you can start engaging the users and a lot more quickly you can start capturing feedback. So I think this idea of like you know go build something for six months or a year or more and then show us what you've got I think is bound to be unsuccessful. 

I think the iterative progress you know trying to fail fast in some cases where you know do something, show it, if the users don't like it or if other stakeholders don't like it, then pivot. And I think in today's world, it's also quite easy to pivot from one concept to another because there is so much technology available. Like I said at the beginning, technology is no longer the barrier. And so if you need to pivot, you can pivot. You can change technology stack very quickly. 

But for that to happen again, it's about making sure you collaborate not only with not only with the different disciplines of software development, so the data engineers, the user interface developers, the people that have the business context and the business expertise, but also with the users, other systems that might interact, teams where their systems might interact with the platform that you're building. And really, as long as you've got that collaboration and that trust and you're able to provide regular updates and you're willing totake feedback on board, be willing to pivot, then there's no reason for the project to be unsuccessful. Ultimately, you'll get there.

Abel, Steven 

So the velocity of change now with modern tooling has changed the way that we collaborate with each other.

Adrien 

I'd say so. mean, it hasn't necessarily changed the way we should have collaborated in a similar way in the past. It was maybe more difficult. Like I remember when we would build wireframes design and you'd kind of sketch it out on these kind of wireframe software tools or you'd do something in Excel. Whereas nowadays, it's very easy to kind of spin up a very much, you know, in a few hours, you can have the interface built in the web and show exactly to the users what it will look like by leveraging AI tools and agents to help you with that. 

A lot of that coding can be automated. So all you need to specify is this is what I want my screen to look like and then make a few adjustments and here it comes. So think there's a lot of efficiencies on the software development side, which then allows for more collaborations for developers and software development teams to capture better feedback because the user then can really see, this is what my workflow is going to look like. That is what my screen will look like. And I think it's much easier to visualize than even by just looking at a sketch.

Abel, Steven 

Now, you mentioned AI. Tell me more about what AI is unlocking for you personally and for our clients.

Adrien 

I mean, I use it day to day to support me with the work that I do. That could just be kind of even just helping with putting slide decks together or documentation, meeting notes, simple things. But I think where I've seen the most benefit over the last year has definitely been with the pricing transformation work that we're currently doing with this client. 

The team uses it day to day with kind of helping to build screens, helping to accelerate the development of a prototype or accelerate the development of a feature to then be able to demo it to the client and make sure that this is the right thing that the users need. I can't think two years, three years back, I just don't think that would have been possible. And so we're getting a lot more regular feedback.

And I think that means we're in a much better position to align with the stakeholders more quickly. We're in a much better position to make decisions around what should be prioritized, should not be prioritized, what is it nice to have. We're in a much better position to build the backlog. And so as soon as we start this build phase, then we are in a much better position because we're already starting with a very good framework, a very good prototype. And now it's really just about productionalizing it.

So I think like in the past, if you look at the design phase, that would take six months. You'd still probably have another year or two of long development work to take that design and build something. And you'd have a lot of challenges along the way. Now the transition is a lot more smooth because you go from something that's already pretty concrete where you've already built, you've already got a lot of code that you can leverage. You've got the prototype and moving into the build phase is really quite smooth. Is it really a separate phase? You know, really it's just a continuity of the work that we've been doing.

Abel, Steven 

So compare and contrast, and we were talking earlier about the importance of gathering data and weaponizing data, and then you were just talking about AI in terms of just everyday innovation and being embedded in your life. How should our listeners be thinking about that in terms of where should they be focused? Should they be focused on using AI to do other jobs more efficiently and their and work their lives more efficiently? And how does data factor into all of that?

Adrien 

How does data fit into all of that? I think. No, I do think once you've, you the foundations of AI tooling is having good data. If you don't have good data, can use as, you you can, you can leverage as many AI tools as you want. You're not going to get the right outputs from them. So I think if you're in a place where you have captured, you know, a lot of data, I think you're in a very good place to start experimenting with AI. 

And that's not just to, you know, that's just not to, not simply to support your day to day work. But think about using AI to kind of interrogate that data. You know, we talk about, I talked about dashboards and sharing insights with the wider business. could, you know, it doesn't need to be at dashboards. It could easily be an AI tool. So for example, you could have your CFO sitting in the morning and just chatting through an AI bot and say, you know, what's my actual versus expected looking like at the end of last month? 

You know, what do I expect my reserving liabilities to be at quarter end and rather than having a look at just a pure dashboard, you know, the AI tool is able has access to the underlying data that the reserve that the reserving team has, you know, captured and included within, you know, the enterprise data systems and, know, suddenly. You can see that, you know, there's a huge amount of people that don't necessarily need to have all of the complex actuarial methodology understandings, but they can start querying some of the actual outputs in plain English and just getting what they want from it.

Abel, Steven 

We mentioned at the beginning that in the beginning of your actual career you were frustrated because you really wanted to interrogate data to gain insight. Is this just another wave of actuaries now having more powerful technology to interrogate data to generate insight?

Adrien 

It is another wave. think this one's been pretty, you know, it's a pretty spectacular wave. I don't think we've necessarily seen the same level of innovation that we've seen over the last five years. You know, before that, I think the speed of change now is a lot more, there's a huge amount, it's a lot more fast, right? The technology is changing a lot quicker. And when you look at what AI tools were able to do two years ago versus now, that it's already shifted massively. 

So, yes, it's another wave, but I think it's a critical one. And I think Actuaries should be looking at leveraging as much of the technology that's out there, but not just the technology, also the people, the skill sets, to think a little bit outside just the Actuarial world too. I would encourage Actuaries to collaborate a lot more with their IT team, with their data engineers, with data scientists and just experiment and see what's possible because each of these disciplines bring a slightly different angle and a different perspective. And the results are usually very, impressive.

Abel, Steven 

I love the word spectacular. What excites you the most about the future of actuarial work?

Adrien 

I think actuaries are going to become, and as they've already become over the last 20 years, but they're going to become more more influential within a business. Businesses are moving towards a lot more kind of data-driven decisions. Data is becoming a very core asset to the business and a core driver of decisions. There are no better people within an insurance company than actuaries to understand data.

Now, obviously insurance companies have also hired in a lot more engineers, software developers, data scientists. And this is where I think like, know, collaborating and working together, bringing those skillsets together is where I think the, you know, the business will get the best outcome, where people will start understanding the data better, knowing, you know, what data to rely on to make certain decisions and also just being able to share the data more widely across an organization

Translating it into the insights that different departments need so that they can do their work better, make better decisions, and ultimately that innovation will continue as that democratization of data and insights continues to evolve over the coming years. And so I think, the actuarial profession for me is in a very good place. think actuaries of today shouldyou know, have that kind of mindset of, you know, let's collaborate.

Let's look at what is possible. Let's experiment. Let's try, you know, obviously the actuaries focus should be on the expert judgment, but there's still so much work being done around manual processes, data checks. All of that can be automated. Just, you know, yeah, I think it's frustrating because sometimes I see it where, where, where people tend to still prefer kind of the siloed approach, but I think, or there's a lack of trust and therefore they don't feel like they can collaborate. But I would really encourage, sometimes it does take time to build those relationships, to build those, to bring those teams together. But you won't succeed if you don't try. 

And that would be my big recommendation is try, try and collaborate with your data scientists, your software engineers, your data engineers, and really work together to experiment, see what works and you'll be surprised at the level of success you'll get and how quickly your systems will develop and innovate.

Abel, Steven

Adrien, we've covered so much from your early days as an actuary to the collaborating, connecting, trusting, dealing with technology. If we had to wrap, what key advice you mentioned, just engage, try? Two or three things for listeners to really remember from the session to wrap their mind around.

Adrien 

You know, first thing is technology is there, the technology is available. So I think the biggest shift required is cultural. It's towards collaboration, experimentation, and critically to trust each other and trust each other across disciplines, because that's the only way you'll be able to collaborate. And I think if we get this right, know, technology is no longer the key challenge or barrier, and actuaries will become more influential, not less. They will be much more involved in proactively steering the business and you know, think that's where we should want to be, that's where we should be.

Abel, Steven 

And if someone wanted to continue the conversation, how would they reach you?

Adrien 

If you want to continue the discussion, I'd be very happy to discuss this with you. can reach me on my email address at Oliver Wyman, which is Adrien.denazelle at oliverwyman.com. Or you can also just connect with me on LinkedIn. I'm quite easy to find. There aren't many people with the same name. So Adrien de Nazelle, connect with me on LinkedIn, send me a message. And I very much look forward to having those conversations with you.

Abel, Steven

Adrien, it's been a pleasure. Thank you.

Adrien

Thank you very much, Steve. Thank you.