Applying Data Science to the Insurance industry with Patrick Miller

Welcome to the Canvas Podcast, where we bring on data and business leaders to talk about how to make data easier for everyone. Today I am super excited to have Patrick Miller, the Head of Data at Newfront on the show.

Patrick, do you want to start by telling us about yourself?

Yeah, thanks Ryan for having me. I'm Patrick and I’m the Head of Data here at the Newfront.  We dub ourselves the modern insurance brokerage and it's apt because our industry is very old.  Most of the legacy companies in this space are not tech-enabled like we are. And my role here is to achieve the data-driven vision that is at the very core of our business.

So that's taking us from early in our data journey, all the way to building machine learning-powered products that will create great client experiences. I've been here a grand total of eight months, so pretty fresh. Before this, I managed a machine learning team at Google focused on Google's enterprise problems. And before Google, I was at McMillan, a trade publisher trying to bring data science into another old industry.  So excited to be here today.

How’d you get your start in data?  What drew you to it in the first place and what has your journey been like?  

Yeah, absolutely. So my first job out of undergrad was at a hedge fund where I mostly worked in R to build risk models for the fund. I had a little bit of programming experience coming out of undergrad, and a bit of a math background, even though my degree was in economics and international studies.  But the hedge fund was really the place where we started using data to actually make an impact on the business. I can't say that I'd be very, very proud of the code I wrote or anything like that.

But the focus on business impact and, and solving problems with data, was sort of with me since my first job and it was something that right from the beginning I knew I wanted to do for the rest of my career. I went to Google and worked more on software engineering-heavy teams. But at the end of the day, it's always had something to do with data.  There's just something about the unknowns that come with data and turning data into solutions that you can't really get with other software engineering disciplines.

What are some of the things that you look for in companies as a data leader before you join and what are some key differences in how data is used at the companies you’ve worked for?

Yeah, so yeah, interesting enough. I think each of my job switches was very different in nature. I'd love to say that I had a grand plan of looking for this in terms of the data culture at a certain company, but at the end of the day, I think not really going from the hedge fund to the publishing industry was about.

I wanted to find an industry that didn't have decades of research already built out on how to use data, and solve problems in it.  Like the finance industry, you can go back to the 1950s and folks were writing out formulas for how to calculate the price of options and market publishing did not have that.

And so I was looking for an industry that had new territory to cover. And frankly was kind of polar opposite of the financial services I just wanted to get out of. And then going to Google, they reached out to me, I didn't really say, oh, I want to go to Google. They said, Hey, we have this opportunity to run a machine learning team.

And it's pretty hard when you're early-ish in your career to say no to that kind of opportunity.  Being able to work alongside so many different pioneers in both the data engineering space and more importantly, for me at the time, the ML space. Working with 5,000 research scientists was such an awesome opportunity.

With Newfront, I just got really excited about the idea of using data again in an industry that was really old just like publishing.  There's something about that that is attractive to me. You have to marry a greenfield space along with changing the mindsets of people who've been in the industry for a while in terms of using data to inform the decisions that they're making. But what really drew me to a new front at the end of the day was the opportunity to work alongside some awesome people and a great leadership team.

The data culture at each company was very different. With McMillan, the publishing company, a very old business basically not using data for anything when I joined.  And then Google is polar opposite, right? Probably one of the, if not the most mature in terms of data usage companies in the world, So very different mindsets in terms of the interest in using data and the problems that folks wanted to apply data to.

Whereas at McMillan into a lot of, in a lot of cases at a new front right now, you're really focusing on the base of the data science hierarchy of need. How do we make sure we have accurate data to tell the right story about our business and how do we use that data to fundamentally solve core problems, even if it doesn't require any sort of special machine learning or advanced intelligence?

That's where we're focused on at Newfront and what we were doing at McMillan. So I like to look at it through that lens of where you are in your journey.

What were the problems at Newfront that you knew you had to prioritize first? How did that inform the team and the stack that you needed to build out?

Our leadership team didn't really look at me and say, oh yeah, this is, this is the person who's going to be building out the really basic fundamentals, like the data engineering pipelines to get our data into a centralized location so we can report analytics on it.

They saw my ML experience and said, oh, we have a real data-driven vision that we wanna accomplish. And we want to really create an experience for our clients where we're driving prices down and building a marketplace where we're bringing clients and carriers together and matching up clients' risks to risk takers in the market.

In order to do that, you need to build out that foundation first. And, and so that's what my team and I have been really busy at work doing, which is centralizing and ingesting data from our 30 or so systems. You have a bunch of systems and so centralizing all of that data, cleaning it, putting it into a format that makes sense, and building really foundational analytics on top of it.

Then we needed to get data into our business practitioner's hands so that they can actually start making decisions informed by that data, which requires putting it into the systems that they actually live in.

They're not going to go to Tableau all the time in order to look at a chart or they're not going to switch to another system where that data lives. So making sure we can get that data into the system that they do live in has also been a priority of ours.

Before we get to building data products, which is what I really am here to do, we have to provide data to our clients that no other brokerage can. And those potential clients say, Hey, we're going to Newfront because they've provided these insights that I can't get anywhere else.

How do you decide if you’re going to reverse ETL data into your systems versus having something live in a centralized data tool?

I see it is you either build analytics on something, which often requires a full-fledged dashboard that you can either embed into a system or you can have, 'em go to Tableau or whatever, the online portal for it.  

But a lot of our problems are not like analytics ones. They're “Hey, this invoice just got marked as paid in our Salesforce instance, but nobody on our servicing team looks at Salesforce.” They only look at our homegrown platform, but that data doesn't live in the homegrown platform.

So how do we get the data out of Salesforce and put it into our homegrown platform? That's a lot of those reverse ETL use cases that we're seeing data for whatever reason that lives in another system but needs to live in a system that somebody actually works in day in, day out.

The engineering team has built a bunch of these sort of point-to-point connections, which are a bit brittle at times and time-consuming both in terms of development effort. How much maintenance effort goes into making sure that their pipelines are, are running, and when things break they have to go in and fix 'em.

And so the whole idea of, Hey, we don't really have real-time requirements here.  Let's just pipe this through the data warehouse since we're bringing it in anyways and send it into those destination systems. So that's, that's really the use case we have so far in terms of when we figure out where analytics should live, should they live, should we activate it into our platform or should we embed a dashboard?

What do you think about the relationship between the business stakeholders? What do you think about the relationship between them and your data team?

I'm totally bought into the newish idea of running data as a product team. Where you get out of that servicing workflow. I think you have to do some of that, but really the bulk of the work is running the data team as a product function, I think really resonates with me and, and resonates with the business teams that I work with as well.

I think the big thing in my mind that you need to do, especially in a legacy industry is you really have to dive in and understand your user. And if that means solving an IT ticket for them, that means solving an IT ticket for them and building that sort of trust because without it as you said, they're not going to see you as a real partner. And so, putting in the time and the effort to build up that relationship, understand their problems, understand their workflows, I think is really important and, and has made our work with many of our business teams, pretty successful.

Another failure mode is trying to solve too many people's problems at once. I think it's a pretty common path to success here is finding your power users, like your evangelists, solving their problems, and then getting them to bring other folks along for the ride.

It takes time in a thousand-person company and you have to meet a lot of people and figure out the people who are excited and who has influence. We have some data-savvy folks across the organization.  We have some analysts embedded across the organization as well that often work in Google sheets, that sort of thing.

We have to find ways to provide mentorship and up-level those folks' skill sets. Centralizing analysts can make sense, but you lose all that business context when you centralize them.

We've made a big focus on trying to not disrupt business operations in order to do things in a more efficient way. It’s an age-old trade-off of like how much effort do you want to put into it.

At least you’re citizen data scientists and operators are pulling the data from the data warehouse, which is nice, but you know, we'd love to push some of their workflows in a centralized fashion.

What are some of the signals or prerequisites you see before starting to even think about AI or ML projects?

I think you need to have the basics in place first, right? You need to have decent data first. Right. If you have garbage data, there's no amount of  ML modeling work that you're gonna do that solves your problem.

So you need a very, very basic foundation.  Then beyond that though, I think I'll turn the question a bit on its head because I think it's an anti-pattern a bit too, to think when should I start prioritizing AI in an ML?  I think it's actually a very common anti-pattern that people say that they're like, oh, I want to toss ML at this problem.

In fact, you should be saying, I have this problem - how do I go about solving it? And if you said you had a certain problem and you're going to build this extremely complicated solution to it that's really difficult to maintain, people are gonna say, well, why, why are you doing that?

You need to educate the people who are asking for AI and ML about how complicated these systems are, even if you build them correctly.

So I think you really need to flip the question and say, what's our problem? What's the best solution to it? And really think about how you can solve this problem without using machine learning.

Do the product manager routine of saying what's the impact of taking it to the next step and, and using ML to improve upon the solution. And oftentimes what you'll find is, oh yeah, hiring an ML engineer and spending six months on this is only gonna get us like 5% lift on this project, so let's reconsider whether or not we wanna go down that path at all.

Where can people learn more about you and Newfront?

So Newfront.com is our website. I'm hiring basically across all data roles except for machine learning ones right now. So that'll come next year probably, but looking for data engineers, analytics engineers, and analytics professionals. We're looking for folks who are owners who have an entrepreneurial mindset and are willing to dig in and deal with the hundred-year-old industry that's filled with messy data.