[00:00]
Nick Brown: Technology is a product now. So we're not just going to market talking about the standard insurance products, but we're also talking about the technology that backs those — our digital capabilities, our apps, our connectivity. All of those things are becoming more and more important.
---------------
Ansel Parikh: Welcome to another episode of The Current, a bi-monthly podcast exploring the intersection of people, finance, and data. I'm Ansel Parikh, co-founder of Finch, the connectivity platform for the employment ecosystem. And today I'm joined by Nick Brown, Head of Benefits Technology Strategy at Guardian. Nick leads the strategy behind Guardian's Benefit Technologies ecosystem, the API and data exchange network connecting the carrier to more than 30 benefits administration and payroll partners.
Before Guardian, he spent years in product and delivery leadership at Lincoln Financial and built out a project management office in Group Life Claims at Liberty Mutual, which gives him a rare end-to-end view of how big carriers actually ship change.
Nick, welcome to the show.
Nick: Yeah, thank you for having me.
Ansel: So before we get into Guardian benefits and the whole tech strategy there, I think I'd want to understand your path, since you've spent a lot of time at a bunch of different leading carriers. And people like to know how you get to own technology strategy. Usually it's someone that comes up through engineering, but you came up through the delivery and program management and getting things shipped inside a large insurer. So curious, can you walk us through your journey to where you are today?
Nick: Yeah. It's an interesting journey; I think everyone's is. To your question, I feel like I've always been tech savvy. I've always liked gadgets or understanding how technology works. But I'd say I know enough to be dangerous. I can read basic code, but I certainly can't write it or understand all the languages.
When I first interned at Liberty Mutual, I was writing some business requirements and working with some of the product owners. And then I fell into project management, program management, really enjoying the challenges of working on something new, and it kept stuff fresh for me. And then when I joined Guardian, I was building out the direct-to-consumer retail products and supported some of the technology that was required to sell that in market.
So in my current role, I'm able to do some market analysis, build consensus around our strategies, and then I partner really closely with our tech leads and our developers to then execute and make it a reality. So I think part of why I was hired into this role is I can hopefully bring a little bit of a different lens to the work that we're doing and think strategically as well as understand the underlying technology.
Ansel: It makes a lot of sense. What are different ways that has shaped your approach to monetization, or at least to looking at innovative new products or solutions, that maybe differ from someone that you work with that is more purely technical, really thinking about it from that lens?
Nick: Yeah, I think if you're purely technical, you're often thinking about what's in front of you, what you can do, what you can't do. I try to talk to peers, grow my network, understand what other carriers or even other industries are attempting, and then bring that lens back to say, all right, well, I know we haven't tried this before or it hasn't traditionally fit into our model, but we've got new tools, we have new technology. Is there a way that we can incorporate that? So I think we have to constantly compare ourselves to other industries as well that maybe are more agile and can move more quickly, but eventually we can get there and find ways to incorporate similar stuff within the carrier world.
[03:50]
Ansel: Yeah. That's really interesting. Well, what I'd love to dig into a little bit more deeply is this idea of turning employer data into something that a carrier like Guardian can actually run on. And there's this component of access and then actually action, because oftentimes there's 2 separate processes.
And so what does that distinction mean day to day at a carrier? Is there a point where the gap between having the data and being able to actually operate on it really becomes obvious? Are there certain use cases or things that you found where it's like, yeah, having data is half the problem, but what do we do with it is a whole different set of questions?
Nick: Yes. The employer and employee data is extremely important, and we leverage it throughout the lifecycle. So we need census files at time of quote so we can better understand the rates. We need enrollment files and demographic data when someone enrolls in their Ben Admin. We want to make sure that that then is seamlessly incorporated into the carriers' platforms.
We also need payroll and employee data for claims. And often getting this data has been a challenge. We've accepted data in various formats from various stakeholders. We're getting data wherever we can, and we've been open to even having manual steps to reach out or obtain that data and then get it into our systems, which is not something that's scalable. But you're right, we need that data, so we'll get it how we can.
I think with the prevalence of APIs, we've been able to get this data much more efficiently. We know where to get it. And with APIs, we can actually go and capture that, and capture it more real time. And then it's in a more reliable format as well. So we're able to then orchestrate that data to up and downstream systems, and all in all, that can lead to significant efficiencies and just better ease of doing business.
Ansel: I definitely resonate with the format, especially since I think the industry has run on EDI for decades. And those aren't necessarily standardized. There's always challenges with that. A batch 834 sent weekly, or sometimes even 8 to 12 weeks to even set it up for a new group. But you've really pioneered this Guardian Access, which puts real-time APIs really at the forefront.
But for someone who's never really had to maybe care about file formats, can you just explain a little bit more why that shift from EDI to API is such a big deal? What's the impact, and why is it taking so long?
Nick: So I certainly don't want to diminish EDI, because it's a fantastic step up from the world before EDI, when everyone came together and said, "Hey, let's standardize this file format." Because before it was paper enrollments, unstructured census files, custom file feeds. And so I think EDI was a big step forward from those other formats; API is the next iteration.
And so I think EDI often requires a firm to help the customer build and maintain the file, and that can take 2 to 3 rounds of testing. It can be expensive, and they have to then maintain it. Also, the data then is shared with Guardian on a weekly basis. And so the biggest difference between EDI and API is not necessarily what we're getting. It's rather that we build directly to a Ben Admin. And so when that is turned on, we don't need to test with every individual customer at that point. We know that that API is supported and live. And so when we turn them on, we can start getting that data right away.
It also often comes without a cost. So there's certainly no cost for any of the APIs that we offer at Guardian. Some of the Ben Admins have some cost, but for the most part, they're available and free. And so you would eliminate some of that need to have these build firms creating and maintaining those files.
And then the data also comes to us real time. And so we get that data the second that Nick Brown goes through and files enrollment. And then Ansel, if you did it 2 days later, we'll get that real time as well. And the APIs allow not just the data to come in, but we also can share data back to say, hey, we received this, it's successful, or there's errors, or there were successes with warnings, and you can put that in platforms that are in front of the employers and the employees, rather than having to come out and get a report from us or an email or things.
So that's just a few examples of how the API is streamlining things. And moving folks off of EDI has been taking some time, but I do see we've had double-digit adoption year-over-year growth changes the last 3 or 4 years. So it's snowballing and taking off. And for most new business that we write, we're seeing APIs being talked about early on, that they want to turn those on.
[08:55]
Ansel: Is there something that's driving that acceleration? Is it behavior, expectations, all the above? Curious if there's something that you're starting to see in those last 3 or 4 years that you're like, finally, we're making progress.
Nick: Yeah, I think there's a few carriers and a few Ben Admins that have been doing this for many years and could see the light at the end of the tunnel, and they thought, this is going to be great. But it's scary to jump and try something new, especially if maybe you've been with a carrier and you've had EDI for quite some time — it's steady. Like, why would I go and take a risk to change that in flight? So I think we've seen a little bit of a hesitancy to move in-force groups from EDI to API, for example.
But that's starting to change, because now it's FOMO. They don't want to miss out on the new technology and what others are doing. I do think we see a higher propensity of groups that are new to Guardian saying, okay, cool, well, while we go through this transition as new business, let's make that transition to APIs. But even still, there's some that are just like, hey, we've had this working really well for a long time. We didn't make a lot of significant plan changes, and so let's just stick with what we know.
But again, I think we're seeing the industry understand the benefits. And they're being talked about a lot at finalists, when maybe 2, 3 years ago it was like a footnote.
Ansel: Yeah, it makes sense. It's those tech adoption curves. You've got those early adopters, they start to say, look, there's major benefits here. Then you start to climb that curve. There's always going to be these laggards that are like, look, if it's not broken, I don't want to fix it. And that is what it is. But over time, when you get 80 or 90% of the market moving toward one direction, you start to see this just massive benefit across the whole ecosystem.
And I know you have a lot of experience building APIs, building to APIs, and that it's actually usually easier said than done. But with Guardian, they continue to expand the API portfolio. And you all recently announced partners like PrismHR and Rippling, which were able to cut down those plan setup periods from weeks to days. So can you walk us through maybe one of those and what it took to actually get to, hey, we've got a working API connection with one of these providers?
Nick: Yeah, so building APIs with vendors is fun, but it's also challenging from a technology perspective. So when we first get these groups together, we have to go through the contracting, the third-party risk management, all those things. And then we get together and say, all right, well, how far apart are we from a technology perspective? What do you have versus what do we have? Are you following a standard? Are you not? Is this going to be custom? What's our testing protocol going to look like? When are we trying to go live?
And I think a lot of the challenges that I see is not only managing the internal teams and the resources that I have, but then you're coordinating with another vendor and all of their priorities and leadership expectations and delivery timelines and things. And so bringing those together can be challenging to land that plane. But it's also really rewarding when you do get something over the finish line.
Ansel: Lining up roadmaps and engineering timelines is no easy feat, especially between maybe 2 large companies that have about 50 things planned out through 2027 already. But maybe with any one of those processes, was there any part of the process that surprised you? Maybe it was an unexpected challenge, or maybe something that was actually easier than you initially anticipated.
Nick: I find the easy part to be the people piece. You meet a lot of really experienced and passionate people that want to improve the customer experience, and so that's just motivating in itself. The challenging part is what I mentioned — trying to orchestrate and time things together in market.
But I will say, with the changing of technology, it's getting easier and easier to connect. And we're building some standards and things behind us. And I think we're picking up speed. Every connection that we make with a new vendor seems to go smoother or quicker. And I think that's partially because we've done it 20-something times previously. But also I think just the industry is getting smarter, the technology is getting easier, and we're able to make tweaks and changes more quickly.
[13:28]
Ansel: Yeah. Hopefully by the 20th time you start to get a little bit of a rhythm in it and know what questions to ask. But every one of these is a little bit bespoke. And that leads to the next question I have, which is more around this build-versus-partner question that sometimes becomes this underlying question underneath it all when you're evaluating, hey, how do we expand that customer experience to more customers?
And I think your former colleague Josh Weaver framed middleware as this answer to a hard limit — that as a carrier, there are only so many API connections you can build. So at Guardian, how do you decide what you build directly versus what you reach through middleware providers?
Nick: So we've been a big proponent of middleware from the beginning, and we think that there's certainly a spot for middleware to be successful. But we've also seen a lot of growth and adoption of Ben Admins asking for direct connections. So we do have to have this discussion.
To your point, I want to make sure that we're monitoring the day-to-day supports and we're putting out fires or escalations if there are any problems.
Even if they make it really easy for me to turn on the initial connection, there are all these other things in the background we'd be considering. So that's the point. You get to an area where, look, we need you to either be this big or have this much business or whatever. There are certain criteria that we might talk about. But at the same time, crawl, walk, run methodology — the middleware comes into play where we could say, you're maybe not at a point where we want to do a direct integration today. But if you work with this middleware, overnight, theoretically, you get connectivity to Guardian.
And then we can see how the business grows or how the connectivity works and how quickly we can set that up. And then that helps with future conversations of, are we good with the way that this is set up now, or would we want to explore something more direct? So that's the approach that we tend to take.
Ansel: It makes sense. I like that you've approached this as, look, you have to operate with different delivery models, different approaches. Because again, you only have so many resources, so much time. And it's important to de-risk some of the ones where you're like, well, I don't know how this could turn out, but at least if I can get it turned on tomorrow with minimal outset on both parties, it creates a path to validate things and go, okay, there might be something more here. Doing something deeper together might actually make that customer experience really valuable for a large set.
Nick: And sometimes you also want to be able to catch those flyers. Sometimes you want to take a risk on somebody if you really think that they could grow into something significant. So it's like, yeah, sure, if you're a behemoth and we don't do a lot of business with each other today, it makes sense. Let's do that. But I get approached by a lot of groups that are figuring something out, they're onto something, and we're trying to take an educated guess on the ones that we think will continue to grow with us.
Ansel: That's super interesting. It's almost like you're doing a little bit of venture capital over there, where you're like, look, I'm taking a bet here, but I can't put all my money into this because I only have so many items on the roadmap I can work with.
And so when you think about modernization at a company like this — I think Guardian's 165 years old — making change inside an organization that has that much institutional knowledge, institutional processes, can probably be pretty daunting to someone from the outside. So how do you get this agenda funded, shipped inside this type of institution? Where does the resistance come from? How do you navigate that so that you line everyone up to go, okay, yeah, we have to do this, this makes sense?
[17:41]
Nick: I know. I've only worked for really old companies. But 165 years is pretty impressive. Maybe someday I'll join a company that's a few years old and it will be like a total awakening for me.
But insurance and group benefits in particular, I think, faces a lot of challenges when you try to modernize. Carrier systems can be antiquated. They've got a lot of history, and that means also probably a lot of complexity slowly built into those systems over time. And you've got an active book of business that you don't want to disrupt. So all of those things mean modernization is a challenge, and I see all of my peers, all of the carriers out there, in various states of their own journey to modernize their systems.
And so the other thing I would mention is that we're in a highly regulated space, so that's a challenge too. An example would be, hey, we want to move away from paper, go fully digital in one part of our product or solution. And the regulations or compliance might say, you have to offer digital and non-digital solutions. And so we have to also be careful about what we build and how we meet our customers at different places.
But that said, I think Guardian has been super progressive. The executive leadership team are constantly talking about new technologies. And I think they're starting to recognize that technology is a product now. So we're not just going to market talking about the standard insurance products, but we're also talking about the technology that backs those — our digital capabilities, our apps, our connectivity. All of those things are becoming more and more important.
And I'm glad that our leadership have recognized that early and continue to invest heavily to grow out my space and the digital space, and do some other modernization activities that can help us stay relevant in the market.
Ansel: Just because the industry moves very slowly doesn't mean you can. And so I think being deliberate makes a lot of sense, but also being willing to take risks — calculated risks — in certain areas can really propel you to the next stage and really set the standard for how things should be done the next 5, 10 years.
So with that, where is all this heading? If I wanted to zoom, I don't know, 5, maybe 10 years ahead in time, and APIs are table stakes — every carrier has an exchange that allows them almost near real-time data access — where does the next phase of differentiation come from?
Nick: So what's interesting is it used to be, in my space, APIs were really to Ben Admin systems. You were getting plan designs, evidence of insurability, and enrollment passed. Those are the core 3. And so that was the first place of differentiation. People were racing to build those out with some of the key Ben Admins and then scale that quickly. And so as that's become more and more like table stakes, we've seen carriers, including Guardian, come together with LIMRA to talk about how to standardize that behind us.
So, like that standard 834 file, at some point we're going to have standard LIMRA APIs. And I think we're getting there. We're seeing a lot more groups coming saying, yeah, we'll build the LIMRA standard. You've got that? Great. And so that allows us to scale more quickly with those core ones. But now it means the carriers are less differentiated by the core APIs and are moving on to leave of absence and billing and claims and provider, and there's broker technology.
So it's very quickly exploding, and we're saying, hey, there's all these other ways that we could use APIs in a similar manner but with different purpose. And so can we get data from this vendor over here, orchestrate that data into our systems, and remove steps that we used to do previously? Or the broker sends us stuff via email, and then we respond via email, and they attach links, and those links are different from the guy who sits next to them at that brokerage that sent us a different link. And so we're finding that we can also standardize the type of data and speed up, using more modern technology than email, to make sure that we're actually moving data between systems and we don't have people typing it into 3 different systems. So I think that's where we're seeing differentiation now.
And even as you fast-forward 5 years, some of those things I just mentioned will also start to feel like table stakes, but we'll be on to the next thing. And so at least for the next 10 years, I think there's a lot of work to be done, particularly in this digital and benefit technology space, and I'm very excited about all the stuff that we've got cooking.
[22:25]
Ansel: To finish this off, speaking of work to be done in the next 5 years: given everything we've talked about today, some of these major shifts that are happening, how do you think they're going to impact the way your job looks in the next 5 years?
Nick: Yeah, so we made it pretty far not talking about AI, but I think inevitably it needs to come up in some part of the discussion. And AI is certainly changing things in my world — not as dramatic as sometimes you think it might — but we're seeing that AI can help augment some of the requirement gathering that we might do. It can augment our development and our testing.
And so we can shrink some of the dev and delivery timelines. But what it's not shrinking is the ideation and the new places we could go, the partnerships and the relationships that you have. And so I think a lot of what we're continuing to do is lean in there to make sure that we have a good roadmap. We're thinking a lot about what's next, how we could go deeper, how we could differentiate, and at the same time hope that we can do that in a reasonable period of time as we see AI and other digital tools improve how quickly we can go to market. So that's what I'm envisioning over the next few years.
Ansel: It's going to be an exciting couple of years. I am definitely looking forward to catching up in a few years to see what's happened since then. But in the meantime, I really appreciate you coming on, Nick, sharing your perspectives and really talking about both the past as well as the future of this benefits technology ecosystem.
Nick: Yeah, my pleasure. This is always fun to do, and I love talking about all things ben tech. So thanks for having me.
Ansel: Thank you.
