Developer Spotlight: Ali Ghazi, AVP Pricing and Analytics at Sompo

Hi Ali, tell us a bit about your role and the kind of work you do.

I'm AVP in the central pricing and analytics team at Sompo, and my primary focus is leading the development of our property model. It's a significant undertaking: I've been fortunate to work alongside a talented team of developers and actuaries all collaborating on a single model designed to support a wide range of business units across the globe.

Today, a big part of our focus is supporting the business units that are already live on the model whilst preparing new business units to come onboard. That means helping existing users become comfortable with the hx platform as a new tool, gathering and refining requirements for future enhancements, and working closely with upcoming business units through testing and user acceptance. The team is involved throughout the entire lifecycle, from planning and requirements gathering to development, testing, deployment, and ongoing support.

The biggest challenge is balancing today's needs with tomorrow's. Every enhancement has to support future requirements without disrupting existing users. It's taught me that success is as much about people and change management as it is about technology.

How did you first get into modelling, pricing and technical development?

I started out as an actuary and technical development definitely wasn't my strength. I remember struggling through an Excel workbook in front of my manager, who told me, "Ali, if you want to make it, you've got to be better than me in Excel." That was a wake-up call. I threw myself into learning Excel, then VBA, and that became my gateway into modelling and software development.

The real turn came during my second rotation, when a data science opportunity opened up at the same time I was sitting an exams with a strong data science component. The combination gave me a much deeper understanding of why we build technical solutions the way we do, as well as how. There's a particular kind of learning that happens when you fail exams, you have to know the material inside and out to get through on the third attempt.

When the opportunity came up at Sompo with the hx platform, my transition from R to Python happened pretty naturally. More than the technical shift though, I'd say the biggest change was working alongside experienced developers who helped me curate a different mindset. Not purely actuary, not purely developer… something in between. I’ve learned an enormous amount from everyone, and the hybrid way of thinking is still how I approach problems today.

What does a typical week look like for you?

No two weeks are the same. We work in three-week sprints, and a big part of my role is staying connected with the wider team through regular discussions and planning sessions. Given the pace of the project, communication is critical. We have developers, testers, actuaries, and underwriters all working together to take ideas from requirements through development, testing, and release. At any given time, there are multiple workstreams moving in parallel, so a lot of my week is spent helping the team stay aligned, removing roadblocks, and making sure we're continuing to deliver value to the business.

I still spend a fair amount of time working hands-on with the model, but a lot of my focus is on understanding the broader impact of changes. When a new feature or enhancement is introduced, it's not just about whether it works in isolation, it's about understanding how it interacts with existing functionality, how it should be tested, and whether there are any unintended consequences elsewhere in the model. A significant part of the role is thinking through those dependencies and helping the team make changes confidently and safely.

One of the biggest changes since going live has been the shift from building the platform to operating and evolving it. We now have regular interaction with users, which provides a constant stream of feedback. Reporting has been a major theme recently. As underwriters have started relying on the platform in their daily work and they've identified reporting needs and downstream uses for the data that weren't fully apparent during development. It's been a valuable reminder that technology doesn't stop evolving once it's released, often the most important lessons come from how people actually use it.

In your experience, what does a good pricing implementation look like?

At its core, a good implementation is one where the technical solution morphs into an intuitive underwriter workflow. That sounds obvious, but it's harder than it looks. You can build the most sophisticated thing imaginable, but if the underwriters don't care about it or can't use it in the flow of their day, it doesn't matter. Technically sound, operationally practical, intuitive, and scalable: those are the things that matter most, and they don't always pull in the same direction.

The collaboration piece is critical too. There needs to be strong alignment between underwriters, actuaries, and the development team, and clear ownership at each stage of the journey. The rollouts we've been most proud of at Sompo are the ones where the business unit genuinely owned their user testing. When underwriters take responsibility for the testing, the quality of feedback is different, and the impact on both the actuarial and development sides is significant.

And then there's the classic: don't let perfect be the enemy of good. I used to hear that phrase and think of it as a cliché. Now it hits me in the face on a regular basis. You can focus so much on sophistication and operational perfection that you end up delaying things that would have been genuinely useful at 80%. Right now, the property model is kind of like the first iPhone. We have a long journey to make it better and the right approach is to keep making progress and improve incrementally, not to wait until everything is exactly right before delivery.

"You can build the most sophisticated thing imaginable, but if underwriters can't use it, it doesn't matter."

Have you developed any approaches, workflows, or practices that work particularly well for your team?

The one I'm most proud of is our branch management workflow. When you have 4 developers working simultaneously on a model that's live and serving multiple business units at different stages, branch management is genuinely non-trivial. We have business units that are live, others preparing for rollout, features in UAT, and new development all happening concurrently. Getting that wrong creates chaos.

After talking to developers across the team and iterating on what actually worked, we landed on a structure that uses a live branch, a dev branch, a sprint testing branch, and individual working branches for each developer. Getting the flow between those layers right, and making sure everyone understands it, took real effort. The daily stand-ups complement it because no workflow survives contact with reality if people aren't communicating.

One other principle that's been with us since the very beginning of the build is the importance of avoiding lists within lists in the model structure. It was Jon’s advice and it was something we discussed early on, and I've kept it as a hard rule ever since. It saves enormous amounts of headache when you're dealing with the kind of data volume and model complexity that property pricing involves.

What advice would you give to someone just starting to work with the platform?

One piece of advice I'd give is to embrace AI tools like ChatGPT and Copilot. I use them regularly and encourage my team to do the same. Just don't treat them as a substitute for understanding. Use them to learn, move faster, and explore ideas, but make sure you understand what they're producing. The value comes from combining those tools with your own judgment and expertise.

Another piece of advice is to understand the business before focusing on the technology. Take the time to learn who will use what you're building and how it fits into their workflow. Talking to underwriters and understanding how they make decisions is incredibly valuable. The more you understand the user, the better the solutions you'll build.

The last thing I'd say is to expect refinement and not be frustrated by it. Users often don't know exactly what they need until they can see and use something. Build the best solution you can, get it in front of people, and improve it based on feedback. That's not a sign something went wrong, it's just part of the process.

Looking ahead, what are you most excited about?

What excites me most is seeing the platform mature through adoption. More business units will be using it, we'll have gone through multiple reporting cycles, and we'll continue improving it based on real user feedback. I often compare it to the early iPhone generations. We're still building the foundation today, but in five years I'd like us to have a proven, reliable platform that's been refined through experience and continuous improvement.

That's when the really interesting opportunities start to emerge. As adoption grows and we build up data across multiple reporting cycles, we'll be able to unlock better analytics and insights. We're still building the foundation today, but the long-term value isn't just the platform itself, it's the better decisions that become possible with years of quality data behind it.

Final (fun) question: should data schema nodes be defined on one line, or spread across multiple lines for readability?

Multiple lines. I have a clear view on this, and it comes from a practical starting point: we read data schemas far more often than we write them. The question isn't "which is faster to type?" It's "which is easier to understand when you come back to it, or when someone else needs to work in it?"

When you're working with a team of developers, consistency matters more than any individual style preference. I'd use Ruff auto-formatting to enforce it, and I'd advocate for that in any team environment. If you're a solo developer you can do it however you like, but if other people need to read your code (and eventually someone will), you need to be thinking beyond your own habits.

And from a purely practical standpoint: when a node has async input, async output, a label, options, linked options and anything else…. trying to fit that on a single line isn't readable by anyone. Multiple lines, with consistent formatting applied across the team, is just the right answer.