Joe Emison - Co-Founder and CTO of Branch Insurance: Maintaining Culture, Recruit Bootcamps, and Maximizing Junior Employees

Joe Emison  00:00

Every eighteen months, there is a really important innovation that would make a software development go cheaper, faster, better. And unless you found someone who is regularly adding or changing how they're doing software development every eighteen months, you very likely don't have someone who is giving you the absolute best information.

Callan Harrington  00:26

You're listening to That Worked, a show that breaks down the careers of top founders and executives and pulls out those key items that led to their success. I'm your host, Callan Harrington, founder of Flashgrowth, and I couldn't be more excited that you're here. Welcome back, everyone to a another episode of That Worked. This week I'm joined by Joe Emison. Joe is the co founder and CTO of Branch Insurance. Branch is an insurance carrier at that makes it simple to bundle home and auto insurance. Branch was listed on Glassdoor's Best Places to Work in 2022 and 2023. Before Branch, Joe had founded BuildFax, which was acquired by Verisk; SpaceFill, which was acquired by DMGT; and Blueprint, which was acquired by Harris Computer. Joe is also an author and released his new book Serverless As a Game Changer: How to Get the Most Out of the Cloud. Having grown up on the sales side of the house, I love when I get the chance to talk with founding CTOs, because it gives me a totally different viewpoint. And this conversation was no exception. I learned an absolute ton. One of Joe's superpowers is creating a team that moves faster and outperforms much larger teams. He walked us through specifically how he's able to do this. Now you think the answer to that would be simple, just go out and hire the most experienced people possible. What's interesting is he's been able to do this with teams that are primarily filled with junior people, which has turned into a huge competitive advantage from a recruiting perspective. I thought all of it was super interesting. And he really got into the details and walked us through all of it. So with that, let's just go ahead and jump right into it. Joe, excited to have you here, man. Welcome to the show.

Joe Emison  02:32

Thanks. Thanks for having me.

Callan Harrington  02:33

All right. So where I want to start, you've done a ton of software startups, founded six different companies. Have you ever thought about hardware?

Joe Emison  02:43

Yes, I think every software person wants to do hardware, because software is really easy, and you can do it on your computer anywhere, and there's something visceral about doing hardware. And so one of my first companies was, I made the first software to work- that made the iPod work with Windows, and this got me a lot of inbound from various people. And this was before I had gained a level of, let's say, critical thinking about who I should be partnering with. I was just appreciative that people wanted to work with me and were interested in doing things. And so this person reached out to me and said, "I want to build this device. I want to allow people to load CDs onto their iPod directly, and I want to make a device that does that." And so I got to build this device. It was sold, if you remember SkyMall magazine? On airplanes? It was sold through Hammacher Schlemmer. And I named it. It was called iLoad. And there are reviews of it out there. But the guy who I had partnered with was a sadist, who thought he was Steve Jobs. And the way he would do everything, every day, there would be a stand up. And he would go around the table, and a typical thing that would happen is he would say, "Joe, you said that you would get the low level driver for the CD ROM drive done by the end of the day yesterday. Did you get it done?" And I would say "no, no, Sandy, I didn't finish it." And he's like, "well, that's really disappointing. I think, you know, what do you think is a good estimate for when you could get it done?" And I would say, "well, Sandy, I don't know. It's hard. I'm reading documentation. This is like low level Linux drivers. It's a difficult thing to do. I would say I just I can't give you an estimate." He'd say, "Joe, I really believe in you, and that's not an acceptable answer for someone that I believe in. I need an estimate." I'd say "okay, Sandy, two weeks, two weeks. I don't know. I mean, this is difficult." He would say, "Joe, you're a brilliant guy. Two weeks is the timeline that some average guy I would pick off the street would give for this project. Why don't we say tomorrow?" And I would say, "Sandy, I don't know if I'm gonna get it done tomorrow." He's like, "is it possible that you get could it- could someone who's really great at this get it done tomorrow?" So, "find Sandy! Yeah, so maybe it's doable tomorrow." And he's like, "great, we'll talk about it tomorrow." And that would be every day. (laughs)

Callan Harrington  03:44

For sure, I do.  (laughs)

Joe Emison  04:48

He thought that this was a great management technique. It's not. If any of you are doing that, stop.

Callan Harrington  05:20

Was it like Groundhog's Day? Like that was the exact conversation that would- because it's reality distortion theory, essentially.

Joe Emison  05:26

Basically, yes. I mean, we had moments where I would say, "well, do we want it to work with the first generation iPod? Because that has a FireWire port, and FireWire ports cost eighteen dollars. And if you look at our bill of goods, at the volumes, we're going to buy it, it's going to push us over the material limit, if we buy that, because everything else is too expensive." And he would say, "Joe, I just don't think that that's what someone who has your intelligence would be able to do with this. I think somebody who has your intelligence, you would solve this problem."

Callan Harrington  05:54

Well, so here's a question. Was this motivational at first?

Joe Emison  05:59

No, it was never motivational. It was always terrible.

Callan Harrington  06:03

How long did this last? Like? What was the end result?

Joe Emison  06:05

Until I quit.

Callan Harrington  06:06

Gotcha.

Joe Emison  06:07

Yeah, I assume it kept going. And I had brought other people into the project. I felt terrible about it, but I just couldn't keep doing it.

Callan Harrington  06:13

I love that. I love that. So you've done a good amount of startups? Where did this all start? I know, you went to Yale Law School and then quickly started founding companies.

Joe Emison  06:23

Actually started founding companies before I went to law school. I thought I always wanted to be a lawyer from the age of about six. I actually wanted to be a judge, but you can't be a judge without being a lawyer. And so I got very interested in that. And it's the thing you tell yourself. You know, you get asked as a kid, what do you want to be when you grow up? So you start writing this narrative that is your narrative, you don't actually know what it would be like. You have a sense, right? And I really wanted to get involved in the law. But when I was twelve and thirteen years old, I asked- You know, my father was a doctor, so I would ask if he knew lawyers, or judges, and I would get to spend a day in a courtroom and watch a judge work. I loved that. I would watch Court TV all the time. And I would go to other lawyers and ask if I could volunteer and work with them. And they just, they won't let you. And this is partly because of the bar, a very restrictive organization, and the way that it's the profession is set up, but it's a very exclusionary profession. And so I liked computers. And so I asked, I think, for my fourteenth birthday to get some a programming language at the time, and I was able to start doing software development. And I reached out similarly in the software development world, and I would say, hey, can I help you build a, you know, a game? Can I go do this development? And I found people were open arms; oh, you can do software development? Please come help me. I don't care if you're a dog, you know, you can go do it. And so I started writing software for money at fourteen. And I did all sorts of different projects and worked with all sorts of different people. And that was I wrote my college application essays about it. I wrote some law school application essays about it and just generally have been consistently developing software since I was fourteen.

Callan Harrington  08:05

What was the reason for still going to law school?

Joe Emison  08:07

I still thought- I'd written this story, right, that I still really wanted to be a lawyer. And I went, and I loved law school. I mean, law school was one of the greatest, the educational experience, especially being at Yale Law School was just phenomenal. What I wasn't ready for was how lonely the work was, which became apparent as I was getting closer to graduation. You do internships, and I also, I had these moments in college and law school in which I realized, oh, I'm not the best at that. And so I remember, I did lots of advanced math in high school. And when I got to college, I was at the junior level of math. And I started in number theory, I did great in that class. And then I took a couple other math classes, not theory was one that I took. And there was a someone who's just amazing at math there. He's a professor at Stanford now. And I just realized I'm not- I'm fine at this, like I'm good enough to major in this. I'm good enough to do some things. But I'm not actually excellent at this at the highest level. And the same thing happened in law school, I was on the Yale Law Journal, and I was on a committee that was reading submissions, to where we would decide what would get published. And I remember reading all of them, and making comments, and having thoughts. And then the editor in chief, who's an amazing woman, a law professor at Columbia now. I remember her talking through the comments. And I was like, just throw mine away, I'm not even on the same page as your ability to analyze and think about this stuff. And I kept coming back to, you know, I loved making companies. I loved building out the technology side of companies. I love this consistent optimization that's social and analytical, and I think I'm really good. And so it became clear to me that's what I should be doing.

Callan Harrington  09:57

Yeah, it's almost that the Seth Godin, what can you be the absolute best in the world at? And I think about that all the time, I really do. Because there is there is a huge advantage of being number one. It doesn't mean you have to be, you know, the best at sales, right? That's such a broad category. You can own individual categories within that. But I think that there is such an advantage of that. So that makes complete sense to me. What was kind of that first startup that really had really good traction that you had started?

Joe Emison  10:29

Oh, well, as an independent software developer, I wrote a game a short game called the Mutant Chicken Races. And I wrote this software was the was the first software to make the iPod work with Windows. So I wrote the Mutant Chicken Races when I was, I think, a sophomore in high school. And I wrote EphPod when I was a junior in college, or no, maybe a sophomore in college. And both of those have had millions of downloads, probably over 100 million downloads for both of them at, this point in time, at least. You can like, look on YouTube for Mutant Chicken Races, Let's Play, and people making videos of it even five, ten years ago, even though it was written in 1996.

Callan Harrington  11:11

Is that what kind of gave you a lot of- Did that, was that a big driver in okay, I've got this, right, like, this is something I'm getting instant validation that I could be the best at what I'm doing; I should start going after this?

Joe Emison  11:27

No. Well, from my perspective, today, I think the thing that I'm extremely good at doing is, with a small amount of money, and no team, just me, or a small team, especially a team of more novice developers, or like mid year developers instead of absolute expert in their field developers, I can build things very fast that scale well, and that delight users. So that ability to build, fit for purpose, iterate quickly, build software to solve a problem. And I realized I could develop software when I built this. So I wrote games. And then I wrote other software, I wrote the voting system that my college used, I just wrote all sorts of things in different fields. I've been, you know, written things for governments, I've written things for oil pipelines, I've written things for commercial real estate agents, for consumers. And so I know I can build things. But I didn't know whether I was any better than anybody else at that for quite some time. And so when I decided, I'm not going to be a lawyer, I'm not going to be a judge, I'm going to build software, I'm going to be a technical co founder for a career or a CTO CIO as a career. What I knew was, I could do it, but not necessarily how I would do it differently from others. I just knew I was capable of it and there was demand for it.

Callan Harrington  12:50

What was that moment?

Joe Emison  12:52

Slowly, over many years watching how other companies and organizations do software development, I began to get a lot more confidence that what I was doing was better. I knew that what I was doing was different. And my approach was different.

Callan Harrington  13:11

How was that? Can you dive into that? A little bit?

Joe Emison  13:13

Yeah, I mean, I have generally had teams that are orders of magnitude smaller than other companies doing the same thing. We generally buy way more things than a typical company does. And so we build a small amount of things. And typically, we don't have very firm processes. I mean, this is agile, and the definition of agile, which a lot of people say they're agile, and I don't think they actually are. But what it feels like the software organizations I have built feel small, fast, and kind of loose and relaxed, and with constant delivery. And most other organizations that I'm used to working with at any kind of scale, right. And so startups often feel this way. But I've built companies up to, you know, fifteen years in that still are small and agile and loose and delivering constantly. And most organizations, after they get to a certain size or certain age, their rate of delivery becomes much more hardened, right, and mechanized. And so there's, you know, every two weeks, we do a release, and it has this cadence of every day. And there's lots of dependency chains. And so if somebody says, I need this thing done immediately, well, you can't actually get anything out for a minimum of five days. Because we have all these processes, and we put them in place because these bad things happened when we were more loose.

Callan Harrington  14:38

Somebody's doing this today, how would you coach them on how to build that? I should say somebody that wants to do that today? How would you coach them on how to do that? I

Joe Emison  14:46

I would buy my book. I have a book called Serverless as a Game Changer, which describes the theory behind a lot of this. But I think the book I'd read first before my book is called Accelerate by, the principle author is woman named Nicole Forsgren. And it talks about the fact that the thing you need to optimize for in software development is releases. Release regularly. The problem with releasing all the time, is that if you have bugs, and you don't have a good way of identifying and stopping them, those bugs will get released out into the world. And so the reason why most organizations don't release all the time, or there are there organizations that say, well, we don't release on Fridays, for example. Those organizations that are afraid to do that don't have good ways of automating their quality assurance. But if you start with this idea of let's release all the time, you will then quickly learn, I have to have automated quality assurance, or at least some automation there. That's critical, and it will make you answer all of the most important questions. So that's a great place to start. I'll give you one other piece of advice that I would give to anyone starting out, is to understand that the senior people in technology don't have any continuing education. And so if you meet someone who is senior, who has done lots of things, built lots of things, and you have a lot of admiration for them and what they've done, just know that it's very likely that they have no idea the best way to do it today. And so whatever their recommendation in the way they think about building today, is probably very suboptimal for what's possible today. And in fact, you'll often, if you bring to them, hey, what about this new technology, they will often very much underestimate potential of new technology. Now, not every new technology is great, you shouldn't just run around embracing things because they're new. There's a lot of new technology that's bad and doesn't make any sense. But we live in a world in which our, unlike in like medicine or law, our esteemed senior emeritus people, CTOs, senior architects, actually are not good people to consult, generally speaking, about how you should build things today, in terms of what technology you should use, or even what philosophy you should have on it, because the innovations happen so rapidly.

Callan Harrington  17:16

So if I'm playing that back, it's, everyone's learning this at the same time. So it's not like all these years that they put in, I mean, that can help from a business perspective, just in general, like basic business principles. But as far as actually building this thing, it's all happening real time, everybody has access to all this information. So what they know versus what somebody else that's in the weeds every day knows, is not going to be that much different.

Joe Emison  17:38

And people can be in the weeds with old technology. I would say it's that- think that every eighteen months there is a really important innovation that would make a software development go cheaper, faster, better. And unless you found someone who is regularly adding or changing how they're doing software development every eighteen months, you very likely don't have someone who is giving you the absolute best information.

Callan Harrington  18:07

So this is really interesting. And I'd love to dive in further on something else that I've heard you talk about before in that, is this a big reason why, or is this, I should say, is this a reason why you also go after what I've heard you describe as undervalued employees and engineers, in particular, in building that bench strength of junior developers to become senior developers? Is that a reason, A? And B, can you kind of walk us through that a little bit?

Joe Emison  18:35

Absolutely. So it is. This is why I don't love the super senior developers out there to bring on to a team. Because a lot of times if you're using newer, better technology, in my opinion, newer, better technology, they'll want to change it to what they know, as opposed to evaluating it for what it is. And so at Branch, we generally hire front end developers. So front end developers are worried about building interfaces. And that's where a lot of your value is, right, your user experience, your member experience, your customer experience. Those are your front ends. And, in addition, the front end developer is, in many organizations, looked down upon by the back end developers, which is viewed oftentimes, as a more, "this is harder and this is where the real engineers are." It's a very gendered, kind of obnoxious thing at a lot of organizations. You can see in social media, back end developers very much looking down upon front end developers. And so our favorite thing to do is to hire front end developers. And then we've largely because we use serverless technologies, we don't really need, and we don't have any separate back end developers. In fact, that Branch, we hire developers, mostly front end, and then we teach them how to be full stack, how to do the back end parts of our code, because it's quite simple. As we're out outsourcing so much to Amazon Web Services, in terms of them running it now.

Callan Harrington  20:04

Now, and so I gotta assume a couple advantages. One, just from looking at the book and things like that, one obvious advantage is cost savings. Another advantage, I'm assuming, is going to be speed. But, correct me if I'm wrong, but I have to assume, this is a guess, I have no idea, but your ability to recruit and develop talent has to be a gigantic competitive advantage with this. Am I right? Am I wrong in anything that I just said? I guess, first, correct me if I'm wrong in anything I just said.

Joe Emison  20:32

You're right in all of those. I think the biggest cost savings is needing fewer developers, with the strategies we use. The biggest business benefit is being able to go fast and really having, and this is highlighted in that book Accelerate, but really having it once a developer gets a piece of work, they can work on it, finish it, and it can go live very quickly. That is enormously beneficial versus an organization that a developer works on something and then there are another, you know, two to eight people who have to be involved before that thing can go live. That's a huge business disadvantage. And so if you can do it correctly, so you get the developer, and that with minimal other humans, it's going live quickly when it's done, and it's correct, and it's not going to cause things to break, you have solved a huge business problem.

Callan Harrington  21:21

Well, I would argue that that that applies to any department. I mean, I could tell you personally, we had a situation, we were a bootstrap company, didn't take on any investment, we had a good solid team. But we were based in Columbus. I couldn't recruit people away from New York, Chicago, or LA. This was when everything was in-office, we didn't have very much of a remote culture at this point, it's probably seven, eight years ago. And I just couldn't get, I couldn't pull the top a players away from these different companies. So it's like, okay, we've got to have the absolute best training and development programs, so we can hire for character that fits our culture. They can come in here, and we're going to develop in them, and it worked to the tee. And it's interesting, because it seems like there's a lot of parallels in that.

Joe Emison  22:06

Yeah, there are. Certainly when we're hiring people who we don't expect to have significant or meaningful experience in developing in a company, right. So we've hired a lot of people, most of the people Branch has hired are people who have really never worked in software development, but have done a boot camp, and we've run our own boot camp in the past, and understand some of the skills but don't actually understand what it's like to work at a company doing software development in a team. And so as as long as they know that, which they do, at least everyone we've hired, but that's part of hiring for culture and character, I'm sure you could hire someone out of a boot camp who thinks they know it all. And so our focus in all of this is trying to find people who have that humility and understand, I'm at the beginning of my career, and I want to learn, and teach me, and I will do it the way you tell me to do it. And that is such an amazing amount of efficiency in software development. There are a lot of software development departments that have senior people who are just always butting heads, because there's this almost kind of primal need for them to preen and show off their technical knowledge. And so, not only is it a recruiting advantage, we've really never had a difficult time finding those developers. It was never difficult at any time, even in 2021. But it's this enormous cultural benefit in the development teams. So many companies have these toxic software development departments where people are just fighting all the time and trying to show off against each other. And that's really not what- I mean, it's not what we have at all. People are very supportive, and everyone's trying to help everyone get better and learn.

Callan Harrington  23:48

Can you break down that boot camp that you guys put on? And what are those phases look like? And what are those stages? And kind of the details on that?

Joe Emison  23:54

Sure. Yeah. So we've worked with some community development corporations in Columbus to recruit people. But so we bring people in, the last time we ran it, we had a I believe a $200 a week stipend if you were doing well enough on it. So this was a boot camp you didn't have to pay for; we actually paid you to do it. We ended up being all remote. We actually had a classroom that people could go to, but nobody did. And so it was twelve weeks, we selected the curriculum, our VP engineering, Ivan Herndon, who's fantastic ran this boot camp. And he set up the curriculum in Code Academy. And then at the end of the course, which we designed to just be HTML, CSS, React, and JavaScript. And most boot camps try to teach you twelve or fourteen technologies. And in our experience, you don't learn any of them, at least from the boot camp, you have to do extra work. And so for us, we were teaching a smaller number of things. And then at the end of it, we have a homework assignment that is what everyone who has ever been hired for Branch has had to do. This homework assignment, which is just, there's an application, we give you some designs and you have to enhance the application of it. It's pretty simple. But it really tests, do you know that front end work? Can you make it look like the design? And most people fail it, because they don't pay attention to detail, and they don't make it look like the design we gave them. And that's a great screening tool. So senior developers have failed it because they're like, I don't want to deal with this front end, making it look like the design. But we care deeply about that. We do a lot of front end work. We do a lot of design implementation. So if you do well enough on that homework assignment, we'll offer an internship, a paid internship for six months. And at that end of that internship, if you've done well enough, in the internship, we will give you an offer for full time employment. So that's that path. And so you don't have to pay anything all along. I mean, not everybody makes it through every stage, but you do get that experience. So even if you did the bootcamp, and you join us, you get this six month paid period of time where you get to develop at Branch. You're a developer at Branch, you're just very slow. We don't expect you to do much, and so we give you fairly simple issues to work on that aren't critically important to get done tomorrow. And, you know, something that it might take one of our more senior developers an hour or two, you get to work on for two weeks, let's say.

Callan Harrington  26:13

That's excellent. I think that's such a way to lower the barrier of entry to a really skilled position. So I absolutely love that. So let's talk about Branch a little bit. And what I'd really love to dive into are a couple things, of course, the you know, why Branch? Like what drew you to that? But I'd also like to know, what did you do differently? You know, this being your sixth startup, the sixth one you founded, what did you do differently going into this one that you didn't do in the previous ones? Or maybe that you did do, and you're like this, if I'm doing this again, like this is going with?

Joe Emison  26:50

Yes. So Branch is an insurance company, personal lines, property and casualty, so home auto renter's umbrella, condo, etc. And we are a carrier, our own carrier, and so full stack carrier, and we built all that from scratch. So we do our own filings have our own products, etc. And we built a decent amount of software as part of launching Branch. And the philosophy that I have is that you should only build the things that differentiate you. And if you can buy it out on the open market, and it can do what you want, then that's it's not going to differentiate you because other people can have it.

Callan Harrington  27:27

Do you have an example of that, in particular?

Joe Emison  27:28

Sure, at Branch, our claims system, we buy from a vendor. We want to be great at claims. We are great at claims. But there's nothing in the way that the claims management software works that we felt, we needed to build that from scratch, in order to deliver the claims experience that we were going to deliver. And so you just buy that. Another example is, at the beginning, we had our head of insurance thought that we needed an underwriting system. And so I researched a bunch of underwriting systems. And I said, you know, these feel like ticketing systems, support ticketing systems that I'm used to. And she would say, well, it doesn't have this part of that, there's this underwriting thing that that system doesn't have. And I'm like, I think it does, and I would you know, set it, configure the ticket system that way. And she would say, well, I guess we could use it that way. And so we got to a point where I said, look, I understand you have concerns that this isn't going to be the right thing in the future for us. But what I can tell you is it's going to be way cheaper, faster, easier for us to buy a system, and use it, and let it teach us what it's missing, so that when we build it, and I in my head, I was thinking, we're never going to build this thing. But fine, let's assume we're going to build it when we build it, we'll know a lot better how to build it. So we bought Zendesk for this, we implemented it, and we left Zendesk. We left Zendesk for none of the reasons that that head of insurance brought up, not close. We left Zendesk, because it wouldn't let us automatically send text messages to our customers, like your billing failed. And the way Zendesk works is, if you send that text message, if they write back, you can't get it back into Zendesk. So we switched to a system called Front, that's a competitor Zendesk, that allows you, when you text the "your billing failed," if they respond, it starts a conversation in the communication system you have. That's why we switched.

Callan Harrington  29:26

It is interesting, right? I mean, I think it's kind of like Who Not How. I don't know if you've ever read the book, Who Not How, but essentially, this is going to be a different parallel, but if you go to a who, if you've got a problem you need to solve; content's probably an easy one, on like the marketing side, to talk about this. Let's say you're gonna start posting on LinkedIn. I use this example because I post on LinkedIn all the time, right? So I can start reading all the things on the algorithm. I could read all these things about copywriting or I can work with somebody that can coach me on how to do this. I'm going to dramatically shorten that learn curve by finding a who. And now, right like now it's like training wheels are off, everything that I put out there is like, I've written. Now there's positives and negatives to that. But that greatly shortened my learning curve, working with somebody that knew how to put it in this format. I never thought about doing that from the perspective of let's buy this now. When you just said that, what clicked for me was, it wasn't even the problems that we thought we needed to build, it was a totally different set of problems. That's really interesting.

Joe Emison  30:31

Everyone has such confidence that they can design systems and they know how to solve problems. I mean, everybody does. What I have learned over the past twenty-five years, is that as the scope of what you're trying to design increases the likelihood that it will not solve the problem approaches 100%. And so if we're talking about something really small, I believe you, although probably our designers, and our product managers should design our solutions and not, you know, stakeholders. Stakeholders should identify problems. But if it's really big, nobody, nobody at all, is going to be able to design it. At Branch, we have these things called our roots, our cultural roots, and one of them is called this is V1. And a big part of that this is V1 is saying, let's have that humility to understand that we're not going to be able to design these big things all at once. And let's go design the first kernel of it, and get it out, and get feedback, and understand, and then iterate on that. And so that was that Zendesk choice. And you asked me, what is it when I started Branch that I did that was sort of different? Or what did I focus on? I had had this philosophy, this philosophy feels very native to me from fifteen years ago, from maybe even twenty-five years ago. But when I had been in companies before I had gotten pushback from, you know, you get some advisor or some investor, or maybe your co founder says, well, you know, they use Salesforce, are they, you know, everyone else is building it this way, or everyone else hires this person. And certainly in building Branch, I said, I have done this enough, that I know that my way works, and I know how to run it my way. And my way is cheaper. And it's faster. And I certainly think it's better. And so I'm just not going to take any of that. I mean, I'm only going to do the things that I know work in this system. And so that is one of the things that I just, when I was in that situation, I wasn't going to let us not use Zendesk. And so really the problem to solve, in my mind in a lot of these conversations with stakeholders in building Branch was, how do I get them to understand that this is the better option for them. And so that that is a skill that I've worked on a lot at Branch.

Callan Harrington  32:54

Are there situations where you're going to bend on that?

Joe Emison  32:56

I mean, if I don't understand the problem, I need to understand the problem to solve first. And so the stakeholder gets to define the problem to solve. But once the stakeholder has defined the problem to solve, unless I am unaware of what the options are, I mean, I would have to misunderstand something, but generally speaking, when I'm in these situations, these are cases where, for a small amount of money, and in one or two weeks or maybe a day, we can get going. And the solution that the stakeholder wants to do is going to cost ten million dollars and take two years. And it's like these are so different. And we obviously should pick this other one. And so how can I get you to think about this in this way. And one of the things I've learned a ton from my co founder, Steve Lekas at Branch, is I was, in all previous startups that I had, I would just lecture you about it. So I would have said that your thing is going to cost us millions of dollars and take years, and my thing is cheaper, faster, better, and so we should just do it, okay. And so he has been a great influence on me, in terms of thinking a lot more about how would someone react to that? And what's the right way to have that conversation with someone? Because the most likely the situation, and what it tends to be, is they're just not- they don't have the same information I have. Right? And or in some cases, they're optimizing for something different than what I'm optimizing for. And so we should make sure we're both optimizing for the same thing and it's the right thing for the company.

Callan Harrington  34:29

How do you have those conversations now?

Joe Emison  34:30

I mean, the most common way that this comes to me is I end up in a meeting where someone is proposing that we buy some software that they used to use in their past job to do a certain thing; that's really common. And so I will always start with, and oftentimes there's like a big presentation with lots of slides, but it's not coherently to me set on a good foundation. And so I always want to say okay, what are we trying to optimize for, one. Then, two, what's the problem we're trying to solve? So these are different things, right? What is the part of the business that we're in? And then, which is what we're trying to optimize for, and then, what problem are we trying to solve in this space? And a lot of times when these proposals come to me, they're pitched as, it solves this problem, and this problem, and this problem, and this problem, and this problem, and this problem, and like, I don't even know if we have all those. I don't know if they're quantified, and they will have quantified some problem, but it's not clear that that problem is fully solved. And so I really want to get into, let's identify the problems, let's identify the cost of the problems. Have we identified ways that we wanted to solve these problems internally that are not by doing a big project? And what do we think the cost would be if we change those? One example that came to me was, we have a way for people to do self inspections. And there was a proposal to buy this software and replace the self inspections with us doing inspections from aerial photography. And these are kind of two different things, like we need to break these apart. Can we first understand, are we okay doing inspections by aerial photography? Does that meet our criteria, right? So we should decide which one of these we're doing. And then once we do that, we should then get an outline of the different ways we can do it. I want to break all these things down into a very logical set of discussions. And when you do that, it tends to kind of all fall out. And so a lot of people, I think I view it as they combine a bunch of issues, and then it's very difficult for them to understand why you would have a different opinion, because in my head, they're thinking about in a kind of a muddled way. And it's great if you pick these things out. Law school was very good for this, by the way, in terms of how to take a problem and break it into its individual component pieces.

Callan Harrington  36:46

This is going to be a perfect segue. How did you decide to have the headquarters in Columbus?

Joe Emison  36:47

So Steve, and I lived in different cities at the time. I was in Asheville, North Carolina, and he was in North Royalton, outside of Cleveland. And we looked at every metro in the US. And we ran a bunch of data, we narrowed it down to twenty-one, we asked a bunch of people what they thought of the twenty-one. We narrowed it down to four, and we visited all of those four, and then Columbus won pretty easily out of the four.

Callan Harrington  37:16

What did your wife say, in this process?

Joe Emison  37:20

She, in visiting all of them, she was like, okay, I get it. But also, I hate it.

Callan Harrington  37:29

What are her thoughts now?

Joe Emison  37:31

I think she would say, and I would certainly agree, that Columbus is the, I cannot think of a better city in the United States to raise a family. It is just the absolute- it just- there's nothing compares to it for raising a family, for being affordable, for having great schools, not bad traffic, it's growing, so there's a lot of sort of surplus. It's really unique in all of those. But I think, if we had no children, I think there are other places we would choose to live.

Callan Harrington  38:02

So one of the things I'm curious about is, you know, since you made that decision, and I encourage anybody to look up the YouTube video of your talk on this-

Joe Emison  38:11

If you search for "why we chose Columbus."

Callan Harrington  38:13

It's excellent. It goes through all the details. It was a very objective, logical reason as to why. What I'm curious about is, when you originally made that decision, and from a business perspective, from where you're at now, did it live up to what you were expecting?

Joe Emison  38:30

From a business perspective, yes. It has a great low cost of living here in Columbus. It is very easy to live and work here. But we are a remote company. And so if our business required that, or we thought it was necessary to bring everyone into the office every day, I think we still would have been successful in Columbus. But I think we would not be as successful as we are now. But if we had been in New York, or San Francisco or LA, or you know, Miami, I guess, Boston, we would still have a ton of remote employees. The traffic and commutes in those areas are terrible. And we just have a tremendous amount of employees that we just wanted to hire, that we had known from prior careers, and we hired them where they were.

Callan Harrington  39:17

Here's something I'm curious about, now how much does this strategy of developing junior employees, junior developers, I should say, how- is it easier to do that in Columbus? Do you think that that brings you an advantage?

Joe Emison  39:33

I do. I do. I think there's real ease of bringing people together in Columbus. It's very easy to get to. It's very affordable. We found quite a few people in Columbus who did the boot camp and joined us. And so most of our tech team, I think most of our tech team, is in Columbus, although we certainly have people throughout the US. I just think having lived in Manhattan, DC, New Haven, Boston, there is a level of just, it's hard to get around. It's hard to get places. There's just a lot of overhead on your time to be places that doesn't exist here, that I think makes just living here easier, and easier to get things done.

Callan Harrington  40:15

Yeah, it's always a debate. And I'm not- I mean, I live in Columbus, but I am not a- I tell younger people all the time, like, what do you want to do? Then go to Manhattan, like you should go to San Francisco, like the density, the networking that you're going to do, the relationships that you're going to build, like, you will have an advantage in doing that. There's no question. I knew the disadvantages that I believe that I had. Now, I was in insuretech. So I just happen to be like in the spot where there's a ton of that, which was, I know, it was a factor for you guys coming here. And there's a lot of insuretech companies that have a second office in Columbus. But I never looked at a breakdown like that, and I thought that was super interesting. So I'm curious, because you guys have really scaled out, what have been the biggest challenges in that, that you guys have had to overcome to be successful in that?

Joe Emison  40:36

I think the hardest thing is always around culture. How do you keep the culture? How do you have a strong brand internally and externally? Which is something we started working on, even when there were just two of us. And so we started writing down these routes at that point in time, and we've had them as part of our onboarding, and we've updated them, we say them all the time. And I would say the most significant reprimands that we have had, for like senior leaders or leaders in the company, have been have not been about performance. They've been about not treating people properly within the company, or not treating our customers or members properly. And so setting that example, and trying to make that flow through. But ultimately, the hardest thing when you scale, is you've hired all these people, and not all of them do or act in the way that you would want.

Callan Harrington  42:00

How do you do that? How do you create processes or systems, whether that's, you know, systems to recognize, you know, aligning with the culture, or systems to- in the opposite, right, of saying like, you know, that's not the way we do things?

Joe Emison  42:14

Essentially, the main thing you have to do is your leadership team all has to be on the same page about what it is- how do you treat people? How are you going to treat people? What are the rules around treating people? And then you have to hold your leadership accountable for that. If you don't do that, then there's no way that anything is going to flow down, right, every department will have its own belief, right? If you're not willing to enforce. Also, if you thought about, if there's like a two by two grid, and one dimension is cultural alignment, and the other one is performing in your job. Most companies will take, obviously, if you're performing your job, and you're culturally aligned, that's great. That's perfect. Everyone likes that. But most companies will look at performing in your job, not cultural alingned, like being a jerk, right? Most people will look at that as like, well, that might be the price, we have to pay for the performance. But in the same way, most companies will say, well, that person is super culturally aligned, everyone loves them, but they're not performing their job, we should get rid of them instead of training them or understanding how to make sure they're better in their job. And I think if you explicitly do the opposite, if you explicitly say, you can't stay here, you don't have to set many of those examples before everybody gets it.

Callan Harrington  43:26

That is a huge problem on the sales side. And it's probably pretty obvious when you break it down, right? You can have-  The Challenger Sale called it "the lone wolf." And the lone wolf is somebody that produces, but they're on an island, they may be bending the rules to get some of these deals, they're probably not a great team player. And I think for me, personally, until I realized that- because I took the opposite, I'm like, well, we're producing, like, everything's great. I didn't realize until I really saw the impact that that had on the team. And I can imagine how much harder that is at scale. Because now you have to instill that from managers of managers of managers, right?

Joe Emison  44:04

There's so much in the organization that you cannot see, and so you are constantly worrying. How can I know, if there's like, just there's so many meetings that are happening in this company that I have no idea about, and there are people doing things that I have no visibility into. How do I know that they're being conducted properly? And how do I not know that like maybe the leader of that department says the right things up and across, but down is doing something totally different?

Callan Harrington  44:35

How do you know that? How do you know? I'm actually super curious.

Joe Emison  44:36

You know, you have to tell all your employees regularly what appropriate behavior is, and you have to create ways for them to report up, and you have to do skip levels. And you, within information security, you shouldn't think "if we get breached," you should think "when we get breached," right, when there is an incident, we'll do these things, because if you're a assumption is, it's possible for you to never have an incident, then you're in a lot of trouble. You're going to have incidents. And so in the same way, you have to assume you're going to have incidents of people. You're going to hire people, you're gonna hire managers, and they're not going to work out, they're going to do bad things. And they're gonna do bad things, they're not bad people, they're going to do bad things, because they're not self aware, because they have some blockers in themselves that make it so they can't take feedback, that they don't really seek honest feedback. And you have to make sure you're vigilant and you find them.  I love that. I think that's such good advice of you've got to see what's going to happen. Because it can't be an "if." We've got to know that this is going to happen. What does the next stage of growth look like for Branch? Getting to enough scale to be, you know, fully self sufficient. That's always the goal, is to be default alive. And so it's just a constant movement toward, you know, the right unit economics. We only want to grow as fast as our loss ratio allows us to. And so-

Callan Harrington  46:04

What do you think that you need to do in order to get there?

Joe Emison  46:07

There are so many things, but we're really executing on the plan that we have. I mean, in insurance, there is this challenge, that you are predicting the price of future claims. And so you have to make sure that you're accurately predicting the price of future claims. And so you do that in a lot of different ways. You get experience, you understand what's happening, your production, you adjust your price, and you make those changes. And so it's just this constant feedback loop.

Callan Harrington  46:34

It's one of the only industries, that and lending, which I know you have some experience with, where you can be penalized for selling too much.

Joe Emison  46:41

Oh, yes. Yep. Yeah. Absolutely.

Callan Harrington  46:42

Last question I have for you, Joe, is if you can have a conversation with your younger self, age totally up to you, what would that conversation be? What advice would you give them?

Joe Emison  46:53

Other than you should mine Bitcoin when the opportunity comes up?

Callan Harrington  46:56

That's it. Thanks ladies and gentlemen! (laughs)

Joe Emison  46:58

And sell it in 2017. No, or 2021. The principal thing that I think I've learned, and this saying can come off a bit obnoxiously, but I think of it as: on average, people are average. And when I was, I would say, all throughout my twenties, I had this view of like, this person is a CEO over here, that means they're better, they're smarter, they're more capable, they're whatever, right? Or this person- There's so much luck in this world, so much luck. Most people who are successful, there was like a good healthy dose of luck in there. And so there's a level of critical thinking that I would tell myself to apply to anybody in any situation. Because I certainly learned that it was not okay for me to have a CEO come and say, hey, I would love to start a business with you. Here's all the ideas, here's what it is. And if I would say, I don't understand how that part of the business plan is going to work. And they would say, don't you worry your head about it, you're the tech guy, I'm the business guy, I got it, I got it figured out. What I realized over a long period of time was, that's not for me, I need to understand it. If I can't understand it, and I think there's a weakness in it, then it's not gonna work. And I'm just not going to believe it. And I welcome CEOs who are willing to get in with me on the tech side and say, or any executive who's like, why are you doing it this way? Why do we not do it this way? And I have, I'm happy to have those conversations all day long. Sometimes I'll say I need you to read this book first, and then let's talk. But I think having a general understanding that most people in their jobs are average at their jobs, they're not excellent at their jobs. And so having a healthy skepticism, when you come into any situation, and not giving a lot of weight to someone's advice, because of their role, or their position, or their bank account, or anything.

Callan Harrington  48:58

Is that almost trusting your gut?

Joe Emison  49:00

You know, I think maybe part of it is trust your gut when you've got enough experience, but I get gut feelings all the time, and I don't have appropriate experience in them. And I discount that, I think, hopefully, appropriately. I think it's more that if you want to know something, you should do research. And if somebody tells you something who has a position of authority, or power, or wealth, on average, that's not any better advice than if you stopped a random person in the supermarket and ask them the same question. I just don't think it's they're likely to give you any better advice in that context.

Callan Harrington  49:34

I tend to agree with a lot of that. And I think one of the things in my career, either whether it was selling to CEOs or having them on the podcast, is that there's definitely smart people, but a lot of them- like everyone's human at the end of the day, and I don't believe that there's this giant gap between- certainly don't get me wrong, certain people are better at certain things, like I would never be better at basketball than LeBron, period.

Joe Emison  49:58

Really? (laughs)

Callan Harrington  49:58

But I hear totally what you're saying. I think that's such good advice. Joe, this has been excellent man. Thanks for coming on to the show.

Joe Emison  50:04

Thank you so much for having me.

Callan Harrington  50:10

I hope you enjoy Joe and I's conversation. I loved hearing how Joe gets more production out of fewer people. If you want to learn more about Joe, you could find him on LinkedIn in the show notes. Also, if you liked this episode, you could find me on LinkedIn to let me know. And if you really want to support the show, a review on Apple Podcast or Spotify is very much appreciated. Thanks for listening, everybody, and I'll see you next week.