E102 - Software & Automation of the Insurance Backoffice with Phil Reynolds, CEO of BriteCore

Join us at Insurance Nerds Day, Saturday, October 6th in Chicago. Go to InsuranceNerdsDay.com to register!

In this episode of Profiles in Risk, I spoke with Phil Reynolds founder and CEO of BriteCore. The insurance back-office is rarely discussed in insurtech circles. It is generally an afterthought. Yet, as I have learned over the past year of creating my startup, the back office functionality of an insurer is vital to the proper functioning on the company and mistakes there can have deep financial and legal consequences. One other thing I found out, the back office is difficult to manage. Insurance transactions are enormously complicated and in this episode, Phil goes into details of this complexity. 

I also learned that Phil fell into insurance like many of us and had a prior career in music...and has a killer microphone, which generated better sound quality than your host's 😔. How interesting is insurance back office technology? Interesting enough, that we spent over an hour discussing it and I feel like we just scratched the surface. 

CONNECT WITH PHIL REYNOLDS: 
LinkedIn: https://www.linkedin.com/in/phillipreynolds/ 
BriteCore Homepage: https://www.britecore.com/ 

MENTIONED IN THIS EPISODE:
CPCU designation & courses: https://goo.gl/jLxgxc 
INS designations and courses: https://goo.gl/rDb9ew 

BOOKS RECOMMENDED BY PHIL:
Enlightenment Now by Steven Pinker: https://amzn.to/2vDgvZI 
Thinking Fast and Slow by Daniel Kahneman: https://amzn.to/2vGa1sO 
Tribal Leadership by Dave Logan: https://amzn.to/2MjCuhK 
The Fifth Discipline by Peter Senge: https://amzn.to/2nBbHzC  
The Power of Habit by Charles Duhigg: https://amzn.to/2nyYBCT 
Non-violent Communication by Marshall Rosenberg: https://amzn.to/2KTbsJ8 

SUBSCRIBE AT:
Buzzsprout RSS: https://goo.gl/5K4X3Q
Google Play: https://goo.gl/WMAvW4
iTunes: https://goo.gl/7SqwvP
Overcast: https://goo.gl/8b4cbD 
Spotify: https://goo.gl/niAbGN 
Stitcher: https://goo.gl/DmE7Mi
YouTube: https://goo.gl/1Turar

Transcript

Speaker 1: 0:00

This episode of profiles and risk is sponsored by insurance nerds day. Teaming up with the Gamma Iota Sigma International Conference Insurance nerds is proud to host the single day of that. For years, we have dreamed of a different type of insurance conference, a half a day of to the point Tedx style speakers, half day of learning labs, which will include hands on skill building sessions, featuring the experts of the insurance ecosystem for many different disciplines and insurance, jeopardy hosted by yours truly lots of networking opportunities and we're even hosting this on a Saturday so you don't have to lose a vacation day insurance nerds day. We'll be in Chicago on Saturday, October sixth. The price is only$99. Register now@insurancenerdsday.com. That's insurance nerds day one word.com. I hope to see their cue, the music

Speaker 2: 0:56

profiles in risk hosted by Nick[inaudible] rally every week. We interviewed those who life limb fortunes, Korea and reputation, and those who work behind the scenes. You look to protect and enlightened us about risk. You can find the show notes and other insurance related content at[inaudible] dot com. That's Ins n e r d e s.com. Now onto the show.

Speaker 3: 1:38

Hello everyone and welcome to profiles and risk. I'm your host, mcnabb. We're really like in this episode, I am very pleased to introduce Phil Reynolds. Still is the co founder and CEO Yo

Speaker 1: 1:49

break court, right core as a company building enterprise software platforms that coordinate and manage administrative functions for insurance companies and Mgas. Phil, welcome to profiles and risk. Thank you very much. Nick. I'm happy to be here today. I have to tell you, you've got the perfect microphone. I got to get one of those million years ago before I did instruct, you know, insurance was a famous joke and insurance that nobody intended to go into the insurance. It's the next day for all of us. That's right. And I, uh, I actually started out my career as a professional songwriter and studio engineer and ended up in insurance software. And now I read one of the larger insurance software companies in the country for the songwriter and no. And, and a children's songwriter. Nonetheless, so most obscure career path in history, let's not forget to tap to touch that topic before we end this podcast. So to kick it off, I want to give you the opportunity, uh, I gave my description of what bright core is. In your words, in your own words, could you describe[inaudible] and what you do? Yeah, absolutely. So the bright core is a, is a collection of services that we have built that target insurance processing and um, so technically as a platform, that's what it is, but as a company, as it, as a mission, as a vision, what we're trying to do is we're trying to build services that target the general use cases and insurance and then, you know, tunneling down into specific use cases, but specifically, um, deliver software in a way that is lighter weight that is more connected that centers on like a micro services architecture. And so all the things that you think of in terms of like legacy software and insurance, it's slow, it's hard to upgrade, it's incredibly expensive. We're trying to solve those problems for the insurance industry, utilizing the best of what modern technology, modern software practices are and bring all of those to the insurance industry. Awesome description. Clearly there's a. there's a big nut there that we're going to crack. Now. I want to get that small job. I want to get back to children's song writing. So how does someone that was doing that transition over to someone that's in that boring insurance industry? It please connect those dots. Okay. Yeah. So I mean it's a, the relatively boring story I think, but I, I used to work there in recording but I, my degree in college was electronic media production which included digital music production and also digital design and so I on the side but do websites with my cousin and I was the designer of the front end guy, that javascript guy and we got asked to do software for bank and one of the board members on the bank, um, was the CEO at, at a, a mutual insurance company asked us to do. I'm a quoting system for his agents. They loved it all. His buddies called us, quit our jobs, started our companies are doing quoting systems, um, got apply for customers and a few years in and then a bunch of our customers came to us and said, hey, we like our quoting systems a lot and we really hate our back end processing systems. Would you be interested in replacing all of the admin functionality that we do? So, you know, policies, billing claims, data warehousing, policyholder cell service, all those things that we do now. And so one of the cool things about the way that our company got its start is that we were not backed by like a big venture firm or something who said, hey, we're going to go tackle the insurance industry instead. We were a very organic movement that arose from within the industry itself. The industry said, hey, there's a need. We, the industry players in industry will go, we will sponsor this, will fund this and we'll make this happen. So one of the things that I think has been an advantage for us from the beginning is that we've always had client need squarely in our focus because we were, you know, that that was our genesis. We came from a client sponsored initiative and so, so that has driven a lot of our subsequent culture in the company to sort of have a focus on client success. How do we make the client successful, make the client successful, make the client successful. We almost never talk about, you know, quarterly profits or you know, we don't even really track our growth all that carefully. We're growing really fast, but that's just because we're just focused on how do I make you my customer? Awesome. What do I do about that? Yeah. Know what I think is most interesting about that is you didn't have to hypothesize about what your clients want it because they literally asked you, yes, yeah, they handed us do this exact thing. Now it's interesting because it also is, it's a liability as well because I'm the original customers that came to us. We're the smallest of the small customers and insurance industry. So those early mutual insurance companies were writing like three to$5,000,000 in premium, which is, you know, very tiny but insurance carrier standards, um, so the original versions of bright core that we built, um, targeted a very small premium volume use case which has all sorts of ramifications for permissions and you know, business rules engines and configurability and all those different things. Um, so, so unlike in sort of like a guidewire or duck creek, some of the really big players, they normally started in like a claim system, our rating engine and they did it for the really high end of the market and then slowly expanded their footprint into new verticals. We started in all the verticals but at the smallest possible scale. And we've been just like growing, you know, the, the overall in each of those verticals like this as we go. And part of why our company is receiving a lot, a lot of press right now is that in the last year or so, we hit sort of that critical mass point where our capabilities in a lot of those different modules are such that now significantly larger insurers are starting to look at us and we have this integrated suite that does all the things and so, so it's just been a really interesting, totally backward story. And you know, I was just working at a recording studio and happened to get asked to do a website for somebody. So the rest is history. Yeah. And it just unfolded from there. Okay. So could you talk about your sweet and I want to really dig into the administrative part of an insurance can be because I'm going through that now and I don't think there's enough attention. It's talked about back office. It's kind of like a, a bucket, these kind of. Oh that's back office. You throw it in there. But you, you mentioned all of the different silos. Could you talk about all of the, the important back office functions and administrative functions that occur? At an insurer or an Mga that now bright core has to take into consideration. Oh, absolutely. No, I could do that. Um, so there are a ton of them just to give you an, a, the high level. So bright core is I'm currently, one of the major things we're doing in our own ecosystem is we're rebuilding under a true microservices model, so I wouldn't even have time to go through and list out the 300, 400 microservices that makeup right court, but a lot of those micro services group together into what people would think of as a product in an insurance value chain. And so that, that's probably the scale that is useful to talk about. Um, so to give you an example of what some of those products look like, um, we kind of divide them up into five different categories and they are all, all five different pieces are critical for insurance operations. The first one is your infrastructure piece. So you have to be able to actually deploy an APP that you build and um, it has to coordinate, has to talk to itself. So in that sense, we have, um, five major products in there, there's bright off, which is our centralized authentication system. So I log in, I know I'm you, that she's a Jason Web token, the token that gets passed around all the various microservices to say, hey, you are you in, you're logged in. Um, there's the bright access product which controls permissions and access controls and there are various levels of access controls. You get route level access controls. Can I access this resource in the network? Yes or no? Can I access this record set, yes or no to record based permissions. You get field level permissions and access control. Should I see this field? Should I be able to edit this field? Um, and there's a few others as well. There's quite a few layers to access control. There's bright hub which is a centralized event manager and message bus that let's all those different services talk to each other. There's the bright cloud infrastructure, which is where we have a centralized service registry that turned onto deploys all the other pieces. And then we have bright vendors, which is an integrated framework for all of your backend services to talk to an external service. So say for example, like, um, lexis nexis has credit scoring. If you want to talk to credit scoring, you need to centralize brokerage that manages that communication in and out. So those five are infrastructure. Um, don't have. Sorry, I'm mute again. I, if I could interrupt you. Yeah, I'm in the infrastructure element and the ability and, and making sure that you're the person who's logged in, right? Um, are there external pressures on an insurance company or an Mga to really have that tight and controlled, but I'm saying I'm guessing regulators want to, but could you give just a little bit of a backstory of this isn't just the insurance company looking to, you know, put in a password or whatever. What are the, what are the external pressures on the insurance company to make sure that data is data is incredibly secure and security, uh, people that are coming in and out are that, is protected from that data. Yeah. So, um, there are a bunch of those things, um, in terms of regulatory pressure, um, you know, New York just passed a new requirement that you use just passed, um, a new data, data law and um, a lot of the new legislation coming down requires, for example, MFA. And so you have to have a well so mfas multifactor authentication. It's like when I log into the site, then I also have like a text message that validates my phone. Yes, sign me up. That's one strategy. There's multiple MFA strategies. Um, so if a law, if your authentication system doesn't support MFA right out of the box, she had a compliance in several states and in lots of nations in the world. Um, so that's like an example of external regulatory pressure. You also have obviously with the ongoing, you know, slew of security leaks to keep happening in log ins. There's a lot of pressure on companies to, to justify and validate how and why you're being secure. And if you're. So in our world we deal with carriers and Mgas. On the carrier side, they are really, I'm accountable to the regulators. The mgas are in many ways accountable more to the carriers, but the carriers don't want to. They are accepting the, um, whatever the security vulnerabilities of an Mga are. The MGA has direct login and they're binding business and so it ends up being a pass through problems. So that's an example. The other kind of pressure that you have is market pressure. And I'll give you an example of one of the things that right off does it, this point is relatively accepted, but if you have a modern login system, you're going to need to support federated user identities. And federated user identities means for anybody who's not an engineer on this, on this podcast, um, that's when you say, Hey, log in with my facebook account or log in with my google account or logging in on a sample, you know, something, some authentication service outside of your system. Um, and so it's a way of linking accounts together and saying, Oh, if I trust this other authority, I trust facebook. So if I logged into facebook, I trust that facebook has done their due diligence, they have MFA, and those things turned on. And you are actually you, so I go ahead and log you into my system now. So that's another major pressure on people. If you go to a site at this point, it doesn't have a log in with google or log in with facebook. You're kind of like this kind of junk, you know? And so, so the, the point of a system like bright coordinate visitors, just those infrastructure pieces, there's a bunch of other pieces, um, is, is that we are trying to say, hey, if you utilize our authorization service, you get all of that, right? All those things are automatically built in. It's all on my feed there. And so then it's a question of do you want to utilize our interfaces like our, our user interfaces. So we deploy all of our services with front end tools that you can just stand up and expose to your users. Or another major thing about the way that we feel that all modern services should be architect, and I think everyone agrees with this in computer science is your, your service should be a true web service exposed to an API. And then we deploy a standard interface that you can go use, you can also build your own user interface and you can just talk to our API. And so a lot of our users now we'll do things like they'll build their own mobile app or their own consumer website and then they'll hit bride off as the authentication mechanism. So it's doing all the heavy lifting. It's history, the tokens is doing the better it user identities that they control the screens. And so that's just, you know, a very specific example of utilizing a platform to power and functionality that you would want to want to create. And I can tell you because I actually just recently we just recently overhauled bright off to give you a sense of the engineering effort that goes into something like that. I had a team of seven people that spent 14 months rebuilding that one service. So you know, when you think about at the individual insuretech level or even an individual carrier level, because each insuretech wanting to devote seven people for 14 months to build out a robust authentication system. Or do you want to go plug into one that's already been built for you? That's targeting the insurance use case? Yeah. Yeah. So I'm going through this right now where we go and we talk to carriers and I was surprised at how much emphasis they put on policy management systems, what are you using it, you know, just a lot of buzzing and questioning and an auditing on that part of it. And I always stopped policy management system is it's a, you know, you can just have a database with a pdf file and there's your policy yet. No. So I would like to learn more because I actually don't know a lot about policy management systems and the intricacies, the things you have to worry about, which sounds like you need to be able to do endorsements and premium related stuff, connect two rating systems and give us a flavor of the tighter that your engineers and your product managers have to think about when a, not necessarily designing but you know, maintaining your policy management system. So it may go through all this stuff, the rest of those product offerings. So he chose products group in Microsoft is, I'll give you a sense of the workloads that that kind of bright court manages. Um, in addition to the infrastructure I just said, you know, bright off bright access, bright hub, right cloud vendors, those are the five infrastructure that there's a bunch of others. So then you have core processing and core processing. There's five products there. There's bright lines, which is the ability for a system to go in and define insurance products, underwriting rules, forms version those things, inheritance across geographic regions, managing user access and controls to the insurance definitions. And then that also includes in our universe a rating engine. So another really, really complicated part of insurance is rating your policies, especially if you do large scheduled commercial policies. That's just inefficient processing overhead. Sometimes we have policies right now that happened. We first build the dependency tree for rating. There's over three and a half million to forks in the dependency treat individual nodes in the tree that we have to operate in parallel. So here's an example of how big those can get. Then there's, then there's bright policies. Policy Admin is the component that issues, policies, cancels policies, renewed policies, processes, endorsements, notable and endorsements is, and this is something that insure techs are really sometimes struggle to to consider right up front is the tremendous complication down the road of out of sequence endorsements, especially out of sequence endorsements that are committed into a prior policy term. So when you're standing up a new insuretech new Mga, you're thinking about getting the system live right, but once you get alive then you have to actually invite the administrative, the policies, those policies are going to renew in a year or three months depending on what your policy terms look like and once those policies start renewing your in new legal agreements at each renewal and but you are still required legally to process endorsement changes back into prior terms and so you have to go in what makes insurance processing and policy admin so different for like a banking system. In banking, everything happens in real time is transactional time. You never go into your bank account and say, Oh, 90 days ago actually my account balance should have been this. Now rewind and replay all the transactions. It doesn't work that way. That's what blows your mind to think about an insurance. That's exactly what happens, and so you have to be able to process multiple overlapping out of sequence, transactional records and calculate the difference between them. Catch them all up and in those things synchronized over into another product, right? Billing and billing is where you then you say, okay, here's your coverage is your premium difference. Here's all the things that happened there. All that has to flow through into a billing system and the billing system and bright core is huge. It does an enormous amount of things. Examples of the kind of things that would do is let's say a process that out of sequence endorsement into a prior term. There are all kinds of settings in it for. Do you want me to bill right now for the difference in the prior term or do you want me to take that difference in aggregate it into a remaining installments? Do you want me to only do that if. If I can calculate the earned premium, the amount of earned premium I've collected in prior billings is positive, um, and if so aggregated into a future endorsement, if that amount is negative and I'm actually behind on my premium going ahead and build now a. So there's a million things like that that go into the billing system. You'd be able to support things that combined billing. What if a policy holder has seven different policies but they won't get one invoice. That's actually a really complicated problem because what if all of those policies have different due dates on the invoices, but I still don't get one piece of paper. Now I have to travel debit system that tracks multiple overlapping invoice due dates and cancellation dates. And there's regulations on a geography basis for when I can cancel the policy. What notices have to go out when I canceled the policy. One policy that's, you know, that's a let's have a policies in 11 different states and only get one invoice. There's different business roles on cancellation and finished one of those 11 policies, those 11 different states. Um, after you issued the policy, then eventually something's going to go wrong and have a loss and then you need a claims management system and claims management systems have to be able to track, um, you know, not, not just the basic, um, the claimant and the reserves. You have to be able to track things like, um, loss events that are macro events that then contain sub claims. For example, let's say you're insuring a school bus, school bus slips off the road, flies into a house and a bunch of little kids who are injured. Maybe there's some fatalities. You have a bunch of different types of claims being filed against possibly different policies with different coverages and the different adjusters get assigned to it and there's litigation that goes into some of those not into others. And so there's a ton of complexity of the claim system. And then finally in our core package there, we also have bright Ui, which is what I told you earlier. Just a user interface, right? There has to be a user interface that communicates with all of these services. And we stand up one that you get for free in our ecosystem, um, so that you don't have to go build all those screens. You get screens that you can use if you want to use them. So that's just the five and core and there's another 35 service at Paul products that we have that go way on out past core. So you probably required you like your salespeople probably required to do consultative selling because you have so many different products to plug in. Like who would have thought that just a policy management system would be that complicated? But that's, that's one of the things that I think a lot of insure techs that are coming into the space don't get. It's like it's even, you know, my cofounder, he laughs when we, um, we go give a pitch. He's like, I always thought of policy. It was just a piece of paper. Yeah, no it's not. I know. So actually I'm in an interesting position in the industry because I'm bright core is really popular right now and it's developed a reputation for being a really good system for mgas and insuretechs. In addition to that, a bunch of the carriers we work with and so I think I may be wrong about this, but I think I get just about every new startup Mga and the country calls me for a demo and so I have a chance to meet at least most of them don't know if I get 100 percent and I probably get 80 percent of them reached out to me and talk to me. Um, as a result of that, I have an opportunity to kind of understand who is coming online with their value prop is what they understand, what they don't. And one of the, uh, one of the things that I'm working on in my own company is at the moment we only work with eight to 12 customers a year. But I am taking right now, I'm in the last 12 months I've done in my crm system. I've taken 246 inbound sales lead calls. And so at a 246 I end up working with between eight and 12. And so I'm, I'm actually responsible for myself for a lot of filtering down our sales pipeline and who are the people who we really think do understand what's going on in. One of the major things that I do in the, in the process is I interviewed the founders of whatever the startup is and I say, hey, tell me what you know about statements, endorsements. Tell me what you know about when you're reinsurance layer is divided by apparel group and you trip over into a cat layer for one parallel group and not in the other parallel group. And Oh, by the way, one of your reinsurance treaties, um, is you, is a three state treaty and the other one is only a one state treaty. If you have this commercial policy that happens to exist in both states at the same time, how does that work for you? And what I'm really doing is I'm just listening to them talk to understand, do they understand the business that they're getting into? And so one of the big pieces of advice I give to a lot of Mgas when they call me is, look, if you don't have someone in your office that really, really understands insurance processing and the complexities, I would highly recommend finding someone like that and bring them into your founder group because that's a major. There's a lot hiding out in there, like a lot, a lot. My, my cofounder, Jim wanted me to ask you knowing that you were coming on a and that's going through this problem right now. He wanted to know about bpo and I was like, what the hell is bpo is like ask. He's like, he'll know. Ask core if they can, if they do bpo for policy management and in billing. So does bright cordwood bpl. Okay. Yeah. So bpo stands for business process outsourcing. And what it means is do we have people on our staff that are the operational processing staff for in place of view. So for example, you wouldn't have to staff claims adjusters, we offer you claims adjusters to do your claims adjusting. Um, we do, not directly, we're not directly BPO provider. Um, we, we decided that we toyed with the idea for awhile, but unfortunately a lot of the BPO providers in the industry, um, if you track them, I mean, I've been doing this now for 14 years, I guess I've been, been in the industry and I've watched a number of BPO providers come up, grow and then crash and burn and go bankrupt over and over again. And it's because that service work is a very tricky business to manage because the volume of it is so sporadic. And you can get, for example, a really big customer out there. One of the tier one customers can come through and you can triple your revenue overnight and services and all of a sudden they changed their mind and now you're, you're closing up shop. So we made the decision that we didn't want to get into the BPO industry. However, there are other partners we work with who are good at Bpo, who do that, who have training in bright core one that we, um, that we really liked working with. There's a company called Tech Mahindra that is actually really good at this. And they have a very sizable staff tech Mahindra. Um, we've been working with them recently among several projects and they do great. They have 18, 1900 people on staff, their insurance train, full insurance professionals and they do a lot of bpo outsourcing and I'm one of the things that we do to try to really help, um, the people who do the service outsourcing work with another, another partner that you work with if you're in my industry, um, is bpo is on the backside of the policies or if the systems are live in someone during the systems. But before that, another, another partnership that sometimes people will want to engage as it's called an partner. And that's the service implementation part of it. Be Somebody who can help offer you services to get you live in the first place. Now we utilize say partners quite a bit less than a lot of the other software vendors and industry. A lot of them rely heavily on sap partners. We use outside partners more where we still manage the project and we said Sy partners to augment our staff, not really to run the implementations. There's a lot of reasons for that, um, that's kind of our perspective on it, but I'm tech in, for example, one the things that makes them nice as they are both in a partner and a BPO provider. And so, um, the way that we were in another one that we work with a lot that's really great as a company called nest it, they're really good as well. I'm really liked them. Um, and the, uh, what we've done in our ecosystems, more about, you know, trying to build an ecosystem that actually captures the value of modern software practices. So one of the things that I think, I think also the, the computer science field has spoken on many years ago now is that closed source software is generally bad software in general, if no one can see the source code, but these 11 engineers, there's probably a million bugs and security vulnerabilities and all these other things that no one's dressing because it's all behind a closed box until something goes really wrong. And so we're big believers ourselves and open source software. And so one of the things that we do, this really, I think somewhat unique in the industry is that wild, bright core is sas, right? Essentially deployed, managed and aws, all those things. We allow all of our customers and our SSI and bpo partners, anyone who's a partner with us, um, to contribute directly to source code. And so we have partners, bpo partners and customers that are in there saying, hey, we'd like to see this new workflow exist. Oh, we found this know that isn't processing the way you want. Oh, there's a security vulnerability in your authentication mechanism right here in this one particular corner case. And we try to empower all the people in ecosystem to go in and do something about it themselves. Right? So they can ask us to do it. But if we're busy, if we're on something else and it's driving you nuts, or do you want to see a new value chain? Go do it because that's the way. That's the best way to do it. You know, it always scratched the itch that you have is kind of the philosophy. And that would be probably very beneficial or valuable to insure techs that are coming in either as a carrier or an mga where there's like there's tech blood in there, like they, they, they have some tech expertise and so anytime that they can contribute or write code or connect or cleaned things up, they usually eager to do that because they want it their way. Yeah. One of our, one of our customers is really, really good at this. I'm a customer called jetty. I'm j e t t y Dot Com. Familiar with Jedi David and Joe Kim. Never. They're all awesome. Um, they've been a customer for several years now and bright or powers the back into jetty and they're really great customer because they are, they're all about high transaction volume and zero downtime. A lot of our carriers, they have business hours at the end of business hours. There's nightly processing and everything goes offline for two hours while we run processing and fire back up. And we first start working at jetty though, I know we're 24 slash seven direct to consumer and we have know we're gonna be taking tens of thousands of rating requests, you know, an hour or something. And so we need, we need this always on a rolling upgrade, sort of like strategy and they were a really good customer came in and pushed our team in a really healthy way to, to work on our availability of the system. Um, and so, you know, one particular example where a customer comes to the door and because they have access to source code, because we really collaborate back and forth as our teams again because we're customer centric and in a very big way, um, um, it produced a lot of um, benefits enhancements to our Dev ops infrastructure and our deployment architecture, working with a customer who had that need. And then all of the customers have now benefited from that because again, it's a, it's a centrally managed SAS system that's, uh, it just so incredibly complex. I, I would like to ask you which administrative functions can get an Mga or a carrier. I don't know if there's a difference on this one. Get them into the most trouble if they screw up. Oh man, the. Okay. So the really big ones, endorsement processing I've already mentioned is huge. Another really, really big one is people do not take into account what their, with their billing regulations are from a cancellation procedure and from an increase in premium endorsement. And you can, you can get fined like, like several states full finally,$50,000 per infraction for any bad invoice you send. Um, and so it can get wildly expensive if you push out a bad, a bad software release on certain invoicing practices, that's a really big one. The one that actually see the most common one that people really don't think about until, until they're later in the chain is there data warehousing. Because once you are writing, you write your first policy, your very first policy, every single person up that value chain. So let's say you're an Mga, it's going to be your carrier. If you're a carrier is going to be your reinsurance, reinsurance, me, the reinsurer that's backing your reinsurance policies, right? Because that, that chain bubbles up until take, get to the exchange and they'll cross the reinsurer. Um, but the, as you go up that chain, any entity up the chain wants 4 million pieces of data from you because they're the ones ultimately backing your risk. So they want to understand what you're doing. And then addition to that, if you're in the carrier side, you have to produce statutory reports are produced statistical reports, there are all these reporting mechanisms. And here's the fundamental challenge. Insurance is a, is a heavily fragmented industry. So the reason that there are 300 new insuretechs a, your$500 ever many there are, um, and there's a zillion carriers out there is because each one of them is doing something unique. They're not doing it the exact same way, right? So in banking, when you go like, like the way that checking account balances work in banking is exactly the same, right? There is no variation in how I calculate your, your account balance is not the case. There are, there are 6,000 different ways you can process any particular transaction and insurance. And they're all doing it very differently. Here's where it gets to be. A major, major disaster for an insurance company is not thinking about this problem. You go through, you build a value prop, a workflow and use case, a product model or whatever it is that you're going to build it, your unique value chain, and it's all based on your unique little data points and your unique processes and you colleagues to come with these new words, awesome day to you have to report on all of that and guess what? Every single reporting agency in the world has a standard data file that you have to report it and if you don't, you get. You get to close up shop. The state comes in and shuts you down and so you have to come up with a way to get your nonstandard processes and data models and rating structures and all the things that you're doing mapped back to standardized reporting and output. And that is a tremendously complex problem to solve. We spent about two years here, I had dedicated team solving that one problem on how you, how you build data mappers for your data warehousing, and that one I've seen hose a lot of startups. They see something they think is really innovative, really great. And then then day two, they have no way to extract the data report anything and just get shut down. Can we can be like, nope, you can't do this. That's wild. Yeah, it's, it's not, it doesn't surprise me. It's wild in that I didn't know about that. It's wild and that I think most insurance professionals don't know about that. Right? And you know, just it, it's, it almost seems like all of that regulatory function is just like cloaked. And so, you know, there are a few few people that had been with the company for 20 years and they're over in that corner and nobody ever talks to them they're doing is saving the company. And uh, so it's really true. And you'd be shocked how many multibillion dollar cares you go in and they're only three people in a back office somewhere that have any idea how this works and if this goes offline, the whole house of cards burns down. It's just a dumpster fire after that. So it's that. That's where I think that's the compelling value proposition. So circling back around to where adopting when and where you can, adopting a standardized system, light, bright colors, bright quarter. It could be anything else that does this where we're a, someone like myself, we're supporting a broader set of use cases. We are required to think about these problems ahead of time. And so the thing you buy with a system like bright core is in some ways you get up running faster and other ways you encourage new debt because you add as a really lightweight startup, you still have to have to engage the complexity of a real system. Right? That did supporting really big. So we have a really big customers to, to do all kinds of complexity. Um, and so, so it's, it's a yin and a Yang, but the thing that you're mostly getting is you can be reasonably confident there's not some giant thing hiding out in a corner that's going to come up and bite you because if there were, we would have already thought about it, you know? Yeah. Legacy, it, uh, I, I worked at a carrier that had, uh, several different legacy it platforms, mainframes, uh, systems that didn't talk to one another. Um, how, when, when a carrier calls you and they have that issue, what do you do? But they all have it. Um, and it is, it's a byproduct of a thing that, uh, there was a trend, a buzzword started up an insurance, I don't know, maybe 25 years ago, even before my time, um, that was best of breed software and everybody went on counting best of breed software, which is not a bad thing, not a bad word, but what it means is I'm going to pick a different system for all of those little thing. And I, again, I've only given you 10 of our products. There's like 50 tons of fork load that I haven't even talked about. Um, and they go around, they pick individual systems for all those things and they think in the demo. They're getting all the best features for all those different things and they may get some killer feature in one of those little monitors that they want the part that no one calculates. I'm in the sales process and it's shocking when you're in my position is, oh, I have to make all these systems talk to each other. And that is wildly service intensive, resource intensive, incredibly prone to error. So the situation that most carriers are in is that they have anywhere from four to literally the worst I've seen was like 200 and was like 235 and 40 back in systems that are running, doing all these different workloads and they'll need to be communicated with. Um, and there are, the issue that happens is those teams that are responsible for implementing that, getting a hurry and when they get in a hurry, the very first thing they don't do, the first thing that drops off the radar is documentation. And testing, so then all of those Api integrations, all those service integrations, they only exist in to people's head in that back room. And then one of those guys, um, decide gets a better offer for another job. He quits and the other guy wants to retire and can't retire because it's old systems around. He wants to get out, but he doesn't know half the things the other guy knew that already left the company and then literally no one knows how it works. And so the companies get paralyzed and they won't change systems because they're like, Oh God, I don't know how this works and if I touch it all my documents quit printing or you know, whatever the case may be. And so, so that's the situation people find themselves. Yeah. I've seen situations where that happened and what they end up doing is they hire a consulting firm. Yeah. And I'm old and I've been in one situation where only the consulting firm knew how to, how the system operated and how to pull data out. Yet we'll leave that. There was no one in the company that literally new kind of anything about it. Yeah. And it was, it was a risk management issue in that, um, you know, at least by having the consulting firm do that part of it, there was a, you know, some confidence or some security in that like, okay, they can't screw up or else, you know, it'll, it'll kill, uh, our relationship with them, but that's like incredibly scary and things that I've heard it and thinks that we talk about things that we're nervous about when we're talking about this as well. You don't want to end up like that. So it's like, it's, it's such a critical decision and get all of the. Get your platform. Correct. Correct. But as, as my cofounder and I talk about all the time is we don't want to get stuck. Like we're very cognizant of making sure our platform allows us the flexibility to do certain things because we don't want to be one of those legacy companies. Yeah. So, so the advice I would give people on that front is that number one, best of breed, again, not a bad word, it's not a bad concept, it's that if you're going to adopt that concept, it is important that you follow through on it, which requires an enormous amount of budgeting for time and money on documenting all the interconnects, testing the interconnects, making sure you have regression test suite that backs at all, and then then you can actually migrate because you know what all your Api end points, you know, what they do, you have tests the backroom and then you can treat the service like a black box. But if you don't have that, you can't. So that's where I tell most companies who aren't, you know, liberty mutual or USA or some massive company that has a lot of resources. I tell most, most people, hey, it is probably in your interest if you're a little bit smaller than that. Um, to try to utilize unified platforms where you can. Because then it's on the vendor to make sure that their individual components talk to each other. It's not on you. Whereas if you go best of breed, it's now on you. It's on your internal team to determine that all the interconnects are working really well. So it's one piece of advice I would give people and make sure that you utilize platforms where you can, that are integrated. Number two, if you go best of breed or if you fragment your platforms, do so intentionally and test the interconnects and make sure that everything is api driven access and you know, exactly, it's all documented. Um, the third piece of advice I would give people is that when you are going with fragmented resources, so again, in bright core in my universe, I have all always individual products in each one of them is its own standalone microservice that talks to the others. So we actually have, you know, 50 ish products that are totally standalone. So it's like I'm talking to 50 different vendors, but I just ended the vendor and all those cases. So when and where you can, I always advise Dev ops teams look design everything in a true service oriented architecture and there's a bunch of rules and computer science. But what that means, a good example would be you don't have your policy system and your claims system talked to the same database once you're talking to the same database, there are undocumented interactions you don't know about, always make them talk via Api. So there's a list of things there that you, from a computer science perspective, you want to do to make sure that your individual product streams, your services are truly segment and, and separated. And then if you, if you do all those practices, then it's totally safe thing to do. You just, um, you cannot go fast and cheap. You can't always go faster, faster, faster, cheaper, cheaper, cheaper, and do any of those things well. And if you don't, you might get live quickly and then everything will explode on you a year from today. Yeah, we don't want that. Um, so I'm going to ask one more business related question then we're going to go get, we're going to transition over to the personal sure stuff. Um, next generation of policy administration systems. Uh, again, this is a question for my co founder, um, digital cloud based client server. All of the above. How do you think that brightcove is going to have to evolve to handle the future of business, the future of the future of insurance business? Sure. I mean, there's a lot of things that are going on and simultaneously in parallel, um, here are some of the big ones. The first one is I do really believe that every modern software vendor should be working as aggressively as possible toward a true microservice architecture. And by true microservice, I mean fully orchestrated, um, all of your individual business workloads, um, function as standalone blackbox services because that's how you keep from getting stranded with a legacy platform. You can upgrade individual black boxes one at a time and that way smaller, they're smaller domain expertise required to move forward. So I think that's huge. Microservice architecture I think is massive. I think clearly it's not, it's not new anymore. It used to be new five, 10 years ago. Um, everything should be cloud based at this point. Like there should, nobody should be maintaining server stacks in the basement or anything like that. Um, we also should be using floppy discs. Not that either. Um, and so, uh, so, you know, I think that that's a relatively self evident thing. I also think then the other big thing so that those are kind of infrastructure architecture is really, really high level product wise. I think one of the big challenges is that we are seeing a shift, a major shift in the industry toward more direct consumer interaction and that necessitates a lot of infrastructure shift and a lot of product level shift in terms of what capabilities are exposing to what user and then how do you expose it. Um, and, and that, that the trickle down from that is a lot of security procedures, a lot of marketing and branding, a lot of sort of, sort of, sort of controlled user experience that provides a delightful user experience for a consumer. Whereas an agent maybe who's you know, who's receiving a commission is willing to put up with some irritating things in your system. It consumer is not going to do it for two seconds. They don't care. They'll click onto the next site. Um, so I, I think there's a lot that has to happen in terms of, of making sure that you're enabling delightful user experiences. Um, and then, and then kind of probably the last thing I'd point out there is that, um, as we, as we move forward and as things get more and more, the nature of the products that we're writing is shifting. There's some fundamental assumptions about insurance and the data model behind it. And then it turns how you report on it. Um, all of those things that are, um, that are necessary. I get a really good example. Most if not all of the policy management systems I'm aware of including bright core. Um, our fundamental assumption about how premium is earned. His premiums earned on a daily basis. Everyday. You know, you write$365 in premium on a policy and each calendar day that goes by, you earned a dollar and then another dollar is unearned, right? And so, so you start fearing she's$5 on her and on day two,$1 and$3,600 is on her next$82 and$63 center. And um, and, and that, that that's sort of your fundamental assumptions. That's the way insurance has worked for a long time. But now we have a lot of companies trying to push a usage based insurance value props, which is great. Awesome. I think everyone can see the benefit and usage based insurance. The trick is how do you report on it? How do you say, how much premium you wrote when you don't know how much premium wrote until they hit the starter on the timer, on this mobile app, somebody is walking around with in their pocket and written premium reports are a standard thing you have to produce for every single state department in the country. So there are a lot of very significant back end processes that I think all of us at the forefront of the people thinking about this problem are how do you bridge some of the obvious value change that could be there? And you connect those two, what is essentially a legacy reporting environment, a legacy sort of sort of data model and bridging those. I think that's one of the huge challenges that needs to be solved for modern insurance right now. So I lied. I'm going to bring up one more business. I'm kind of the topic. Does your, is blockchain? Uh, I have, I have a, I might be a contrarion on blockchain. Unfortunately. I said understand block chain very well. And you know, the value of blockchain is when you do not trust an authority. Okay? So they're the only reason to ever use because block chains have vastly more expensive data store. Then the standard transactional database. The only reason you would ever store something in a blockchain is because you do not trust a centralized database because there's no reason to pay 10 to 20 fold for the same transaction to put it into blockchain and less, um, there's a reason you don't trust any single database, at which point the consensus voting mechanism in blockchain now as a value chain. Okay? So in the majority of insurance use cases, you do trust the back end, right? I mean it's not like you have an insurance policy with a big carrier and then you're like, well I don't know that that carrier generated the right invoice for me. I need to put that in the blockchain so I can validate that the invoice you sent me is really the true invoice that's not a real business need out there right now. And I have a lot of people that call me and say, well tell me what you do at blockchain. And I'm like, I mean, you know, there I can articulate really cool value props for blockchain, but none of them are the things that most people call me and asked me about because, you know, I just asked them over and over again, why don't you trust the backend system there? I like, what is the thing you don't trust? Now having said that, I'll give you a couple of examples where blockchain does make a lot of sense and where, where I can see big potential for it. Because again, you don't necessarily want to rely on a centralized service. Um, one example would be if you're doing cargo insurance, alright, and you do not as the insurer have control or access to whatever the inventory tracking system is for the shipping company that's putting cargo into those cargo containers. If they file a claim and say, hey, 30 cargo containers were lost at sea, it's a$52, million dollar claims were full of diamond rings. You want some way of knowing did they in fact put diamond rings in there? Now, if you could get the shipping company to write a data source directly to your database, in that case, the centralized data storage would be a perfectly acceptable solution. But if you can't and you want to only validate that information at the point in time that there's a loss, then running those things into a blockchain is a perfect way to say, no. You told me it was in these container. This is what was in the container. You can't go back and change your mind now. So that would be a really good example of where blockchain would be valuable. Another one that I'm shocked, no one is, no one is tackling right now, but it seems like an incredibly obvious one to me is that I can't fathom why the insurance industry has not yet adopted that we would all be doing statistical reports into a blockchain. Right. But why, why do we all rely on a couple of centralized authorities to gather and collect these statistical reports? It would make a lot more sense if we were all just running that data integrated into a global blockchain. Everyone subscribed to the blockchain and then you can do what you want with the data. I think that would be a really awesome use for blockchain. Um, but outside of just a couple of uses now, I can't think of a reason you'd want like your invoicing system to go into a blockchain or your premium system to go into blockchain or anything like that. I have a hard time articulating where the value proposition is there. Good. I liked the answer. Thank you. Uh, this is the part of the podcast that we transitioned. Learn a little bit more about you and not just your brilliance and what you do on a day to day far from brilliant who you are and I already know that you used to write children's song, which is awesome. Uh, I put my kid to sleep last night doing itsy bitsy spider. That's awesome. Um, so I love, love kids songs. Um, when, when you aren't working, what do you enjoy doing? Yeah. Um, so obviously I have the music thing, um, that I still really enjoy. I, my, my wife recently, um, about a year ago, uh, picked up mandolin lessons for myself and my son, my son's 11 and uh, we started taking them together and so I've really enjoyed doing that. And a big Christy Lee Phan from Nickel Creek. Now he's in punch brothers and he's a Virtuoso Mandolin player and I've been learning to play some of his stuff, so I have that. Enjoy that. A lot of love, a love exercise, like to lift weights, have a whole, a kind of a crossfit style gender in my basement and like to go run in and do things like that. Um, and then I like to scuba dive a lot. My, my, uh, my wife and my son, we were on vacation. We love travel. We travel frequently. Um, we went to Iceland not very long ago. We went to Kosovo pretty recently. We're heading to Alaska and a couple of weeks I'm just spend like a week or two hike and just out and out in Denali. And so yeah, just anything that gets me out and, and doing something because as a career I spend most of my time sitting behind a computer, talk to people about insurance and so kind of when I get some downtime I mostly want to do just something to just get out and be active and, you know, and, and just stretch my legs, look at the mountains and I love that. That's great. Uh, what tools or techniques do you use to stay productive and slash or organized? Yeah, so I'm there a lot. So we're heavily remote team. Um, our staff is 170 at bright core today. Um, and we have the biggest central office we have is where I'm located in southwest Missouri and there are only 32 people that live in southwest Missouri and we have an office here that I go into once every three months. I pop my head in for an hour and I say, hey, you guys still hear his office burned down? No, it hasn't. Okay, good. Awesome. I'm out. Um, so we're, we're really remote and as a really remote team, productivity tools are really important for us and I'm one of the ones are really obvious. Everyone's picked it up at this point. I think slack is hugely valuable because it lets me keep track of all the various conversations going on in my company. I was like, can I ask it to be chaos? I, I, our company has 7,400 slack channels active at any one point in time. Yeah. So, uh, yeah, there's a lot going on. And so, uh, so, you know, I obviously going track all of those attract like 200 of them myself, but even$200 a lot to keep track of. Um, so that's really helpful. Um, we utilize, um, a couple of other things. I really liked to use clubhouse right now that my project management suite of choice, um, is lightweight. It's really nice and it lets me sort of sequenced organized works really quick to set up projects. And so I utilize project management suites, um, even for things that are not software project so I know what's going on. So ticketing's really valuable for me and so I can go out and look and see what all is out there, what should I be doing? Um, another thing that I find incredibly valuable is, um, in our company we standard issue, um, Mac book pros to everyone in the company and we do that just so, not because Max, you know, it better than pc or anything. Like, I don't care about that actually a lot of engineers, it's just run Linux. Virtual boxes were in a bit to virtual boxes on their Mac and all they do. But the, uh, the, the advantage of having the Mac is by having the same operating system, we can adopt the same tooling. And so we have standard tools that we utilize across the company. One of those is in slack. You have video conference, but also we utilize ring central, which is actually the corporate version of zoom, which I think we're using right now. And um, and what it does is it enables everyone has it. It's an all of our toolbars right up top. And so I know it's on everyone's computer. And so at any point in time when I'm like, Hey, I'm going to talk to them and talking to slack it, this would be easier to say I just click and Bam, I'm looking at it and I'm talking to him regardless of what country they're in and time zone they're in, it doesn't matter. And so I find that to be a really valuable tool as well. We also made the shift several years ago, um, I actually sent out an email is, it's a famous email in our company where I said, if you send me one more Microsoft document for any reasons that doc x and it's an excel file, I will fire you. But that is a, you are fired for that. Do not ever send me that. I'm not even. No, none, absolutely not under no circumstances because google sheets so far, no one has ever shown me something that I would need excel or google sheets doesn't do it if you'll just take five minutes to learn how it works. Um, and the reason that there'll be some of them say this podcast is like, no, excel does this one function is the killer feature. So, which is fine. I'm sure you have your feature. That's awesome. And please keep using excel if you want my company. I said no, and there's a reason for it. Um, if you were going to be a remote distributed team, collaboration is absolutely critical. And the problem with Microsoft files around it's an excel files around is every single time you send that file and you have another version that file sitting on another laptop. And who knows what the most recent copy is, he knows that there's an edit stranded in someone's local laptop copy. So by forcing everyone to go to google docs, maybe lose some formatting, maybe you lose a function or to hear that you wanted. You have all the documents are just only one version. There's one centralized copy. We can all go, we can comment, we can edit, we can see the history of revisions and edits and so that is tremendously powerful for us. And then we have a whole suite of software tools we use surrounding all of those things that are really envision. Um, he's all sorts of things to like help. The main thing is we focus on collaborative web based tooling internally so that, that there's no penalty for being at any particular location on any particular time zone. Everyone is able to be productive in, there's no reason to go into a physical office for any reason. Yep. Oh, that's cool. Uh, we're, we're struggling with that now. Google, I had dumped into a google sheet and I was like, ah, can you download that to excel because I don't think I'm going to be able to use it. So it was a. anyways, that, that is a collaborative effort. We are very remote as well. I'm in a Home Office. So, um, absolutely. Um, we chatted about this before we started. So let's finish off with books and what books you have found influential. First of all, are there any marketing materials, books, whatever, that can help a listener with insurance back office related stuff? Oh Man. Insurance back office is really tough. The best thing you can do there, and it's a painful thing for me to say is the institute's The ins courses or if you really want to go deep, which I've done the CPCU courses, which are a quickly getting a CPA. I'm an insurance. I've done all the CPCU courses myself, so I really understand insurance well. Um, but they have another, another series called the ins series that is like 100 hours instead of 3000 hours. Um, but here's all your insurance basics towards that backup. It is specific towards back office related function and it's an interactive tutorial based online. So, so that is the best thing you can do if you want to learn about insurance. Go do that. Um, so, so, but besides that books that you found influential and business and slash or personal. Yeah. So, so the books that are really foundational for me in the way I think about the world. So these are not insurance books, these are, these are thinking about it in the organization. I have a laundry list of a lot of them, but the four that I normally will tell people if you're like, hey, give me a few books I should really read. And I say, okay, if I were you, it for me, these are the four most influential books for me. The first one is fast and slow by Daniel Kahneman, which I know is a very popular book. It was like, you know, New York Times bestseller sort of thing. So it's well known that's a book where he basically explores all the logical fallacies and, and, and where, where we are not rational consumers all the time. And I think it's important because I'm a programmer, I'm an engineer by background and so I have a tendency to want to build systems or organizations that make logical sense on paper. I draw the flow chart. This is the way things are gonna happen and then when things don't happen that way, but I can, I can explain why logically they should. My, my brain wants to explode. I'm like, why is it, why isn't everyone doing what I want them to do? And so I have found that book to be wildly helpful, um, because, because it helps you understand why people sometimes do irrational things and then you can understand why they're doing it, which then helps you sort of sort of tried to design systems that encourage them to do the rational thing, to be empathetic towards them. Um, so, so that you can really get everyone moving in the same direction. So that, that was huge. If I only had one book recommended me, that one. Um, the next one that I really enjoy, um, it's a book called tribal leadership. Tribal leadership is written by a range of authors, but the three that are listening, the front is Dave Logan. I'm John King Holly. And because you're right, and that book is all about how I'm migrating yourself and your team from a, from a middling performer, a high performer, to then somebody who actually quits caring about whether or not I'm a high performer and everyone says, look at me and look at my accomplishments to making yourself good at caring about making your team a high performer. And then finally that had taken your whole organization and saying how to make the world a better place. Um, so it's all these stages of trying to lead people through, through what you could sort of call like an end, the actual eyes, career. What are we trying to accomplish? It all like what's the point in doing any of these things, right? Why do we, any of us go out and start a company in the first place? Why do we, why is insurance exists? Why do we wake up to do our jobs every day? And it does a lot of, of helping shape how you think about helping people channeled towards it. For me matters very much, which is I want us to be a force for good in the world, in the insurance industry, but in the world in general. And so I care about that a lot. Um, another one that I really, really value a lot is the fifth discipline by Peter Sankey. Um, I've done a bunch of the mit exec ed stuff, which for anyone listening to the podcast, if you haven't done the mit exec ed stuff, it's readily available when you can go do just like I'm a week on site there and get several credits that you pick up just by going there for their executive program. It's awesome. A Peterson, he's one of the professors there at Sloan and he wrote an entire book on being a learning organization, um, and about how to, how to make sure that you are the sort of company that's constantly asking the why and challenging your norms. And then even a framework and a process for doing that and enforcing that and making that be institutional memory and habit. So there's that. I love that book. And then the final one that I has been really foundational for me is the power of habit by Charles Duhigg, which was also a best seller not too long ago. Um, the power of habit is great because it really focuses on how people will do whatever their habits are. Like. It's nice to think that you're going to tell people to like, think above the moment and rise to this idealized version of how we should all react to respond. It's not true. People will, people will do their habits. They are 98 percent of what we do is just habitual. And um, and so that book is all about how you, how you identify and shape habits and how you change habits so that people will begin behaving and doing the things you want them to do because that's their habit to do it. Not because they have to stop and think about it and you know, utilize the emotional energy to try to have the right response. And so for me, those four books are foundational in my thinking about how you build and running a company and across. And they represent a pretty good spread of the, sort of, some of the concerns you think about. Um, there's a fifth one that is that it is not, uh, I'll, I'll throw out, I'll half indoors. It's called nonviolent communication and it's a little touchy feely. I'm so I fully endorse it because of the scientist in me is like, that's a little touchy feely, but it is an excellent book. A nonviolent communication is all about how you handle people who are mad and hot and are angry about anything and how you redirect the conversation in a way that deescalates and builds consensus instead of elevating. And I find that to be useful in a daily basis for me. So that's incredibly valuable. I love the list. The power of habits been recommended before. I haven't picked up and read it, but as you were talking, I couldn't help but think of a sports analogy and you know, I, I play a lot of basketball and I would, whenever in crunch time or in a situation where there was, you know, a competitive element to it, I would always float to my habit, which was always, I would always get me into trouble. Uh, I remember I spent an entire summer just working on my left hand. I got so good at working on my left hand that I would always use my left hand when I got stuck, that I couldn't break myself out of it and go back to my right hand in certain situations. So interesting. Yeah. You build that habit and it's just, it's just what you know, your brain maps it. And we do that same thing with the way that we talk about customers, the way we talk about our own product, the way we think about our own success. Those things are all patterns in our brain to get burned in there. And every time you reinforced the bad habit, you know, you're, you're, you're making it that much harder to do the right thing. So leaders have to really care a lot about. It's just like being a coach does the same thing. You're right. It's exactly like basketball. Awesome. Awesome. I'm Phil. This has been fantastic. Our. Thank you so much. I learned a lot. Uh, we will be in touch. Uh, so, uh, thanks for coming on and, and, uh, with your awesome, completely embarrassed me with your. Awesome. Now I'm going to have to get the dangling A. I appreciate you coming on and us.

Speaker 3: 1:02:20

Nick, thank you very much for having me on. I really enjoyed the conversation. Okay. My guest this week has been Phil Reynolds of right core. Take care everyone.