The Technical Founder: Recent Episodes

View Details

Welcome back to another episode of The Technical Founder, the show where I meet with founders to deconstruct and demystify the art and science of building technology businesses

My guest today is Doug Coors. Doug is the CEO of Edel Golf - a company that makes custom golf clubs personalized to each player's specific swing. You may be asking - golf clubs? I thought this was a show about technical founders?

Buckle up. Doug has made his career in business and entrepreneurship in solving a series of innovative technical and business problems. He brought highly sophisticated ceramics to market with CoorsTek, tamed the physics of waves with NLand, and with his most recent acquisition Doug is bringing the codified results of sophisticated athletic analysis to golf players across the country.

Please, enjoy.

Doug Coors [CEO, Edel Golf] - The power of shared vision, conquering waves, and finding that perfect swing0:00/75:551×Highlights[19:49] People skills are critical in business

[44:02] Doug's first foray into entrepreneurship after a career in business

[53:03] Overcoming big obstacles

[109:32] A masterclass on how to launch a business venture in a new domain

Transcript (Provided by Otter.AI)SUMMARY KEYWORDS

people, patents, golf, wave, problems, create, company, product, year, technology, surf, surfing, liner, work, doug, talk, business, innovate, park, ended

SPEAKERS

Ryan Rosztoczy, Doug Coors

00:12

Welcome to the technical founder

Ryan Rosztoczy 00:25

welcome back to another episode of the technical founder, the show where I meet with founders to deconstruct and demystify the art and science of building technology businesses. My guest today is Doug Coors. Doug is the CEO of Adel golf company that makes custom golf clubs personalized to each person specific swing. So you may be asking golf clubs, I thought this was a show about technical founders. Well buckle up. Doug has made his career in business and entrepreneurship by solving some truly challenging technical and business problems. Doug is brought highly sophisticated ceramics that can withstand an earthly temperatures to market with course, tech. He's tamed the physics of waves to bring the US its first serve park with inland in Austin, Texas. And with his most recent acquisition, Doug is codified the results of sophisticated athletic analysis into a manufactured hard goods product. Doug is one of those entrepreneurs who you can rightly call a force of nature. I think you'll see what I mean from our chat, and I hope you enjoy it just as much as I did. Hey, Doug, thanks for coming on the show.

Doug Coors 01:43

Hi, Ryan. Thanks for having me. This is awesome. Yeah, for sure. My first or second podcast.

Ryan Rosztoczy 01:49

Awesome. I'll take that as compliment. Yes, so okay. I mean, I have a ton of stuff that we're going to talk about, like really, really excited to get into your career, the way of park. But I would love if you could just give a little teaser of what you're working on now to start off.

Doug Coors 02:16

Oh, so right now i, for the last three years, we're working on a golf equipment company. Del golf, LLC is our our corporate name. And we are just a incredible innovator in the world of golf equipment and how it relates to each individual player. So we can customize solutions for anyone. And it's really exciting to watch and fun to be a part of.

Ryan Rosztoczy 02:43

Okay, and I loved when you were telling me about it, some of the details. So when you say like customize the solution for golf, what does that mean?

Doug Coors 02:52

Well, each player is different, their body makeups are different, their swing is different, how they approach the game is different, you know, either mentally or what they're trying to accomplish. And we're out to create equipment that works for any individual golfer to make them better at golf. So I mean, our philosophy is, if you can hold more putts, you're going to lower your score. If you can get the ball closer to the green with chipping, then you're gonna lower your score, because you're gonna lower your putts. And if you can have more accurate irons, then you're gonna have more opportunities to make more putts, and you're gonna lower your score. And at the end of the day, we're not in the woods yet, but we're taking a close look at that market as well.

Ryan Rosztoczy 03:37

Three. So I mean, basically, it's like, if you can highly customize and optimize the equipment for each player for each part of the game, you can get them to sort of like this optimal state of their golf game. Is that the idea?

Doug Coors 03:56

Absolutely, yeah. It's just to help them play, have more fun playing golf, like scoring or beating their friends.

Ryan Rosztoczy 04:04

It's so cool. I, I just read this article recently, that was saying we're entering the age of, we went through the age of essentially like optimization via mass manufacturing, and we're entering this age of optimization via mass customization. So it's really cool to see you guys like working on this problem.

Doug Coors 04:25

Absolutely. That's kind of where the whole thing's going with all of golf. Really. It's just so much information now with technology out there on ball flights and spins and windows that you can hit with your golf clubs and all kinds of stuff. That's just just now starting to become mainstream. And people really know what their what their clubs are doing based on analyzing ball flights and understanding the data behind what's going on.

Ryan Rosztoczy 04:53

So like when you say analyzing it, like what what does it look like? Like you're gonna build a custom Club or somebody, you need a bunch of data in order to make those changes. How do you guys like analyze their game? Well, essentially,

Doug Coors 05:10

you can you do it in different ways. So there's a something called a launch monitor, which gives you the ball flight data. And there's also how you how you, your club path and your face angle, angle of attack, and all these things that can be measured on for club data. So we understand not only what's happening with the ball, what's happening with the club, and then we optimize that to create a better face to pass scenario with more clubhead speed and better spin rates, launch angles, descent, angles, all that kind of stuff.

Ryan Rosztoczy 05:48

Oh my god, that's so

Doug Coors 05:50

kids really fine tune your game, you know, up to, you know, hitting your yardage is perfectly and gapping your clubs completely. I don't know how many, you know, common players are doing that. But it's it's important to know, you know, the, your, your flight data and what your balls doing. So that when you get to the course, you know, really what clubs, you're supposed to be hidden.

Ryan Rosztoczy 06:14

Okay, so one of the things that comes to mind just talking about this is like, when this level of optimization becomes impactful, I mean, obviously, like talking about it here for golf, but I think just in general, it's like a curious idea to me, like, we enter this age of mass customization, just how much change is that going to create in the world? So I golf, but let's say I golf, like five times a year, or they're at versus you who is who's sort of a passionate life golfer? Is there a point at which there's this type of customization becomes like one of the only ways you move forward? Or would it be like you're so expert, you know, you get to this level? And suddenly you need this customization? or would this help somebody like me, who's a casual player? Or, you know, anywhere in between me and you?

Doug Coors 07:10

Yeah, definitely. It's, it's a cycle. It's an ops as musicians cycle, I guess I'd put it that it's a constant refinement. Right. So for me, I would be refining more often for you, you would want to analyze what you're doing the five times a year what's, what's going on. And so to start with, anybody can be a great putter. It doesn't take extra strength or extra. Anything really, physically, anybody can become a great putter. And so starting there, you could become an awesome putter, even if you only play five times a year.

Ryan Rosztoczy 07:52

I never thought about putting is that? That great? democratizer of golf.

Doug Coors 08:00

Yeah, it's one of those things. If you become a great putter, people are gonna say you only play five times a year you're cheater or whatever. Because you're rolling putts, and they're like, Well, man, what are you doing? How are you doing that? And so I know a lot of players that don't hit the ball well, but there are amazing putters, and everyone that's been a golfer around you know, the amateur ranks that plays in in what's called a scramble, where everyone gets a shot at the making a hit or the strike or the putt. There's some guys that are just such great putters, I could care less if they can hit a driver or an iron but they're so good at putting that you just want them on your team because you know they're making putts

Ryan Rosztoczy 08:45

you get them to the hole and they get you in teamwork, love it. Yeah. Okay, so it's this idea of, of feedback cycles, which is just an awesome, I was awesome concept and technology in general. And basically, I'm gonna have a less if I'm playing less per year. But each time that I am analyzing and optimizing, I'd probably see a big change then I would assume.

Doug Coors 09:16

Certainly, and it depends on your dedication to working on it. If if you're going to go just straight out to the golf course and hit five or 10 balls and go to the tee. You're going to have less chance of gaining in that optimal cycle right? So the more you practice or the more you focus on something you can, you can iterate more often and be become better at it. But that being said, there's a lot of things that can happen with understanding how you approach the golf swing, whether it's through biomechanics, or even even some mental mental thoughts as you as you go through But what's your muscles, what your body structures doing how you perceive hitting a ball, right, it would would tell me a lot just to see you swing, and then we can optimize your equipment based on your swing, or we can give you tips on some thoughts or some actions you can take without playing golf, that would help you with your swing or with your biomechanics or whatever have you. So it might be a grip, slight grip change, it might be a just a thought process, or a muscle triggering exercise that we can put you through to develop the right mechanics, you know, at the bottom of your swing.

Ryan Rosztoczy 10:44

Wow. Okay, so when you say bottom of your swing, that brings me back to you mentioned earlier, I think this like face to path. Or what was that

Doug Coors 10:56

face to path. At the end of the day, if your path meaning, which is the direction your club is headed at impact is square to your target, and that face is square to that path, then the ball is gonna go straight?

Ryan Rosztoczy 11:11

Okay. So, yeah, so when you're like optimizing the essentially body quarks for the bottom of the swing, that's what you're optimizing for. You're trying to get that optimal face to path connection. Correct. Okay. So what I love about this is, it's almost easy to think what you're talking about is analyzing sort of how somebody plays the game and then giving them advice. But that's like, a small part of it, right? Really, what you're doing is you're, you're sort of baking or your analysis into their interaction with like, the real world game of golf through either changes in behavior or what I think is even crazier in the club itself, right?

Doug Coors 12:07

Correct. Yes, most of our focus is in in the club, the club design and the construction for a particular individual.

Ryan Rosztoczy 12:16

That's it. So why, like, it's easy to just think you're gonna give customized golf advice, which I mean, it's super cool at period. But the fact that you can then transfer that knowledge into a physical item is just amazing that we,

Doug Coors 12:31

yeah, it's it's that intersection of everything, right? It's intersection of the club, the understanding of the golf swing, the club and the weighting of the club and how it impacts you as a as an individual. You know, and there's all the components, there's the shaft and the club head grip. You know, how you grip the ball, how your body works, and how to optimize it, basically eliminate all the variables for you to a minimum, not a variable so that you are now more consistent.

Ryan Rosztoczy 13:06

Yeah, I've never thought of the golfer as a system. But that's really what you're talking about. And you're optimizing the system. Yes, that's so cool.

Doug Coors 13:19

With any human system, it's, it's flawed.

Ryan Rosztoczy 13:23

It's complex.

Doug Coors 13:24

It's fun.

Ryan Rosztoczy 13:25

Yeah. Yeah, you should work with a Boston Dynamics. And then you can have a perfect system where the robot the robots are golfing. Yeah. Cool. Okay. So we'll get back to that later. Because I do want to talk a little bit about the business there. But we've got a lot to talk about. So I would love to just go back and start I mean, you have essentially led a life of on entrepreneurship business is driven by passion, which is why you're working on golf right now you did the wave Park, because of your love for surfing. So I would just love to like go back and kind of maybe start really earlier in your career college, whatever sort of speaks to you. When you decided to get into these, like highly technical, Passion Driven career, like can we go back for the early and just and talk about how it all started?

Doug Coors 14:27

Absolutely. Yeah. So you as a child, I was, I guess considered gifted and and in math, or whatever that is. And so I was in all the, you know, geeky or whatever the advanced classes and I always looked up to my brother who was a real people person, but I was not I was like numbers, numbers, numbers, very analytical and could could figure stuff out pretty quickly and I learned quickly. I Um, but I always had trouble interacting with people. So my whole childhood was man, I want to be like my brother and figure people out, right. But of course, I was trying to figure people out through physics and math and analytical stuff, and it

Ryan Rosztoczy 15:19

doesn't work that way. Understand the system?

Doug Coors 15:22

Yeah. So I, yeah, exactly. I was trying to get the system dialed in. Anyhow. So I got, I ended up going to Colorado School of Mines. And getting a degree in physics, engineering, physics, specifically, never really liked school, I didn't like the way school was broke grammatical, and checking the boxes here and there. And I thought, you know, I would rather learn, I learned differently than that. Some things I get, quite easily. You know, as a kid, when I was doing multiplication tables, or whatever, I would have it nailed in five minutes. And then I'd be sitting in the classroom waiting for 30 minutes for the next thing to do. And it really just turned me off on the whole school system. So I wanted to get out of school as fast as I can. And I got my degree in physics, because it was the least amount of credits for.

Ryan Rosztoczy 16:23

Okay. Because that's, like, go ahead, say that's the least amount of credits, because it's probably the hardest credits to plow through. It was, it was, but I, you know,

Doug Coors 16:39

when I get determined on getting something done, I get it done. So I was I got to play basketball in college, Division two. And that was, that was a blessing, a lot of fun. And I really have some good friends and good camaraderie. And I think always in sports. If you if you play competitive sports, do it as long as you can. And then I was not. I'm 510 145. Now 160, I wasn't going to have any aspirations to be out in politics just wasn't going to work. So. So yeah, I was just love sports. And I loved engineering, and math. And physics actually love the philosophies that kind of go around developing theories and proving them out and those kinds of things. So I really enjoyed that time, didn't know what to pursue. So I ended up working for the family business temporarily on a project that I had a little familiarity with, through my senior project at school mines, and they had landed a government contract, and needed someone to run a program to develop automotive components out of ceramic that they had been awarded by the Department of Energy. But I ended up really enjoying it, it was developing a product that was extremely difficult conditions to two, it was it was an exhaust pipe liner. Actually, it was in the cylinder head. So it was gas port liner. And we had to be able to figure out how to make a piece of ceramic survive a 2200 degree molten iron for and you know, the thermal dynamics of that whole thing is crazy. But we were able to do it. And it was a diesel engine. And the whole idea of it was to save on fuel economy. And the calculations were that if we were able to do this, it would save 5% on fuel economy, which is just a crazy number. So it all kind of started there, it ended out ended up after several years being too expensive, and too risky for the large automotive companies to invest in it. And they they basically said, if we're going to do this, we would do it on a 10 year cycle. So we'd be designing a an engine 10, that's 10 years from now. And at that point, I was kind of like, I don't know if I can stay on this for 10 years and go through all that rigmarole. But we had success. We got some good data on it. And when it became a 10 year program, I decided that I wanted to move, move on go somewhere else.

Ryan Rosztoczy 19:33

Do you feel like by the time you go back to core sec, that management experience, do you feel pretty confident in your understanding of working with people, you're comfortable in this with it? All that stuff at this point?

Doug Coors 19:49

Absolutely. Yeah, I had, you know, gone from pretty much run the gamut of, you know, working with frontline workers and All the issues that they deal with on a daily basis and, you know, they get confronted with all kinds of issues with dealing with their kids or their, you know, their spouses or just dealing with life in general. And it's, you know, it's, it's noble that they come in every day, and they spend eight to 10 hours or whatever it is doing a fairly mundane task, which is, you know, actually helping the company succeed. And they do it. Well, they take it seriously. And they put their pride into having so many cartons boxed in a day, or whatever it is, whatever the measurement system is, and it's really fascinating and fun. And so I really, I think, started to learn a lot about people. And I think

Ryan Rosztoczy 20:47

it's an interesting thing for anybody who's like going to go into a career in business or entrepreneurship, the human part of it is so huge. But things like managing the production line, like it just doesn't sound nearly as sexy as creating novel ceramic casting techniques that can let you sort of make an molten environment behave how you want it to be. Right. But like without it, you definitely couldn't tackle the kinds of things that you have in your career after that point. So I think it's just a really important thing to think about, especially for people who are highly technical. Even for me, it's easy to default and stay in this space of, I want to be a software engineer, I want to go down that track, even if I'm founding something, I'm gonna stay in the technical space, because people problems are hard and thorny. But by engaging with that, and being highly competent in it, you just, you get a whole different skill set. So I think it's really cool and important to hear.

Doug Coors 21:51

It's the most important thing, it's what makes the world go round. You know, it's, it's full of people, and it's all about people at the end of the day. So

Ryan Rosztoczy 22:00

yeah, it's, I recently I've started thinking at some point, if you want to, when you want to start doing bigger things, people skills sort of becomes like your interface for making them happen.

Doug Coors 22:15

Absolutely. That's so true. Yeah, right. You have to enroll people into what you're doing. And people want to help people in general, that's not true in every case, but the majority of people want to feel important and accepted and loved and feel like they've done something good for somebody else.

Ryan Rosztoczy 22:37

You're back at Coors tech. And I feel like we're getting close to sort of where the entrepreneurial journey starts to formulate. So what happens when you go back to Course, tech,

Doug Coors 22:50

I went back to Course Tech, we had started, they had started a new business venture, I would say expanding from they had a bunch of machine shops out in California to assembling product for the semiconductor industry. So they would would machine components mostly out of aluminum, and then assemble them and test them. So it'd be like an etching chamber, or some other process for for moving silicon wafers through through a clean cleanroom process to getting you know, getting them etched and deposited with the right materials and all that kind of stuff, very highly technical things that use all kinds of really strange stuff. But we made a lot of the components for these pieces of equipment. And so we started the assembly operations. And so I went out there became a project manager ran a couple of projects on assembling what we call, you know, like 1000 piece bill of materials, product that had strict assembly instructions and cleaning instructions and technical specs for testing and delivery. So we would make, for instance, a product for Applied Materials or lamb research. And essentially, we would manufacture it, put their labels and stickers on it and then ship it to their end user, usually overseas or have several in the United States too. And so we would then basically be their manufacturing arm for their equipment. And that lasted about three or four years. The interesting thing that came out of that is after 911 There's a group in Newark Cal Fornia that produced bombed scanner units for luggage. So it's essentially a industrial CT scanner. And they had made 44 units, most of them went overseas for scanning luggage. And after that, the US government stepped up and tried to get our security here in the US to where we could scan for any kind of potential dangerous objects and luggage, which they had done, usually manually at airports. And so these were machines that could do it automatically. And it was go back to Bill of Materials. So we have 5000 components in these machines, very technical specs for being able to deliver to airports around the US. And they went from 44 machines in 2001, to 1200 machines in 2002. Oh, my God. And we helped them build about half of those, oh, my God, it was, it was quite the, what the neatest thing about it was the objective was clear. And people were not comfortable getting on airplanes after 911. And the objective was to create a secure environment and confidence in the American people to be able to get the airline industry back up and going. And these bomb detectors were a huge part of that, there was a lot more to it, we were just a little piece, but at the end of the day, being able to rally around and have you know, hundreds of people buy in from all different, you know, San Francisco is a melting pot, we had people from all all kinds of I think we had I want to say 33 or four countries that people were, you know, from that were that either immigrated or their parents had come from. And so we have this melting pot of people that all lined up to make, you know, get the security and our airports done in this very, very short period of time, and a very complex piece of equipment. And you know that that company went on to be sold to GE and they took it over and we you know, did our product for a year a little over a year, year and a quarter.

Ryan Rosztoczy 27:31

I can't believe that you did that in a year. That's crazy. Okay, okay, so that wraps up what what can happens next?

Doug Coors 27:45

Next, I ended up moving back to Colorado and taking on some management of several facilities in Colorado, for coarse tech. And that was kind of a holding spot. Once Once that was established, I had been working with the executive management group to, to work on how can we how can we innovate better, we have a lot of great technologies we had, we even did a patent review, and we did all kinds of stuff. And it turns out that, you know, our trade secrets are just second to none in terms of value. And so it's rather than try and go out and, and defend patents or create a bunch of, I guess, castle walls to protect the IP we did have, we felt that if we could get we could create new customers or create with other companies new products, because of our trade secret and expertise, that would be a better way to grow. So we started down the road of looking into taking some of the technologies that we had that were very promising and kind of tried to shop them around a certain customers. And in some instances, we actually started small, small companies within our company to pursue that further where we could get funding either from private or from public money. So it's kind of interesting little amalgam of stuff. And then we made an acquisition that was a complete r&d funded by 50% government funding 50% commercial r&d funding so we did research and development for Chevron and Air Products and well, there's a bunch of other companies and, and and the government we have a lot of government projects too. And it was all really a materials science.

Ryan Rosztoczy 30:03

Okay, so Okay, so I love this. So, Scott, he's been on the podcast, he's been a multi time founder, he's the head of engineering and gather. And now, when he was in college, he did this program at Oklahoma, he was also a physics major. So you love that he did this project that was it was a group. And I think he got invited. And they it was like the Institute for Economic researchers, I can't remember what it's called. But the idea was the university and the professors had all these patents that were just sitting around, that no one had ever done anything with. And their goal as students was to come up with cases to commercialize them. So I love that you guys are essentially doing this on an industrial scale. And I would love to just hear like, what does it look like? You've got a bunch of patents? How do you even get to the point of knowing what they are? Which ones to focus on? Do you have people championing like their patents or innovations or a committee that's trying to decide what's the most promising? Like what did that process look like?

Doug Coors 31:16

Well, we were fortunate enough to be able to hire a, an outside firm to come help us kind of get it, we have a, we have a very, at the time very federated model, meaning that each, I think we had 44 plants, and I think, I want to say 38 or so 35, or so we're in the US. And a lot of our growth had been through acquisition. So our IP was dispersed all over the country. And so we had a consultant come in to help analyze and gather, you know, gather IP resources from all these different places in the country. And put together a an analysis, and essentially, the the end result of the consultant work was, we didn't have really enough patents to be to be considered someone who would be a patent driven company. A lot of software companies, you know, are patent driven, and they create walls around their particular IP in either software or hardware around what it is they're doing. We had like a really dispersed set of material patents on formulate things and different ways to produce product. So there wasn't like a strategy around it. So we wanted to gather all stuff and see what the strategy was. And yeah, we quickly realized that our, our strategy should not be patent focused. It should be focused on our ability, not that we didn't continue patents, because when you ever have a novel material design or capability to make, you know, bulletproof, whatever, something or other you want patents around that stuff, so we did. But we we realized that our biggest value was in trade secret of how to create a product that actually works. So whether it's, you know, go everything from ball bearings and windmills to, you know, ball bearings and tennis drills to seals for really difficult applications of oil fields, to, you know, automotive components that need to be what we call on the front side of the firewall, where the engineers so they have to, you know, like an oil sensor has to, you know, be in a really crazy environment. Yeah. So, we've created all that stuff. And it's been able to produce it. Yeah, that's

Ryan Rosztoczy 34:06

what So is it true then? Right, because I yeah, I can think of a million companies that follow the model that you're talking about where they're essentially just massive patent trolls. But for you guys, would it be fair to say the value of the patents was, you knew if you could make a product work, you would have abnormal chance, you would have the chance for abnormal economic return that would make taking additional risk and innovating worth it? Is that kind of where you landed?

Doug Coors 34:46

Yeah, so it was it was really about growth. Yeah. It was really about being able to find other applications for what we did have protected as well as create through working with customers new applications that we need to develop new trade secrets with,

Ryan Rosztoczy 35:08

and how does that stuff work out,

Doug Coors 35:11

it actually led to a path where we, we really started trying to focus on some of this innovation. So we set up a sort of a venture capital structure where we had access to a certain number of dollars. And we created, we took a couple of products that we already had, you know, some business with, peeled it out from the bank company, so that we could innovate more in that space, but also had some some current sales and product, you know, that we could, we could fund fund that partially with and then we had access to small amount of funds to create business units outside of the company. So we had a little redundancy and in probably in management and an oversight of these companies, within the company, but we felt that was worth it at the time for creating this innovative culture.

Ryan Rosztoczy 36:17

But the idea here is you're you're looking at, is it business units? Or is it products where you think there's really promising, like new entry points or growth trajectories, and you've got patent protection around it, you're essentially taking those things from the existing company into this seed, almost like incubator company to really like pour gas on the fire? Is that the idea?

Doug Coors 36:45

Yeah, that was the idea. So we took our sabbatical proud products that we were doing and created a medical offshoot that could innovate outside of our corporate structure within the medical device world. And then we also had a really promising sensor technology for measuring emissions in vehicles, diesel, diesel engines, so trucks and heavy equipment and the like. And there have been some target regulations by the US government to to more accurately measure what was happening in, in those environments, and what's happening in trucking and everything else. And we had a still have probably, I don't know, it's been a long time, a very promising technology in measuring, essentially, whatever the mix of gases coming out of an engineers and providing feedback for cleaner, you know, cleaner combustion, essentially. Yeah. Yeah, that technology is very promising. So we had a sensor company that we started and funded for several years, and they ended up with a I don't know how it ended, I left before it ended, but they had a very promising partnership with a top automotive group that was seriously considering, you know, getting that as a product into the, into the environment for us.

Ryan Rosztoczy 38:28

So what, just real quick, real quick overview, I'm just kind of curious, what pieces of the large existing Corporation make it made it so that it was much faster to innovate outside of it.

Doug Coors 38:50

So yeah, so essentially, the biggest thing is our production and production comes number one. And so your management team is focused on production and hitting their targets and making the business work, which is essential to being able to survive in any world, right, you have to have you have to have profit, you have to have ability to produce more value and gain more value than the cost it takes you to make it or put it out in the world. And that's, that's just being normal. Because running a business at a loss for too long, it just folds and you you, you know, got it you can only do so much. So number one is get our operations in line and running efficiently and effectively and creating that platform that then we can take some of those profits if you will, and reinvest them in future and in and however that is whether it's, you know, future and censored or future medical products or a future and anything else. And so that's how that's how it had work. Now, when you're trying to innovate in that environment, you get second, you get second seat, you will get graveyard shift and even then you probably don't get it because setting up the equipment for a different product or running something specially and trying to consume production equipment or production, people's time, and efforts is seen as a negative in that environment. Whereas if you separate it, you can be seen as this is what we're about is innovating this thing.

Ryan Rosztoczy 40:41

Yeah, it's just, it's so interesting to think about from the perspective of a startup, which is, at some point, the business will mature into a state where the overriding incentive and behaviors are no longer optimal for innovation. So it's good to sort of be aware of that.

Doug Coors 41:00

Yes, absolutely. There comes a time. So. So yeah, I had been working, you know, it's in a well established company for a long time. And we, we made these moves to just try and create more momentum around our innovation. And so we did very well.

Ryan Rosztoczy 41:19

Yeah, so how does so you start this new series of companies under this sort of venture capital, like organization, do these innovations, they start to work? How does that change your career, because you didn't stay at Coors tech the whole time. So what kind of happens?

Doug Coors 41:40

Well, from there we created we had a little bit different direction in the company to we had made some acquisitions and the growth had been more towards fulfilling on those than just filling on the the startups that we created. So it was a combination of combining the medical group back back into the main organization. And at that time, the medical group created great value in products for medical devices. So the value was there. And I think just felt time it was it was time to put it back into, you know, production mode. And the innovation had been largely complete. So wow, that was a real win. And then the sensor company, I think, was established, I believe we ended up either selling it or spinning it off. To keep going and not fold that into the core mix. But it had the products been launched, we would have been the manufacturer of that product. What else there were several other companies, some of them just, we ended up folding, some of them we just held. So we had this, we had this investment arm. And when this was kind of being considered that the whole venture capital model was not something we wanted to continue. So we've kind of folded up that piece and kept another piece that was more private equity style and doing acquisitions under there. So we had several companies, not several, I'd say two or three that were more along the private equity line. And we used since as a family company, it was all about getting family experience in trade and leadership. So we had family members running different companies at that point. So the venture capital piece kind of slid back into the main company and then we had this little private equity piece and and that's what launched by nuclear and a certain part.

Ryan Rosztoczy 44:02

Okay, sweet. Yeah, super happy to get here. Because when I met you, you're working on the server Park. And there's so much to it. So And here we're back to like your life of passion. Essentially, building or working in businesses that are centered around your passion and also highly technical. So like, just just I just want to kick off a little context here because when you when I knew you were working there. I knew it was it was obviously very cool and exciting. And also extremely challenging, but I wasn't aware of just how complex it was. Same Same with with the golf business. So let's talk about the surf park because I think it's it's one of the both things. And I think I mean, even just from you from talking to you at the time I learned so, so many really important lessons. So let's talk sir FARC.

Doug Coors 45:10

I think girl do it. Well, so I had, I had this vision for probably 25 years, I had actually designed us surf part and did a concept. Back in, I want to say the late 90s. I had always, I never really got to learn how to surf until I'd say 91. And I got hit by a surfing bug and enjoyed it for a period of time until I realized that I'm not gonna be able to do that and live a life where I was making money off my butt and start doing something more productive than, than hanging out in the water. So So I, I had to kind of leave that. But it left me with this dream that pretty much every surfer that surf probably has had is I wish I could do this all the time. Because there's not always waves in the spot you're located. There's a whole industry around traveling to surf. And it's, it's pretty fascinating. But I think everyone wants to be able to wake up, walk out their back door, turn on a wave, get a few waves in and then go to work and do whatever. So it's, it's one of those things that that's kind of where I was headed is I live in Colorado, there's no ocean here. There's, at the time, there was no wakesurfing because there were there was a I shouldn't say none. But there was a real group of people that would ride surfboards behind ski boats. But it wasn't, it wasn't mainstream, by any means. And so yeah, I had that in my back of my head, I'd worked on it off and on for 20 years, and I found an article somehow came across my desk or on my computer that had a wave that was being generated in Spain. And it showed people surfing on it. And it's kind of the first time I realized that technology had come to the point where this could happen. And the original surf park in the US was was big surf out in Arizona, and there's a whole movie made off of it. And it was really interesting. But the the way it ended up being is that the the model of just people paying to surf was we didn't happen there didn't work there. And I want to say in the late 90s could have been Mandalay Bay had a had built a wave pool that was supposed to be make waves that people can surf. They had some problems with that. So they just kind of decided not to surf there. And then Typhoon Lagoon was also produced for sort of capabilities of surfing and then that one was just kind of after hours. availability for surfing. And the waves were were really for entertaining. You know, hundreds of people in the otter not necessarily strictly for surfing,

Ryan Rosztoczy 48:22

right. I remember going to big surf and I remember the big wave, but it was always it was like, yeah, just hundreds of people and little tubes floating. I never even hit my mind that the idea even though it's called Big Surf and never hit my mind that the idea would be that would be a wave you could serve because it wasn't it was. Yeah, just like a big rip of water.

Doug Coors 48:44

Yeah, so. So it's been, you know, it's been out there forever. It's nothing new. But that's that was one of the things in my head. And I had, I was at a point in my career where I wasn't sure what I wanted to do. There. I had two ideas at the time. One was a drone company that would fly, whether it be you know, farms or even quarries or whatever, and be able to either compute volumes of things or look at plant health. Through its NVDI technology, which is which is the thing, right? Our golf course now uses that to recover money to fly over it and say where the sprinkler has maybe broken or not dispersing correctly and we do it you know, once a week and we can tell what's going on in our golf course just via drone technology. That's actually camera technology flown by a drone, but I had that that was the most promising to myself and my family at the time but that it kind of tied us in back into agriculture. With our You know, dependence on barley, and grains growing and having I guess partners in that space. And so it was pretty exciting. And that we had some issues with the company and some of the founders. And it was at a time where I really couldn't take that to the family for approval, because it was too messy. And the only other thing I had had done any work on as a syrup park, so quickly put together a feasibility study, had some people helped me with that and, and was able to get that approved to the family process. So I was off to my new career, building something that hadn't been built and over 50 years, I think, and it was completely different. Completely crazy. If had been scaled on the computer, but not necessarily in real life. And so there was a lot to learn as we went forward. But yeah, interestingly enough, yeah. Computing Technology is what made it all available.

Ryan Rosztoczy 51:11

Yes. Okay. So I'll get there in one sec. But what does? What does it look like for you getting to that point where you do a feasibility study, and then you actually get approval to work on it? Because we're talking about, like, pretty large effort. So probably a pretty decent amount of capital, you need to make this project happen. What does that process look like? Like? feasibility? Was that to make sure the technology would work? And then you also had to sort of come up with a business model idea around it? Or how do you get the approval to move forward?

Doug Coors 51:55

Correct. So you really have to do as much as you can to de risk. The risks that the whatever it is you're working on, right? And what the syrup Park is really difficult. Because there wasn't a surf park out there that was operating as a surf Park. So so we had to create business models, and we had to do all kinds of investigation on what kind of pricing and what kind of capacities were available and what was happening. And you know, we learned a lot from what we did at the same time. It was it was one of those things where, no matter which way we shook it, it was hard to see it that it wouldn't, wouldn't work. Too to, to have that. So. Yeah, have I learned a lot? Yes. But I also proud because the industry is started around the world, there's a lot of sort of parks now dedicated towards that. And there's several more being built as we speak.

Ryan Rosztoczy 53:03

So you so so you get the approval. And then, I mean, I would love to talk about the challenges that you encountered, because and how you sort of, like lead through them, because I just I think it's so important. I mean, it's like you build the park, I remember you would be going down to Texas working on the park. But you guys ended up having problems, was it with the wave? Or what, or like cleaning the park or there was some sort of like big issues that you guys ran into?

Doug Coors 53:40

There was a lot of big issues. For instance, well, the biggest problem I think we had is with getting the community to understand what it is we're doing. Well, and and that's where I think I I wished I had learned that lesson before going into it. But yeah, once we got the approval, we did the investigation of costs and and you know, had consultants or or people that that were close to help us with understanding the tire scope, and what was going on. The unique thing about surf Park is that we found all kinds of people that could engineer stuff for static water. So our basin, if you will was was lined very much like a mining pond. So it's contained by a special liner that is impervious. And so it could maintain, you know until they can clean it up. It was there's a lot of that going on in the world and so We were able to work with a liner company and a design company to figure out what all the forces were and everything that needed to happen to contain this water. At the end of the day, because the water, the forces are dynamic versus static, there was a lot missed. There was a lot of lack of understanding of what the true outcome was going to be. And so we had to, we had to pivot a lot on, on what we thought might happen versus what was actually happening. And it was it was complete problem solving, all day, every day on lots of fronts. Not only not only the liner, but the Yeah, the wave making equipment was, you know, worked. And there were certain things that were not working out, we found out about it, and it's just a complete learning curve.

Ryan Rosztoczy 56:01

And so when you're iterating, through problems, can you what would be like just a really concrete example with the liner, like what would go wrong.

Doug Coors 56:14

So the biggest thing that went wrong, first is we had, since you're making a wave, there are people there, a lot of people don't know how to make waves, either through government or through just playing in their backyard, the hard thing is stopping them. And if you can just tell that by coastal erosion and other things they do, they're very, in a way a destructive force. But that's what makes them so fun to ride to. And so you have, we had to figure out how to stop them. So our first attempt at stopping them work theoretically, but the design would allow, essentially a, an unseen portion of our liner system to fail, without us knowing it. And so we ended up having to rip that whole thing out and redo our liner system in order to contain, you know, the energy of the waves, and then water from getting underneath the liner. And that was part of the engineering fail that, you know, in a static world, this is perfectly fine in a dynamic world just doesn't work at all. And so

Ryan Rosztoczy 57:27

it's so crazy to me to hear that because like my, my brain just thinks, oh, yeah, like we understand physics and fluid dynamics. And we've engineered tons of crazy things. Of course, everyone knows exactly how a wave would behave. And that's so not sure. There's still a massive gap between the theory and the modeling, and then the real world impacts.

Doug Coors 57:50

There is and I think, if you take the world collectively, there's probably enough information through you know, all these different oceanographic Institute's and things like that. But they're applying it to soil erosion and other things, you know, on there, they make these fake reefs in order to protect harbors or whatever have you. So there's a lot of knowledge, but when it comes to surfing, and the experience of people being able to get in and out of the water safely, and being able to manage that aspect of it that didn't exist really at the time. Yeah, so it was a lot of trial and error there.

Ryan Rosztoczy 58:32

If you are omniscient, then you could have avoided the problem.

Doug Coors 58:38

If I was able to collect the world's knowledge on this stuff, probably would have been a direct success, but I didn't.

Ryan Rosztoczy 58:47

Okay, so So I remember talking with you, as you guys were experiencing a lot of these sorts of real, challenging, expensive reward problems. So it's surprising to me to hear you say that the community problem out of all that I remember at the time thinking, join our work on leave, I was really struggling, we were not seeing the growth we wanted. And I remember it just really helped put in perspective for me the scale of the issues that I was encountering. So I'm surprised to hear you say that the community understanding part was the biggest one what, what happened with that?

Doug Coors 59:25

Well, you know, we ended up being classified as from the health department as a pool. And we were essentially moving. I think it was close to 20,000 gallons per minute circulating around and in order to have the drainage and Lauren requirements and all that kind of stuff that pool has was really not feasible. For the project at nor, you know, wasn't going to be healthy for the people in, in our lagoon. And so it it caused kind of a stir amongst the health department and all the departments had Texas insurance departments and everybody was now kind of in an uproar when we ended up not partnering, but indirectly partnering with another group that was trying to do lagoon style construction in Texas, and we had to change the law in order to be operational. And the crazy thing is the in Texas, they only meet every two years. So we had very little time to get a bill passed and in the law allow us to have smaller restrictions on things like chlorine and, and turnover of our water and things like that.

Ryan Rosztoczy 1:01:01

Okay, couple of things really quick, because I've seen this attitude from a couple of you, and then one other like very successful businessman, Santa Ana, which is this idea that you encounter a problem. And that problem is, you're not allowed to do what you want. Like the United the government, the law, as it exists here says you cannot and there's a hard line there. A lot of people would think that's a hard line. But I have now heard, just two people talk about changing the law as a step in achieving that objective. And it is just a perspective altering thing to think about, it's also true. I mean, especially in innovation, when a society hasn't dealt with a certain product or technology problem before the laws are obviously not made to handle it. So of course it would have to happen, but it is perspective altering to hear you talk that way. So and I think good just to think about the boundaries that impede your success, or define the system you're innovating in. It's important to understand just how concrete those are physics is concrete laws. The power of a wave is a concrete, finite, unchangeable thing that you need to work around. Laws can be changed. Yes. Did were you did you guys get it done?

Doug Coors 1:02:38

We did. Yeah, we did. And we were able to operate, we operated for three seasons. And, boy, I mean, the the impact that it had on, on people all over, you know, where we were in Austin and, and even outside of that was was huge. And it was super fun to see. You know, I hadn't had that kind of collaboration or buy into a vision, since the 911. You know, build the bomb detector things where you have people from all walks of life, just excited to be part of something you know, happen again, and surfing and surfing is a little more sexy than than bomb detection. But same time it was it was really fun to have a second chance at having that. That kind of joy of everyone contributing and people enjoying the product and enjoying just being there. The atmosphere, having everyone from every employee to every customer, essentially having a great time and really enjoying this, this whole new world of surfing on land.

Ryan Rosztoczy 1:03:59

I mean, so that I think for me, that's going to be one of the the biggest takeaways even maybe for sure. I'm glad that you just said it is this idea of the importance of, of by buy in when you're tackling like true innovation or something very challenging. Like if you look back at the post 911 project, to scale up that supply chain and build these highly complex machines at far more than 10x. What you did in a year is an extremely challenging thing. But you had a bunch of buy in and clear vision behind it. Same thing with the wave Park. Yeah, I think I think that's just something that's really important, not take for granted, especially if what you're going to try and do is really innovative or really challenging.

Doug Coors 1:04:56

Absolutely. Yeah. Yeah, I mean, as much as you can You may think you can do it on your own, or you're you, you're the one that that has the vision and you're gonna make it happen, really to fix. You know, it's just like it takes a village to raise somebody, it takes a village to get something done. And especially a thing big. If any entrepreneurs out to do something big, it takes a lot. It takes a lot of people. It takes a lot of buy in from people. And yeah, it takes it takes this. We can't quit attitude. To the grave.

Ryan Rosztoczy 1:05:33

Definitely. Yeah. Yeah, for sure. And then actually, there's another, this just this stuck with me, to me, I think this got embedded in me from when you're working on the surf Park. This, like, can't quit attitude, taking it to the grave. I remember the first time I realized, I was like, Okay, well, here's Doug. He's already, you know, with a lot of his endeavors, hugely successful. And he is going through these immense challenges on a daily basis. And my brain was just like, Oh, if you want to have a life of entrepreneurship, then you have to get comfortable with the fact that that will be your life. Like there is no, there's no like, Oh, you did it. And now everything just works smoothly. From that point on. There's, it is just something that you have to sort of accept in I mean, for me, sounds like for you to more than accept to be like, yeah, lean into it like that is appealing. That sounds exciting and worthwhile.

Doug Coors 1:06:31

Yeah, I think, you know, when you're up to something big, whatever's in your way shows up. It's gonna happen. It just happens. It just never is smooth. And I think if you talk to any entrepreneur, it's never just, oh, yeah, we created this and got it produced and got it marketed and got it distributed. And that was all fine. And there wasn't any hiccups or any problems or any roadblocks, or, you know, it's just, that's the nature of it.

Ryan Rosztoczy 1:07:01

Yeah. So do you have, I don't expect you to, but we've been talking a lot about technology problems, or the role of solving those plays in innovation and business people problems, like societal system problems. Do you have any kind of framework or intuition now when you go to into a new endeavor like with, is it Adel, am I saying that right? Dell? Yeah, you're gonna be dealt with like? These are like, do those experiences derive your focus? I guess, because there's a lot of places you can focus when you take on something new. How do you think about it is pretty new. Does it start with people? Does it start with? Yeah, I'm just kind of curious.

Doug Coors 1:07:59

Yeah, people is the foundation. And that's, that's where it all starts and with with golf, it's, it's the same and probably ironically, golf is one of the most patented difficult places to play and innovation. And it's, it's, but at the same time, the it's a big there's a big horizon for the sport right now. There's been so much innovation in golf, and in the last 100 200 years, however long it's been. That's, it's really it's fun. In a way there's, there's tons of opportunity, but tons of landmines as well. And I guess that's, I just sign up for it. And we're tackling it head on, and we're seeing where we're going. But it is about people, you know, if some great people and we were it's a fun little company is nothing as big as you know, the surf Park stuff or some of the other medical and sensor projects and other things I've done. So it's kind of fun to have just a small group of people that are really wanting to to innovate in this space. It's a lot of fun.

Ryan Rosztoczy 1:09:23

I love it. Okay, real quick, and now we're just I'm just past time. How are you do like five minutes? Yeah,

Doug Coors 1:09:30

I can take five minutes for sure. Yeah. Okay, cool.

Ryan Rosztoczy 1:09:32

So there's one there's one other thing two other things I want to just touch on really quick. Okay. And maybe just last last sort of topics to wrap things up. One is that just to like be clear about things when you went into the surf park, you are not the world's foremost expert on generating manmade waves and when you started with, you know, you were not a expert in the golf business, so when you're tackling these new ventures, you're essentially having to upskill and learn a ton really fast. It's not like you had 10 years of experience in it. So I'm curious like, and I think it's really inspiring, it's inspiring to like, see that you can do that. Do you have any tips for it? Like, how do you go about that?

Doug Coors 1:10:27

comes down to the people again, right? Yeah, I had to find people that, that could see the vision, but also have bring some expertise. All right, so I had, I had a gentleman who was my chief finance, Chief Financial Officer, come alongside me, and he had spent his life in real estate development. So I had somebody with big expertise in real estate development, in terms of permitting and, and construction and, and all that stuff. That was great. You know, and we had our partner in Wave garden, who had a lot of expertise, you know, creating waves, and that was a group that I saw on on the article. And then, you know, as we went forward, we just tried to fill gaps, a lot of engineers, a lot of civil engineering goes into that. And, you know, we just kind of put piece by piece by piece in place in order to secure everything. And then when we ran into problems, you know, it's first time I've ever had to hire a lobbyist. Yeah, and, and then, and then the, yeah, the whole legal thing. Before that was, was having gone into it. Really kind of naive. And in terms of the working with, with the City of Austin, or the health department, and all that stuff, went into a blind got into a little bit of trouble. And, you know, found a great law firm that had expertise and a lot of context and knowledge and, you know, guided us through resolution to even to what needed to be in the law that we had to change. So, yeah, just it's a lot of help. And unfortunately, it's expense, as well. So you just have to be able to manage through that.

Ryan Rosztoczy 1:12:39

It's just I really wanted to hear your perspective on that. Not all technical founders have this problem. But I think it's just, we tend to be able to more I think, and it's just really important to remember that, like when you're building a new venture, you're building a company, not just a technology, and that you build companies that people so really cool to hear how you how you do that, and how you tackle those problems.

Doug Coors 1:13:05

Yeah, you really always I mean, to me, the big thing is, you always have a network of people, no matter what you're working on, whether it's your family, or whether it's your friends or whatever, but you need that support. And so what, however you want to expand that out into your company or into the community. And that's, you know, I didn't, when I went into Austin, that was a new town, and I didn't know a lot of people and I hadn't created that community support, was able to do that. Through some very special friends and contacts, and, you know, a lot of work on a lot of people's behalf. So, you know, it's not possible without that,

Ryan Rosztoczy 1:13:48

yeah. Support Network. I love it. I mean, in that, that could be it. So one thing that I have been asking everybody is like, Fine, if, if you have something that comes to mind or not, but I'm I'm curious, like, if you had and it can be that if you have any, like advice that you would give to somebody who's thinking about tackling a new venture, or maybe just started? Does anything come to mind for what you would tell them?

Doug Coors 1:14:20

I would say just that you need a support network. And you need financial support, you need emotional support, to go tackle this, you need a lot of support of your vision, you know, from your team and from either consultants or other advisors that you may grab. Yeah, it's, you know, to execute, you just need that. You just need that whole network and where something's missing, you won't be able to execute and you'll have to go figure out how to solve that

Ryan Rosztoczy 1:14:53

thing. I love it. It's I think it's super easy to look at people who have had a lot of success. and think, oh, that they're successful, you know, they must be a highly unique individual or that must have been like they got lucky and it was an easy path for them. And pretty much that is never the case. And to get to that point you really having that network I love that you included both like financial and emotional support in there is is sort of a big part of the puzzle. So I love that. That's huge.

Doug Coors 1:15:30

Yeah, that's, that's what it takes. That's, that's me. Yeah. Love it.

Ryan Rosztoczy 1:15:36

Well, thanks for the time today. That was That was awesome. Again, thank you so much for coming on.

Doug Coors 1:15:41

Well, thank you. Ryan's been pleasure. Really enjoyed it. It's been fun walking through the past.

Ryan Rosztoczy 1:15:47

And that's a wrap. I hope you enjoyed the chat with Doug. Some pretty epic stories in there. And I'll see you again next time.

View Details

Welcome to another episode of the technical founder, the show where I meet with engineering founders and we deconstruct and demystify the science and art of building technology businesses. My guest today is Mike Flanigan. Mike is the CEO of SeaSats - an autonomous aquatic drone company that manufactures drones used for scientific, commercial, and military use. When we first met, Mike was in Bahrain for the Navy's Digital Horizon event. In addition to a wonderful origin story and some technical topics, in this episode we also cover some serious territory specific to fundraising. SeaSats has raised money through accelerators, rolling SAFEs and a $10M corporate round with L3 Harris. I had a blast talking with Mike and cannot wait to see what the SeaSats team accomplishes in the coming years!

‎The Technical Founder: Mike Flanigan [CEO, SeaSats]: Accelerators, Rolling SAFEs and Corporate Rounds on Apple Podcasts‎Show The Technical Founder, Ep Mike Flanigan [CEO, SeaSats]: Accelerators, Rolling SAFEs and Corporate Rounds - Feb 9, 2023Apple PodcastsMike Flanigan [CEO, SeaSats]: Accelerators, Rolling SAFEs and Corporate Rounds0:00/71:151×Highlights[10:00] The beginning of autonomous boats

[35:00] Techstars

[48:00] Rolling SAFEs

[55:00] Corporate rounds

Transcript (Provided by Otter.AI)SUMMARY KEYWORDS

people, company, accelerator, money, techstars, big, autonomous, talking, customer, boat, business, project, engineering, ocean, build, product, bit, super, investors, sensor

SPEAKERS

Announcer, Ryan Rosztoczy, Mike Flanigan

Announcer 00:12

Welcome to the technical founder

Ryan Rosztoczy 00:26

Hello again, this is your host Ryan Rosztoczy. Welcome to another episode of the technical founder, the show where I meet with tech founders to deconstruct and demystify the science and art of building technology businesses. My guest today is Mike Flanagan, Mike's the CEO of sea sets, an autonomous aquatic drone company that manufactures drones used for scientific, commercial and military use. If autonomous ocean drones aren't enough for you, in this episode, we cover some serious territory specific to fundraising. CSAT has raised money through accelerators, rolling safes, and a $10 million corporate round with L three, Harris. Without further ado, let's hop in. Here. Hey, awesome to have you on the show.

Mike Flanigan 01:16

Thanks. Thanks. Yeah. Glad glad to be on here. Yeah, kicking off.

Ryan Rosztoczy 01:21

So one thing I just wanted to mention at the beginning, we can give some context for the audience. But last time I talked to you, you you were in Bahrain.

Mike Flanigan 01:31

Yeah, that. Yeah, man. It is. It's funny that that is like a whole, like whole another roller feels like so much has happened with like Christmas and the holidays in between. But yeah, that was last when we first assumed I was in a hotel or mountain Bahrain.

Ryan Rosztoczy 01:46

Yeah. So what were you there for?

Mike Flanigan 01:50

So out there for the Navy was running an exercise? That's like, yeah, you can look it up online. It's called Digital horizon. And they were hosting an event where they're really trying to up their game and unmanned systems and robotics and AI. So they invented a whole bunch of different it was like 10, to 15, different robotics, all in the maritime space. So both companies, one or two drones, aerial vehicles, and then some AI companies ought to go out there and help them really kind of push forward, push further use of those tools. And like their main focus for that was maritime domain awareness, which, to the commercial world is very similar to like the illegal unregulated fishing kind of mission set. Hmm.

Ryan Rosztoczy 02:35

Okay. Okay. So trying to basically just track what's going on in the, in the oceans out there, essentially,

Mike Flanigan 02:43

exactly, which makes sense for robotics, if you're always trying to take up the stuff that I would say, just like the 70% time, it's the time where humans are out there waiting. And that is just as expensive as the other stuff and way more boring. And, essentially, you're cutting out all this cost. So like for coastguard ships, or for the Navy, or for a lot of stuff, you're just out there patrolling in the ocean, and you're keeping all these humans, you know, fed happy, healthy, safe. In steel boats. It's pretty expensive. It's pretty difficult, and you're keeping people away from their families. So a much better model kind of of the future is like, hey, you've got all these drones out there. They're kind of seeing what's going on what's normal. And then if something bad happens, it's like, hey, some, either someone's fishing where they shouldn't be or some boat was traveling into someone's waters, where they shouldn't be anything that yeah, there's a lot going on in the world of people getting another waterways and creating global tension. So if you can, that was their hope. It's like, Hey, can we have more patrols understand what's happening in these water waterways? Yeah, take advantage of droughts.

Ryan Rosztoczy 03:50

That is a mind blowing thing to think about this, like the 70% time yeah, what during the sort of boring, uneventful periods, you still need something terrifying. It's boring and uneventful. Yeah, I love that.

Mike Flanigan 04:06

Yeah, it's like the you know, I can like Hollywood like bank robbery movies. I'm sure there's a scene like this in Ocean's 11 or something. When like, there's a bank of 20 CCTV cameras and some security guard is like supposed to be watching them all. And then you see from the like, over the shoulder video, you see like in the top guy go through, but then it like cuts to the fake video feed. It's like, Oh, if he'd been looking there who would have known? And it's like, okay, that's the case for like, why you need you know, AI running, like on 20 different video streams all at once. Just like it doesn't get tired. It doesn't need to take a sip of coffee. It doesn't need to go to the bathroom.

Ryan Rosztoczy 04:41

I love it. Yeah, he took a bite of his doughnut right when George Clooney walks in the door. I don't want to go too deep here, but just out of curiosity, how much doubt all of the different focuses you just talked about robotics AI? What If you guys focus, do you have one or you like an integrated platform? What? What is CSAT?

Mike Flanigan 05:05

Good question. So for us, really, we focus on being a platform. So we try to carry mature sensors out into the ocean, we will love working with sensor companies that already have because that means that hit customers exist, like, and when I say sensor companies, I'm talking about, like a water quality sensor like a CTD, or ICA these multiparameter songs that measure like turbidity, or acidity pH like all these different parameters, and is basically Hey, we can go carry that out into the ocean, or like for the Navy, it's like an AI s node, something as simple as that. It's just an antenna. It's collecting traffic on who's in the area who's doing what cameras, basically any kind of mature existing sensor, we can stick those on use this as a truck to carry it out into the ocean and put it where it needs to be.

Ryan Rosztoczy 05:56

Okay, awesome. And so you have the drone, and then I assume some software that's driving it, essentially, or?

Mike Flanigan 06:03

Yeah, that's a great. So I guess the first thing I said was like, Okay, how do you give a simple answer, it's like, a truck. That's the difficult answer, the more encompassing answer that also captures the second bit of our strategy is we do do a bit of everything. The reason we do that is because customers really like particularly in our field, need vertically integrated solutions that, hey, I want something that solves my problem. They're like, Oh, I don't want another there. Because it's so easy. There's so many different sensors that they can go to and be like, Oh, I can buy this sensor. And I was like, how do you get it? They're like, Okay, now you buy some other thing. And then you need to put them together. And then it's like, who provides the data? It's like, oh, well, you know, go get an account with iridium, the satellite provider, and then great, now you've got to go into your email. Okay, cool. Now I need a data scientist or someone to create a spreadsheet, well, a spreadsheet kind of sucks, can't we have something nice. And so for us, it's really important, like, we always try to do things end to end. So we do. We do both side software, we do communications, we do. Like front end software, like database stuff, we do kind of a dizzying amount, like we do way too wide of a tech stack. But at the end of the day, when it works, like when we've finished a payload integration, when someone's something's like in our run of the mill, library, like earlier today, we had a customer that was like looking to buy some vehicles and go do a mission. And we're okay, we can't, you know, do production timelines, we can't get your new vehicle set. But you can learn this other on we've got another one near you. And you we've already run that pillar that you want to do, like, can you just plug it in? someone's like, how long is that gonna take to integrate some sort of like, man, really, it's like, maybe two hours, like, you know, it's like, screws and cables that you plug in. Like, it's pretty straightforward. We've done it before. So that is kind of like the Grail when it's like, plug and play fast. super straightforward.

Ryan Rosztoczy 07:50

Yeah. So it's like, you've got this platform you can accomplish, like, whatever objectives your clients need to. And then with everything around it, you're sort of building like the user interface, like making sure that clients can use it to accomplish what they need to.

Mike Flanigan 08:05

Yeah, that's like, our iPhones, like simple like, definitely not. That's a crazy complicated. So much engineering on iPhone. But is it simple for user? Like, yeah, totally. It's like super intuitive. And so that's, it's like, okay, which striving towards that sort of thing. I have a lot of complexity hidden away under there.

Ryan Rosztoczy 08:25

Yeah. Well, I'm looking at I'm actually looking at the picture from the one of the articles, I've seen a few that came out from that digital horizon. And you guys totally scored, because right in the front, it's the sea SATs drone, and then it's all the other drones like around it.

Mike Flanigan 08:40

Thankfully, I'm lucky with that quarter shot.

Ryan Rosztoczy 08:42

Nailed it. Sure. I'm sure it was luck. I mean, it looks extremely simple. It's like a very small, almost like a canoe with solar panels on top and a little motor. Compared to other things in there. At least. Yeah, very sleek. So love a focus on that.

Mike Flanigan 09:01

Thanks. Yeah, low. That was definitely a distinguisher. I mean, I guess, to clarify, or maybe to like to, like, take away first I don't know if that's good strategy. But there's a lot of vehicles out there that could do tons of missions, super capable platforms doing crazy stuff. But a lot of those are just like, slightly apples to oranges, where it's like, okay, you need like order a huge crane. You need a crew of like eight people to set that thing up. That thing cost many millions of dollars like ours, right? Hey, this is like, you know, orders of magnitude, maybe not orders, but one order of magnitude and a half or so cheaper than some of this. And it's like, pretty much you have one person, maybe like two is convenient, but like Man, I've gotten run loads of missions by myself. So, yeah, small and low Logistics is what we go after. Yeah, I

Ryan Rosztoczy 09:49

love it. Okay, well, we'll come back to some some interesting technical topics and we'll go deeper there. But before we do, I would like to just go back into your background and Little bit talk about how she sets came to be how you ended up there. I think it's an awesome story. So maybe you could just start from what you see as the beginning. And we could go from there.

Mike Flanigan 10:12

Thanks. Yeah. Well, thanks. Thanks for the comment of it being a core story. I agree. It's, I think I feel pretty lucky. Like, man, it's been been a cool path. I mean, if I was to go back far enough, it's really like tree houses and catapults and like having parents that are like willing to put up with that sort of mayhem. I think my dad always kind of joked where he was like, I don't, you know, they're like, normal, stiff parents and like preventing us from like, going and getting in trouble with like, drugs or drinking. But if it was like, Oh, you want to go to Home Depot, like, Oh, you want some two by fours? Or you want to like, play around in the dirt pit? They're super hands off. They're like, Yeah, go for it. Like, we know nothing about that. But have fun. Drill. Sure. Like, it was like pretty, pretty, very supporting parents on that front. But that, I mean, probably the first thing that really kicked this stuff off was a project back in for me, it was late high school and early college for some of the guys that was working with us more. Most of them are in college, the oldest guy Max was like, probably, I think just finishing college, a project that became known as scout or Scout transatlantic. And that was basically an early autonomous boat, not so different from our current ones. And the goal was to grow across the Atlantic. So it's like a robotic boat solar panels, supposed to go and drive itself across the Atlantic Ocean.

Ryan Rosztoczy 11:30

While you're in high school, and you guys did that.

Mike Flanigan 11:33

Yeah, I was. I was definitely the like, whippersnapper of the crew. Yeah. I was like, younger and was like, Hey, guys, like, you know, this is kind of like, my older brother and Max and some guys that are a little bit older than men. We all knew each other growing up, and I was like best friends, Dylan, but who is kind of the brain. his brainchild, I guess was what it was, it's like he had done first robotics. And Max's had an internship, I think in Spain or summer job in Spain, his dad was working internationally. And so they were joking in Max's garage about a message in a bottle. There's like a smart message in the bottle. Like, you know, the odds of the messenger bot are really low. And then it got turned into like an autonomous boat. And I was like, Oh, that'll be done. Don't think I could do that. Like, I think the initial thought was like, it'd be like, maybe a two month project, like a summer project. And it turned into like a two and a half year project. And like a lot of people and a lot of a lot of stuff, multiple launch attempts. An enormous amount of warning. Yeah, that that probably do it. Life changing.

Ryan Rosztoczy 12:34

Did you get the message across the water?

Mike Flanigan 12:37

It didn't make it unfortunately, they made it It made it about admitted 1300 miles, I think was the final count. And it was out there for like two and a half. Yeah. But it was cool. It stirred up a ton of excitement because it had a live tracking page that would update every 20 minutes. And so all these people were following it and cheering it on. And it was it was like a whole hype thing about this boat just venturing out there by itself in the ocean. Yeah. Oh, cool.

Ryan Rosztoczy 13:05

It's a shame that we probably won't be able to do that with any of the Navy uses.

Mike Flanigan 13:10

Well, yeah, now the navy boats, boats for ourselves and for commercial purposes, too. And we definitely have ocean crossings on our near horizon. Just because there's so much fun. It's like, yeah, we're basically gonna repeat Skyrim Okay, here's the professional take at it.

Ryan Rosztoczy 13:25

I've got this image in my mind of you're like the youngest one on the team. And really, your autonomous transatlantic boat is a canoe and you're you're under a solar panel, and you pop out once away from Cheyenne.

Mike Flanigan 13:39

We make a lot of jokes about how, yeah, about how it'd be so much easier just to have a person. And can we just do this a person is like, oh, yeah, that would really solve that problem pretty fast. Like people are so incredibly skilled.

Ryan Rosztoczy 13:54

Man, that's great. Awesome. I love it. So I mean, you get into I mean, even Wow, it's not like even gotten to robotics. It's like you actually get into autonomous ocean vehicles at that age.

Mike Flanigan 14:06

Yeah. And it was before. I mean, so that was back. I think the project started in 2007. And then launched eventually, the final launch in 2012. Maybe. And in that time, like in for a couple years after, if you Googled autonomous boat scout was like the number one search result. And that wasn't like doing SEO optimization. I was like, No, we didn't. We didn't know anything about that. But it just was like the only autonomous boat that had news coverage that kind of exists. I'm sure like, Navy was doing DARPA style projects hidden away somewhere. But kind of this field was starting around that time. Like there's this revolutionary change in technology of like, satellite communications, getting cheaper circuit boards, batteries, like everything was changing, and becoming are suddenly a lot of people realize, like, Hey, this is possible. I mean, 2010 era, I think liquid robotics. The Wave Glider was founded in 2009. They were bought Boeing in 2016, that's kind of a foundational product in this space sale drone. I forget if they're 2011 or 2010. But they were founded right around then they also are probably the biggest most public one in the space. Now. They're San Francisco company that's raised heaps and heaps of money. They make these big orange sailboats that are autonomous. Yeah, this is it's kind of an exciting, exciting that we got into it so early. And it's just the right time.

Ryan Rosztoczy 15:27

One timing. I mean, yeah, that's such an it's such an interesting thing. Have you I'm reading The Rise and Fall of American growth right now. It's a really cool book, like pretty dense, but goes through the history 1800s 1900s, and sort of makes a case for why and how American growth happened and what will happen in the future. But one thing that it just makes super clear, what you're alluding to, which I have always taken for granted, is just how big human impact the price of technology decreasing over time matters. Like the like the difference between the invention in the car and the actual adoption of the car, right, like, decades, but just just fascinating how it's actually like, do these things become usable for non mission critical one off uses, like I think the Telegraph's a great example and never got cheap enough to become widely adopted. But so for you guys to come into this era, when all this smart sensors, the technology, it's all becoming doable. Yeah, amazing.

Mike Flanigan 16:32

And it changes. I mean, you see it, the rate of change then accelerates, because then the use case like human ingenuity takes off, because now suddenly, it's not just in a couple of labs where the cost of failure is high. It's like, again, this technology democratized now into the hands of hundreds of 1000s or millions of people. And then suddenly, people are doing crazy things with it that the inventors had no idea. And yeah, things get really exciting.

Ryan Rosztoczy 16:58

Yeah, well, I mean, yeah, seriously, I even just look at just you guys like what you're doing. It's not like you're just working with the Navy on projects, right? Like, you're out there measuring ocean helping you. I mean, he tells me all the stuff. Oh, my gosh, I

Mike Flanigan 17:11

mean, we started the very way I got started with this project, besides knowing everyone, and like, having worked on a tajbakhsh before, but when CSAT was kind of spinning up in its earliest days, actually wasn't involved in the first few months. It was like, I'd worked with the guys on this like side engineering shop that was going on, but really, like I worked in federally, but wasn't by name associated with it. And the first thing I did was I started doing some customer discovery calls for them, because I was taking a class that was like, the only entrepreneurship class I've taken. And I was like, do customer discovery calls. I was like, Okay, I'm doing this. I was like, Hey, guys, I think like, how do you feel if I do this for you guys, too, for the Scout project? Sounds like no one's doing this. Yeah, sure. Okay, go for it. Like, no wonder that didn't shed their chair, spend your time, like calling people to everyone. But it was fascinating. I was calling the people that were available. The phone numbers that were available, were all the scientific groups. It was like the people who had science articles about using Wave gliders to go do science missions. And so they're the ones that email and call and then get on phone calls with. And one called just this like price of technology thing. There's a guy who's talking to who is like, yeah, this would be awesome. Like, we've tried to build these ourselves. Like we were, they had bought these other vehicles that are in the space. And here's like, you know, like, this is awesome. But frankly, like, I don't, I don't want to be discouraging, but I just don't think there's a very big market for it. But besides like us, and maybe a couple others, like there's just not that many people that need these things. And I was like, oh, yeah, okay. And he was like, but like, how much would you sell it for? Like, I don't know, retarding like 70k. And he was like, oh, oh, wow. Okay, that would be game changing. He was like, then actually, all these other smaller like these, you know, like all these, like, organizations that are slightly smarter than us. He's like, That's within all their budgets. So now, like, suddenly, there's like 10 times more users, just by dropping the price from like, 250k, which is like, kind of comparable product before the 70k. Like, cut the price in half, or, you know, yeah, more. And then like, oh, the use case, like in the span of a conversation, like from one line to the next. He was like, oh, man, that's sort of a game changing. But that's super exciting.

Ryan Rosztoczy 19:23

I love that. And that's, it's the kind of stuff you only get from customer research, like and talking to people. And it's a it's a little bit serendipitous, right, like you got to be talking to somebody and that hits their mind and they bring it up and suddenly it's a big unlock. There's an example. Shoot, I can't remember the company or product, but this company was selling their product and they were trying to sell it through wedding registries. They thought it'd be this huge unlock for them. It just made perfect sense. It was the exact right market and they get in all the channels and get it going they get nothing. Instead of give going up and being like, Oh, this wasn't the right channel for us. They just started talking with everybody. Turns out that nobody's looking to spend $400 in their wedding registry gift, I think whatever. Let's say it's 150. I don't know what they realize if they gave like a half offering at 150, then it blew up. It was that they, they were just a little bit priced out of that channel.

Mike Flanigan 20:21

Yeah, and that's in that can be the type of thing exactly. It's like, Man price does matter. And if you're like, in slightly the wrong spot, then people can totally put like your product in like, a different use case or treat it differently. It's yeah, it's pretty fascinating. Yeah.

Ryan Rosztoczy 20:37

Yeah, super cool. Okay, so. So you join in, you start doing this because I love that so much. By the way, I love that. What was the class? Do you remember that

Mike Flanigan 20:47

is I love this class is D for D, or designing for defense or hacking for defense, which is a pretty cool program that you should like, Man, I saw on a wall as in a grad program, I saw a poster on the wall. I was trying to figure out my last classes from last semester. And I was like, oh, that sounds like interesting. Like is kind of like entrepreneurship, technical, mission driven. There's all this stuff. And so I went there having like a, the head of the class, I was giving a talk on it to like do recruiting to get people to sign up in elective class. I went and listened to this guy, Lloyd thrall. And oh, man, I listened to him talk for 30 minutes. I was like, That guy is super sharp, super inspiring to listen to as like, I want to be in his class. Like, I want to take a class where I get to be around him. And I was not at all disappointed every time he would get up. I mean, he could say like, Hey, we need to sharpen our pencils. It would be the most inspiring thing in the world. Except the reality was it wasn't just you know, he was always he just was thoughtful, cared about what he was doing. He Yeah, he's, he's a great leader and a great teacher.

Ryan Rosztoczy 21:54

It sounds to me like, is this the right word for that? Like, did he have gravitas?

Mike Flanigan 21:58

Yeah. Gravatar. He made ship matter, which I actually that's like something. Yeah, that on a personal level, I really like I've got this is a total tangent. I've got a favorite movie, which is Princess Mononoke. A, it's like by this this filmmaker, Miyazaki. It's, it's a Japanese movie. Yeah.

Ryan Rosztoczy 22:18

Have you heard of it? Or heard of him? Yeah.

Mike Flanigan 22:21

It's yeah, they're great. They've got a bit of a cult following. But to make a long story short, it's a very like, almost like ancient Greek mythology. Like when stories were very simple, and like, stuff mattered. And now we've gotten into like, much more complex realm of like storytelling, like every hero is really an antihero, and everybody is much more relatable. And it's like, okay, the good guy is actually a little bad. And it's like, it's very interesting, engaging television. But I also am kind of bummed by where I'm like, Man should be like, this is the goal, right? This is, you know, try attempts to explain the world or something. So, yeah, I'm a sucker for some gravitas.

Ryan Rosztoczy 23:05

It is. Not that I'm endorsing the views in it. But I've been watching that. Ancient Apocalypse documentary Netflix, just like about in ancient humanity, pre historical humanity. And one of the things to that point that's just so interesting to think about is, when we didn't have a lot of understanding around how the world worked. The smallest things had really big impactful imprints in our mind. Like there was so much extrapolation going on, to your point of these stories being just simple and meaningful. I can see how they'd be so it's really attractive to see that because, yeah, our brains work that way for most of humanity.

Mike Flanigan 23:53

Yeah. And it's like, okay, this is yeah, appreciating some little things and, and maybe putting too much meaning as to things. Yeah, it's in stuff that we're wrong, but it's like, okay, cool. It's there's still some some emphasis behind things, just totally,

Ryan Rosztoczy 24:07

totally, maybe one that we have aI handle the minutiae of how the actual world works. We can get back to that.

Mike Flanigan 24:16

Yeah, the utopia just by being like a Yeah, technologist and like, optimist and a lot of things. I guess, I'm not like an optimist. And well, I guess I am an optimist, but I don't know. Gosh, there's the question where we're going is very tricky.

Ryan Rosztoczy 24:33

Yeah, yes.

Mike Flanigan 24:35

But to wrap up on that one class, actually, just in terms of like the beginning story, like wow, that class for me actually was quite insightful because it was all about dual use technologies, like lean entrepreneurship. I spend a lot of time kind of like dabbling entrepreneurship and little projects and working with people in the past but yeah, it was a good it was a good class and going from like technical and then being like really emphasizing like calling people One talking to customers and understanding a problem really deeply. So it just had a ton of. And not to mention, I guess the last thing was this whole, like hacking for defense or designing for defense was specifically, like, I went to Google. And after listening to that first kind of recruiting lecture, I went to Google the program's history. And it's only a couple of years old. And I was like, Oh, wow, this is really cool. It was all about the emphasis that, like American tech, like back in kind of the Vietnam era, like really, like we got pretty disillusioned with, like the government and kind of far flung wars that we shouldn't be involved in, very rightly so. But then, that a modern day bit of a revival, where it's like, hey, now we've got like, all of our best and brightest talent going to work at like Twitter, and Facebook. And like, you know, I love those platforms, too. But really, like, it's like mining, the latest metadata about, like, where you drink your coffee, like that exciting or meaningful? And it's like, maybe not like, Oh, can we get more screentime out of, you know, my younger brother, like, Ha, bomber. And so the basically, the hypothesis in forming that class, I was like, hey, like, we can probably get some people to work on more meaningful projects, if we like, you know, get them back and tied into national security and into kind of, yeah, a bigger mission. I love it. Yeah, it was, it was really good. It resonated with me and our stuff, like I was familiar, this industry, and then just is this dual use nature of pay, you're doing science work, you're doing commercial mapping work for offshore wind farms, and you're also doing, like, these products are also going to the Navy. So understanding how the government works, and how government sales works, all that stuff was really important. And that class definitely opened my eyes and like, how the government functions and how the military functions. And yeah, it was very educational.

Ryan Rosztoczy 26:46

Well, and just to say on that topic of, you know, those early customer calls. I mean, I'm at my second startup, right now, I joined after they got a seed round, they already had their initial, I would say, like customer discovery session, the first startup I joined was same thing. They had essentially raised money and decided to build a product. So in both cases, I came in after the initial idea session, only through this podcast have I started to realize how tactical that phase can be. And how a lot of people's first biggest mistake is not realizing that you need to essentially be boots on the ground talking to people. So for you to just get that experience in college right off the bat and go do that. I mean, I love it. That's awesome.

Mike Flanigan 27:34

Yeah, definitely, like, any time with customers is the best feedback possible.

Ryan Rosztoczy 27:39

Yeah. Cool. Okay. So you start. Kind of have your own initiative helping see sets out with business development.

Mike Flanigan 27:51

Yeah. Well, I was looking for something to do, I guess. I mean, like I had done, I guess there was a chapter that I skipped in between here, which is between when the Scout project ended, maybe a year or two later, I forget exactly the number. Like I was still in school, my brother had gone off and done a job, a couple of people have gone and gotten jobs. Dylan, the guy who I said was his mastermind, like when I'm like my best friends growing up. He was had graduated as a summertime. And he was doing freelance engineering, and frankly, killing it. He was loving life. We're doing a lot of different stuff. Anyways, ocean arrow, this was a company that was founding an autonomous boat project. They Googled, like I said, Scott was the first you know, searchers on Google, they Googled autonomous boat. Okay, we need to engineers Googled someone maybe told them about the project, or they Googled science, but found the scale project, when did the team page saw doing call them up? In our case, we want to fly out to San Diego, and, you know, give you a job to help us start this Thomas Boat Company. So he flew out. Basically, I was like, yep, sounds great, sunny weather, you know, like, good. Next chapter. So he was working at ocean air and he works there for like five or six years. I wouldn't work there only for a year. But yeah, that was before. I went back to grad school in computer science. And that, like in the right when I was wrapping up grad school is when I took that entrepreneurship class in when a couple years after Dylan had left oceanaire. And so there's this kind of revival where, like, yeah, I guess actually, a lot of the core Scout crew was now living in San Diego, like various jobs have brought them out here. They're working out here. They've been doing their own freelance engineering thing. That's called kuruva. They're doing composite work for people, structural engineering elements, doing some electronic designers. You know, it's just like engineering contract shop. They're doing all sorts of neat, cool projects. But there's always kind of a push for a product is like, oh, man, it's if you're, you know, if you're really good at product design, and you're doing great contracting, a lot of contract shops, if you go talk to him, they always kind of have like, a little inkling are very common to say like, oh, yeah, but we kind of want a product as your own thing. because then we can stop just spinning the wheels for everyone else and make one of our own Suite products. And so that was very much here. And that's when they started kind of scratching out there. Hey, what about we take another shot at, like, commercializing these autonomous boats, like, we did it for fun is kids, there was no people like wanted to turn into a business. And I'm like, people called up and asked us about selling scouts. At the time, the technologies are mature, we were immature, we're mature enough to talk to each other and be like, that'd be a bad idea. We kill each other, this business won't succeed. Like there's no way it's ready. You know, after five, six years doing it professionally for jobs and doing being like the leader, electronics engineer, and being a product manager oceanaire on really seeing customer use cases, a company go through boom and bust of raising money or running out of money. Lots of drama and technology hurdles. But yeah, I mean, so oceanaire was a huge foundational experience. And then post oceanarium is when, like this couva contracting shop was going on. And then sometime after that, it's kind of like, hey, like, couldn't we take another stab? Like, it seems like all the products in this market are a little too complex cost a little bit too much. Seems like there's a gap that like we know how to fill. And that's when they kind of started on the, like, technical building of a prototype. And that's the phase like they've started on the technical phase. And I was like, Hey, guys, seems like you could use some BD help, like calling some people. And they're like, Yeah, sure, go for it. Whatever happens happens. And yeah, that and I did that. Because yeah, it's getting close to graduating, I was kind of doing some contracting stuff on the side. Like when I left oceanaire, I started contracting, doing like electronics and software people freelance, similar to this career really quick,

Ryan Rosztoczy 31:48

just because I've been i I'm gonna keep going with this because I have, I do want to talk about this, but I just keep thinking my head I have never heard until you and it's like, your whole crew is doing this. I've never heard of just like freelance engineers just building cool shit. How do you get into a work like that? Like, how do you end up as a engineering contractor?

Mike Flanigan 32:11

Um, you know, so there's a couple of places like, I guess. So one, if you're gonna Google like, are places like professional versions of what we're doing, and we're professional, but we're just like, a couple of days in a shop. But there's like, a corn engineering in Boston, DMC info or DMC engineering, like there's all these engineering design shops that, you know, this happens a lot where companies raise a bunch of money. And then they like, need to do something like, Oh, we don't have an app, or we don't have this, or we don't have that. And then they basically go to like an engineering services company, to start helping them. Yep. The way that we started, I would say, there were two different ways. Like for me, I wanted to quit my job. And I was like, I need to do something else. And it was like, started job hunting. And then I also started just doing contracting on the side through Upwork. Which, okay, yeah, doesn't make you loads of money. But like, man, it's cool. You can get programming gigs on there. I did electronics stuff through there and prototyping, they're like, cool, you're out enough. People are looking for funny things. And if you communicate well and do the job, and it's just a great experience, like doing those little jobs and doing them for money are going to change because you almost always end up like ghosting hours things go south. projects aren't profitable. You're like, Man, I'm not good money for doing really high end work. Because I didn't know how to project like budget or estimate.

Ryan Rosztoczy 33:29

Hunters that okay, cool. Okay, so

Mike Flanigan 33:34

if I actually can just stick in one other surgery, I love telling my older brother's story, the way the crew started. He was working in naval architecture company that did design and engineering. And he was kind of butting heads with management because he was like, hey, like, I don't think you guys he like, basically kind of disagreed with how the sales process was going down. And it was like, thought that the engineering side of the business was getting a little bit mishandled. They eventually laid off the whole engineering team, they just asked the engineering team like, you know, we're just gonna be a design firm, like we'll have someone else engineer. The day after he got laid off one of his old, one of the old, like, customers that had them do engineering work. I called them up and like, Hey, Dan, here, like he got some free time, like we need engineering work done. And so he was like, in the kitchen of the house that I lived in with Dylan. And he's like doing engineering work. And he was like, hey, the first job came really fast. I was like, Congrats, man. And I was like, but watch out. The second job would take a long time. And just wasn't the case. Like second job, like people refer to him. It was like those first few will refer to him. So just in he just started in engineering out of the kitchen, and then it goes out of the garage, and then he moved in with his girlfriend. So they converted his bedroom into the office until like, two of them were working out of there. Yeah, it just kind of grew. Or yeah, sometimes it just works. Yes. Sure. It's not always so easy, but sometimes it is. I love it. That's awesome. Actually, on the things not being easy sign on like talking rambling. Sounds good. So I do enjoy and things aren't easy. That first project, my brother likes to work in a much more planned and generally less stressed out environment than I do. But I really enjoyed that that first project did involve some stress, they were like to meet a deadline. It was like one of our now founders, like, flew out from the East Coast. And they were up all night and like finishing stuff, but they hit the deadline, and the customer was really happy. So wow, sometimes,

Ryan Rosztoczy 35:26

sometimes you got to push a little. Yeah, for sure. Cool. Yeah, no, I mean, maybe that's one of the beauties of when you're a freelancer or later you when you're sort of running your own company, the there's a lot of incentive to push times. Okay, cool. Dude, I love those stories. So. So what I'm curious about is, there's this epiphany of we're doing this work, we want to make our own product, this might be the right time to get into autonomous boating. And then you guys raise some capital to do that, right.

Mike Flanigan 36:04

In the beginning, some of the first stuff we did actually, like the scuba continued for the first like, maybe even six months or so, like Groover just basically kept, yeah, kept running is, you know, tuned down a little bit, it was like, we each put in some money to like, buy equipment and buy stuff. Dylan started taking, like, more or less to know, kuruva jobs. I'd finished school. And so I was kind of like, free and floating and just kind of like, am I going to get a different job? Or am I going to work on this? And so I came out here and basically started working on this. So you know, I would say like, some of us, like, definitely had the like, luxury, the financial freedom, just say like, okay, like, I can make it by for six or 12 months here, like really not making money, but also just like, try to be frugal. But then, but then the flip side of that is that like, yeah, basically Kuva kept operating for a while. And when we were applying to accelerators, they always want to hear that. So is everyone full time? Like, you basically by the end there, okay, the answer is that you're all full time. Want to get over full time then like, yeah, we're just tell them we'd be like, yeah, we're full time. That'd be like, during that interview, we're full time. Like, hey, until like, we can make some money, like how we're going to pay the rent to keep the shop open. Like, yeah, extra monthly. If we don't have any money to work on this thing, then, like, Yeah, we're gonna keep making money on the side. It's like,

Ryan Rosztoczy 37:33

yeah, we're full time, we have these two employees that do the services side of the business that bring all the revenue right now.

Mike Flanigan 37:40

Exactly. And they do whatever's necessary to bring money and exactly how it was.

Ryan Rosztoczy 37:45

So you, so you mentioned, you're talking to accelerators. And that's when this comes up. And that's because you decide to build this product, you decide to go in on autonomous aquatic vehicles, and then was the next step. Okay, we should go to an accelerator?

Mike Flanigan 38:05

Um, no, vague to tell you that, like, very vague and terrible business plan in the beginning was yeah, it was like, the thing that I think got started was like, oh, we'll make this demo. Or we'll make this thing that has these MVP capabilities, we're gonna go demo it to a couple people that we know, like, we knew, like this woman who worked for a navy company, we knew, like a couple of people in the space. And we didn't know how anyone raised money. We didn't know where I've been initial seed funding came from Frank, these other companies in this space. So it's kind of like, a we'll just, like, make this thing. We'll go do this demo, and everyone will be super impressed. And like, someone will give us a bunch of money. And we'll like, you know, make a company. Yeah. Yeah. Like, we'll figure out how to make it real. We did. We did like I remember having a sit down. We Yeah, we didn't think that we're just gonna sell it right off the bat. Because we did have a sit down like Phil Knight both having worked at Ocean Eric. Man, it's gonna take like a 15 person. Like, we're not going to lose chapters to people, we're not going to get to like a market ready product for two people. It was like, it's gonna take an engineering team of 15 to get there. So like, so what are we gonna do the meantime I was like, well, we can definitely hack really impressively. So it's like attacker, really impressive demo. Use that to raise some money or to sell something and then figure out the next steps.

Ryan Rosztoczy 39:19

Love it. Love it. It's so cool. And then and I mean, I think I remember you saying this. That's why I like in your minds. TechStars was your like, we need to learn how to scale this thing. Right.

Mike Flanigan 39:35

Tech Stars was the real deal. Tech Stars are so good for us. Yeah, we applied to a couple of different cohorts like we applied to. It was a little except accelerated even our accelerated accelerator process, but we applied to one and really got schooled we applied to the border on because I was in Boulder at so I talked to like Andreas, and some of the like his team there. And it was Great, we made it like to the final round interview, but we got roasted on a couple of different interviews and like having the wrong answers, including some like memorably horrifically failed. Answers, like in interviews were shut out. I was like, Oh, that was the wrong answer.

Ryan Rosztoczy 40:12

You gotta you gotta you gotta give me one now. That's great.

Mike Flanigan 40:17

Yeah, I think I think one that was like a bad one was just like, at one point, someone was like, well, like, the technical stuff is way ahead of our business stuff. It was like asking for some business answers, like, what's your business models? Like? Well, we don't really have that. But we got pretty good technical stuff. And I was like, it's like, it's not a good answer for like a business. Like, it's a thing. Like,

Ryan Rosztoczy 40:36

you're like, you make, like a cork core guiding company principle is if we build it, they won't go.

Mike Flanigan 40:45

There. That's not gonna work. Yeah. So by the time we got to the end, by the time we like, we then got shuttled to another one that didn't really interview us. And they spent like, no time and we like got shortcut into the finalists and then got rejected, right. That was weird. And then we properly interviewed one more time. And at this point, everyone was like, Dude, that's a waste of time. Like TechStars is just like plans on we shouldn't be interviewing. I was like, give me one more. This guy, Jonathan Penske texts, our space is like, this is the real deal this time. And sure enough, is like good interview. Also. Also, like, you can look up anyone applying decks artists can like click up basically like, oh, all the questions that yc is gonna pepper you with? Yeah, it's different ones. It's like, how are you gonna get 100 million ARR need to know the math interview, I'll say in like, one sentence for us was like 250 Boats $1,000 A day operating like 80% uptime is like, over 100 million arr. And, like, and we know that $1,000 A day like we have a competitor in the space who's selling boats for $2,500 a day services like, and like, by the time we knew that, and I could regurgitate that like on a moment's notice. I was like, okay, cool. These guys could actually make money into this.

Ryan Rosztoczy 41:56

Yeah, I love it. Yeah. Well, I think people take I mean, the tough part about any interview question like that, for an accelerator is, you know, they're limited on time and scope. But so you can't just like go back and like, hey, we thought of it, you know, but the reality is, like, you iterate on the business just as much as the tech product. So whatever you say is the answer. It's just like, that's what you're thinking about ahead of time, it has no bearing on what it will be, you know, six months later,

Mike Flanigan 42:25

a ton of the business stuff is a little frustrating to technical people, because like, basically, you could ask anyone, like a technical question and answers almost always ends. Like 30 variables like to give like a truly accurate answer. But in the business world, there's almost always just like a correct answer and ever moves on, which is like, show me your financial model slide. And it's like, okay, it should be like hockey sticking up. And then and then they're good, you know how to bullshit your homework and to turn it in, and then we move on.

Ryan Rosztoczy 42:52

Now, I kind of want to I kind of want to start a bogus company apply to an accelerator now and then just show a logarithmic graph. of it. Like they're like, No, that's the wrong answer. We want the hockey stick.

Mike Flanigan 43:06

Yeah. Okay. Nice. I'm glad that you actually said that. You're gonna be like we've heard there. But yeah, like logarithmic. Just show completely, like, we've learned to plateau, like,

Ryan Rosztoczy 43:16

this thing will scale to 10 users, and then it will decrease rapidly.

Mike Flanigan 43:20

Man, you should podcast review a like a why. So you should get yourself into like a YC interview and be like, how to give all the wrong answers. And when they're going to scale to whatever be like, we plan for this to be like a four person or lifestyle company for how we're going to make our tax return. But we plan to Nobert

Ryan Rosztoczy 43:38

Yeah, yeah, I'll figure I'll do like, how to hack YC, like Princeton Review version, we're all figured out the wrong the wrong answers the questions and then everyone can do the opposite.

Mike Flanigan 43:48

Dude, I would wash that, that'd be great.

Ryan Rosztoczy 43:52

Okay, so So TechStars is amazing, that sets you off on a trajectory. Top couple of takeaways, where you come out and your perspective has changed, your thinking has changed. Yeah, just curious what the out look like.

Mike Flanigan 44:09

Um, I think one of the things that tech search does is they try to make you in this probably a good answer to like investors until a lot of business models and stuff too, which is like, you probably need something that you're awesome at, like, you need some spike that you're winning on. And then really, the other half of that is you need to not suck at anything, because investors kind of like ideally, they got emotionally hooked and excited, or even like your customers got emotionally hooked and exciting, excited. And then they're looking for, like, Oh, now they're doing doing due diligence and trying to like pre mortem, like, Okay, why is this thing gonna fail? And generally, there's a giant red flag or too many red flags. And so, Tech Stars was like, okay, cool. You guys have something that's exciting. And like, yes, like you're not going to be able to be good at all of these other things, but like you need to patch them up and just have okay answers. Like standardize have answers have an attempt at all of these different things. So it's a real whirlwind and doing just like a gazillion different things like, I mean, they also have like tons of like customer discovery, Metro madness, and like, yeah, there's a ton of good points, but I would kind of synopsis it in like, here's a whole checklist of like how to be a company, and you need to, like not get an F and any of these things,

Ryan Rosztoczy 45:22

I love it. It's almost like, here's what we're going to accelerate you, but then we're gonna do guardrails, like, we don't want you to fail is one of the biggest ways you can fail.

Mike Flanigan 45:34

And even like, if you try to get an A on, like all the criterias of how to be a company, like you're definitely going to fail, yeah, you'll just explode. Or if you can't get it done, like if you only have a couple people or one person, like there's just no chance you can keep up with like the businesses of today. And so that was just like, yeah,

Ryan Rosztoczy 45:51

so by the end of TechStars, your answer for the business model is not

Mike Flanigan 45:55

a Yeah, well, we've got a cool technical stuff. Yeah, no, it was it was like, here's our sales plan. Here's here's the Yeah, exactly. Yep. We had a business model.

Ryan Rosztoczy 46:06

Awesome. I'm Did you did you guys get funding coming out of that?

Mike Flanigan 46:10

Yeah, I'm funding going into, it's just super helpful. Like they like TechStars, NYC had like a standard like 121 30k deal. That's super helpful. We were some angel funding at the same time. And then coming out of it. Coming out of it was frankly, really hard. We did not raise money fast. But within like maybe four months, we raised a million dollar round, which is huge. But boy, we that was hard. We had to pull, like every trick in the book and try. Like, yeah, we had so many investors bail on us. And yeah, those are like, for many I would say from the beginning of Tech Stars, all the way until. Definitely for the meaning of Tech Stars for like one year, we probably never had more than like a three month runway and sometimes shorter. Whereas like, wow, things are like, yeah, it was like, Oh, this is not gonna last very long.

Ryan Rosztoczy 47:09

Wow.

Mike Flanigan 47:11

Maybe you want to think of if after that million dollar, I guess after the movie, because well, no, because even the million dollar round, like we say, and this is like an example of using every trick in the book. If you look up our stats, like online, or if like I say, right now my kid, we raised a million dollar round, really didn't raise like, you know, 150k from someone in the beginning, who's like, Yeah, I'll put in 150k. And then someone else was like, all come in for 50k. Someone else's, like, I'll come in for 100k. And some of those, like, we use a rolling close safe, because we couldn't like we had, we had multiple times we got very close to closing around with like a major lead investor, you could say, Yep, and yeah, I'm gonna close like that everyone invest at once, get all the money one time. We were right, this is not working. And we're going to be kind of screwed here. And so we went to a safe where you can just basically accept money on the fly. It brings in its own headaches. But we went to that, which meant that we were accepting money as we went, I guess when we finally got like three investors at the same time to come in and read some really critical ones that joined. Yeah, like a syndicate of some really good guys. And then also like monozukuri ventures, and they came in at once, for maybe something like, kind of makeup. Not correct, but 400k That probably gave us a couple more months than three months runway, but it was just like it was just always really tight for a long time.

Ryan Rosztoczy 48:29

I mean, yeah. Do you call it a safe? Is that what it is? We're Yeah. I need to remember that I was just talking with the founder that in a very similar space, looking to raise a seed round right now they've got I don't know the exact number. So let's say like a quarter of a million locked up, they had a big lead investor, I think they had to back out for some reason. So it's just they're in this space where like, you know, now cash is tight. I haven't actually even heard of that where you can essentially just take it in over time.

Mike Flanigan 49:02

Dude safe sir. Yeah, so safe is a publicly like we did TechStars. But you can download the safe from the YC like Google Safe yc. There'll be like a form documents. And it's basically it stands for Simple agreement for future equity. And then there are some weird math things. Like safes like lawyers don't like safes. But if you don't have a lawyer on your team, you definitely want to use the safe. Because like lawyers created the safe. So like illegally works. It's a real deal thing. But it just like leaves a bunch of the hat, like all the stuff where you would have like teams of lawyers duking things out, and it would be like an aggressive situation. It's like, it's like three lines. It's something that like you and I can understand. It's like, oh, maybe maybe you're like a lawyer or son of a lawyer, but I don't profess to be good at legal stuff. And I'm like, Cool. Here's the money. Here's kind of the upper end of the valuation. You can read this book. It's called Venture deals. How to be smarter than like you're in bed. stir and you're a lawyer or something like that. And I like skimmed probably half of venture deals like enough to, like understand safe dynamics to like, answer the questions and do the math. And yeah, so safes are sweet. It saves a lot of headaches. Yeah, awesome. And we play the tactics right? Then you can actually get money closed, which is like critical for business. It's like, Hey, you can't like oh, yeah, there's just like, so much like handshake deal. And like, oh, maybe and hype and all this stuff. It's like, yeah, raising money kind of sucks.

Ryan Rosztoczy 50:29

No, yeah. Right. I mean, I love this story. Yeah, that's actually getting the cash is what matters. And you nailed it. I mean, I yeah, just working with founders going through this right now. I understand how, just how everyone imagines it's going to be a straightforward process. And in reality, unless you've been preparing well ahead of time, and you have a deep network of connections, it's not it's gonna take a lot of time. There's gonna be hiccups. There. Yeah, I don't actually know. I've never even seen it be a straightforward process.

Mike Flanigan 51:00

Yeah, the same. The same is really cool. Man. If you've got like, I don't know. I mean, like, very simple rules is like, like, oh, you need a Delaware? Well, I don't even know that's true. But basically Delaware C Corp, you probably should work with lawyers, a lot of good law law firms like kale law, which is a boulder colorado firm. Why don't like good startup law firms? Well, you know, you're working with a good, we'll law firm, because they will know about startups. And they will, if you can convince them to work with you. They'll defer your payments for like six months or a year. So we had a legal team that helped us like incorporate the company properly. Tell us a bunch of the stuff that we've done in the beginning, that was like bogus, and they're like, oh, no, you need to do like this. I was like, Okay, we set up the company. We didn't have to pay them for a certain runtime, which helped us like get probably like, all the way to TechStars. And then it was like, okay, we can pay back our legal fees. And you safes and then like you don't, because anytime you talk to a lawyer, it's incredibly expensive.

Ryan Rosztoczy 51:56

So we in startups, the T deferring legal payments, taking in capital over time. Oh, I love it. Yeah. So cool. And then, man, and then you're operating under this constant, like, you're continually getting cash in the bank, but you're never quite at this feeling of safety.

Mike Flanigan 52:20

Do you take in I mean, so we like are very fortunate and that we just close this big round with Elfi Harris and some other investors really led by alpha hairs. And so now I can say like, just in the last couple of months is the first time that we've been like, wow, shit, like, we can plan with like, security and like, hire people and not be making all these ifs, buts and then some, like contract negotiation, and like stuffs, like, really, like we're operating like, pretty freely right now. It's, it's pretty epic. It's incredibly fun time period. But yeah, I mean, that like a long period of operating and insecurity can also just like, people kind of nuts. Like, it's not a fun place to be operating from. I mean, I remember, like, we were just like, for an example of like a little store, and like how this can be kind of brutal. We were, like, accepting an investment from an investor or one of those investors on that million dollar round. And they had a term in there there. Oh, and you need to spend, you know, you need to buy this, like 20 grand insurance policy or something like that. And I won't go into the details there. But one of my co founders was like, Dude, this is nuts. Like, why are we spending any money on that, like this, it's like, brushing a guy's teeth, when like, his legs need tourniquets, like, you know, has no legs like this is a really, like, this is like such a bad expenditure money. And I was like, hey, like, well, we'll figure it out. Like, is it just, it's just, like, just keep patching the next problem? And then yeah, eventually we did sorted it out. But uh, but it can be, it can be a little harrowing. Yeah, I

Ryan Rosztoczy 53:47

mean, I know I've seen I've been through it a little bit myself. We've been my brother. And then I've seen him go have to go through a lot before. And it really does soak from positive sort of momentum when you have to deal with all these cabinets. On the flip side, I would be very curious. And I'll be really curious to talk with you again. After some time has passed, because my gut would say, the battle instincts that you honed, trying to keep a company running under such tight fiscal constraints will probably pay off in weird ways. Like, I'm sure.

Mike Flanigan 54:23

They definitely do. I mean, like, on one hand, like we're constantly having any kind of like predicting the last few months, it's been like, reframing like our key decision makers minds being like, Hey, make sure we're not being overly frugal on this thing. Like timelines are more important to us right now. Then, like 10% profit margin. So it's like, make sure we're not using our old ways going forward. But on the flip side, just like you just said, we definitely have like a frugal mindset as a company where, you know, some people offer us a solution like, Oh, why don't you just use like x machine? It's like, that's $150,000 machine like, no thanks. We do that with like a $2,000 machine and like we do just fine with these tolerances, like we're not trying to be a big, bloated Corporation.

Ryan Rosztoczy 55:05

Oh, love it. Oh, so great. Yeah, well, so you did just raise big rounds. That's awesome. Congratulations. Thanks. One thing I did want to ask you about x. Actually, now that I think about it, you're doing all kinds of interesting funding stuff, because I didn't know about the safe process. But this was also a corporate round, right, which I think is really interesting. Can you I mean, is it the exact same as a standard like venture capital razor? I assume not. Could you just kind of walk me through what that looks like? Yeah,

Mike Flanigan 55:43

I would say it was, it would be actually, it would probably even be hard to even like fit it, like, short and reasonably concise answer, I would say made up with like, a lot of different rounds, there's always like personal or actually use use a good way to compare it to venture capital. And this is just my understanding, which is definitely naive. But from what I went through and experienced in from talking to advisors, or mentors, like for VCs, you typically have a scout who finds you, or one person in the firm, and unless you got lucky, and the person that found you happens to be the boss of the firm like that the most senior decision maker, usually you're not found by that person who's usually the scouting job is up someone else. So usually you're found, then you need to make it through diligence, which is really them being able to regurgitate an internal sales pitch to their key people. So within, yes, like, we lost a lot of deals, like when I said, like, we probably like three different deals that had like major leads who spent, we spent hours and weeks of meetings with these people in the promise of like, multimillion dollar rounds, and then being like, this is a sure thing. And then they come back to it. And that at the end of the day, like it finally fizzles out and dies. And you're like, man, what happened. And it's like, oh, behind closed doors, they couldn't get the deal passed. They're like their decision makers. And like you weren't, you didn't get to be in there and charm them with whatever vibes you had with that one person, like, someone else who doesn't like you. He's making a pitch against your company. Yeah. And that person who's stoked on you needs to remember, like, all the details, you know, it's sort of it was a good lesson, like optimism, like if I'm having a conversation with you, and you're totally stoked on what I'm doing. And you're like, Man, I'm so stoked on and care about the details. That's actually probably bad, because you're probably not going to know enough the details to make a really concrete argument to your partners. Whereas if you've got a VC person who's, like, stoked, but asking enough to really understand your business, because everyone wants the business to be simple. If you're like, Yeah, give me 10 bucks, I'll send you a million bucks. And that's like, every single time, then it's easy. But for us, like we have a complicated business. So the people who were the champions couldn't go for whatever reason, we would, our deals would always die in closed doors, but behind like back with that circle, like three to five people. For a corporate, it's much worse, because you don't have 35 people. You have an accounting department and you have sector heads, you've got corporate presidents, you've got teams, like we, you know, like you're talking dozens of people, you're talking like a public company, they need to defend all of their stuff. Like it's, yeah, it's like working with a big company be hard.

Ryan Rosztoczy 58:36

Wow. Okay. I was not. I was not thinking you're about to say it is harder, but it makes sense. But

Mike Flanigan 58:44

I would I would not try to like, yeah, like, you know, Boeing has like Boeing's venture arm, I forget what it's called. And like, Lockheed has a venture arm and like, some of the big energy companies have like, like EIP ventures have like energy branches, and like Shell ventures, like, I think in general, those are way harder. I'm just gonna do way more diligence, like, yeah, yeah. It's yeah, it's gonna be hard to get past those.

Ryan Rosztoczy 59:12

So you said a part of that is your business is complex. And I mean, we're talking about autonomous drones. So you know, we can just take your for your word. But I do want to start to just unpack that a little bit. Because you are dealing with I mean, you guys Oh, hackers, engineers, your mechanical NCS, which is amazing. But you're still dealing with hardware software, the real world out there in terms of the elements. That is complicated. How, like, how big is your team right now? I guess and how are you like handling all that? Just software for me is enough. That's why I'm that's why.

Mike Flanigan 59:55

Yeah, so our team is about 15 Right now, in when we started I mean, we were you know, for people. And I would say that one of the ways like really to simplify it, one of the ways that we do it is men, we knew our problem in our industry super well. Like, we don't need to solve every hardware problem. We don't need to solve these different software problems. We're done. Like, there are so many things we didn't have to do, because we knew exactly what our customers needed. And there's like, only build what we need. And like, even though we're doing little bits and all these different areas, like it's made hiring hard, because sometimes we pull someone in a cruise experience from another industry, they come in, they're like, Oh, my God, this is like a flaming dumpster fire. Like, I don't want to work here. And we're like, Hey, okay, like no worries. But that same flaming dumpster fire, like customers look at it, like from our like, from a customer perspective in there. Oh, my God, you've solved the one problem that I hate in this industry, that your thing is amazing. And so, you know, it's just being super focused, like, only build what you need.

Ryan Rosztoczy 1:00:58

Yeah. So yes, I'm in Oh, yes. Perfect. I'm going back to your earlier initial comment on being able to integrate other sensors. So is it fair to say it when you you know, you said, you know, part of it is vertically integrated? Is it fair to say that when you are building something yourself, it is in the you think it's necessary to solve the problem, essentially, that you're solving? Like? So there's a little abstract, but maybe you need to build a particular sensor or a particular software that will transfer data from one place to another or whatever? Because it's in pursuit of the problem you're solving and doesn't exist yet. But outside of that, you're essentially going to be stitching together different components. Is that fair?

Mike Flanigan 1:01:48

Yeah, like we stitch, we use so many different components from different places. Yeah, we use stuff left, right and center that's already built, like we try not to reinvent the wheel because we're doing like, yeah, or just a really wide stack. Like we don't, there are some competitors who only lease their boats or do data as a service. There's some competitors who only sell their boats and do hardware sales. And we're like, hey, we do we sell it, like, you're gonna look up on our website, and you can see our price, which is actually a neat, there's no competitors out there who put their price on their website in this field. And so you're gonna look up our sales price, our lease, our leasing, one makes you quote, and then our data as a service price. And the reason we do that is because it's a complex answer. This is why it's like investors don't like this answer. But it's like, some customers only buy one of those methods, and some only buy the other. And so by offering all of them, like we expand that market, and there's some core values that allow us to, like serve both ends efficiently. But like, even our business model is complex, because there's like different costs associated with running data as a service than there are with hardware sales. And there's, there's complexity across front. And then yeah, when you actually get into the product side of things, correct? Well, yeah, we're solving like a manufacturing problem. We've got like energy efficiencies we're dealing with, like, oh, yeah, let's mix in some AI because like, some people need intelligence and robots like satellite communications, like, oh, have you heard of Starlink? Maybe we should be using that. So now suddenly, you need to be like, at least somewhat first. And like the latest in satellite communications, it's like, there's a lot of moving pieces to track.

Ryan Rosztoczy 1:03:30

Yeah, no kidding. But the idea of simplifying it by focus attention on the problem you're trying to solve it at school to me, it's so cool to hear you say that it's so cool to demystify a little bit it doesn't take away from their complexity at all but it does help me understand how you're doing it. That's awesome.

Mike Flanigan 1:03:54

Yeah, that's kinda Yeah. Focus is like I feel like everyone says that a lot was like God definitely golden rule. Yeah.

Ryan Rosztoczy 1:04:01

So I think I remember I think I asked you what your biggest struggle was and I'm pretty I remember at the time I'm curious to hear what I said at the time. The time I think it was daily I think it was manufacturing is that is that ring a bell?

Mike Flanigan 1:04:19

Yes, I would say supply chain which is like which yeah and not even supply chain Yeah, it's really manufacturing like production of these vehicles. Yeah. Which

Ryan Rosztoczy 1:04:31

I go for it is that I mean macro economic or you know like same supply chain issues have been hanging everybody or something else going on?

Mike Flanigan 1:04:41

Um, it's a little bit supply chain issues have been hitting everyone but I would say more that we build a lot in house and we like aren't you could like make some comparisons. I'm definitely not trying to make this to be grandiose because like we're just like, not in a country grandiose but parallel and some of the reality of the problems in Like, Tesla builds and got a lot of still does get a lot of grief for how much they choose to build in house. And when you build in house, you're always paying for that in time up front. And like in errors and mistakes, they make their own seats and house and like random stuff into work. Why are we making car seats, like you can just buy new seats, like their whole companies that build car seats for automotive? Like, like the actual chairs, and they had their reasons, whether it's way integration design, or whatever it was, they decided that they wanted to build them in house. And it's like, okay, so you pay for that, and learning how to be a car chair, producer, and like making some silly mistakes as you ramp up in that process. So we build a ton of stuff in house, because at the end of the day, that makes our products lightweight, energy efficient, affordable, like we, you know, we kind of have this envision and to get there. There's a lot of areas where we're like, hey, yeah, like the industry solution isn't going to cut it for us. Like, that's not good enough. And yeah, so so it just takes time. So we're learning how to build out that manufacturing process.

Ryan Rosztoczy 1:06:01

Yeah. Cool. That's so awesome. Cool to hear. Okay, yeah. So just upfront investment gonna be a slow start, but you can if you can learn fast enough. Will you'll see some major payoff over time.

Mike Flanigan 1:06:14

Definitely. Yep. And that's super exciting. Like, definitely our biggest challenges also, like our biggest exciting point, like, you know, we, it's like, oh, man, I can tell you like, we've researched hard, like the number of vehicles that like different people produce in this field, and you think this field is going to change dramatically like maritime, I think maritime robotics is like where aerial robotics were, like 10 or 15 years ago, before, like, in 15. Or today, like, aerial drones, like, the airframe is commoditized. It's like, man, you can go you can buy flying drones as stocking stuffers for crazy. Holy shit, like then on the technology stuff from that, like $15 thing is bonkers. It's got flight control systems got remote control, it's like this is wild. So I think it'll be a similar parallel. Like, right now, there's just not that many boats out there to do the jobs. And so like we're investing and how to do that. And I think that we have like a great, a great plan, and we're making great progress on like, going a lot more vehicles than anyone else has. And so I think that's gonna be a pretty big game changer. Hopefully, if we were to talk like a year, or 18 months from now, it'd be like, a Yeah, see, SAS has like, loads of vehicles and like, like most other companies aren't keeping up.

Ryan Rosztoczy 1:07:28

Yeah, I love it. We'll do we'll do a rehash and your biggest pain point will be something else. It'll be like, Yeah, I don't know. But you'll have that taken care of. Awesome. Cool. Oh, that's this is honestly been like, so awesome for me. Tons of fun stuff. Tons of fun technical stuff.

Mike Flanigan 1:07:52

Thanks, man. Yeah, it's it's fun to chat about. I feel like I think one thing that's hard on stuff is there's like, yeah, there's stories out the wazoo. There's like tons of different stuff maybe similar to being like a big complex business. It's like, it's just like stories and stories.

Ryan Rosztoczy 1:08:08

Yeah, no, that's, that's where the gold that I'm here. Yes. I mean, anything you want to talk about anything on your mind before we wrap up?

Mike Flanigan 1:08:19

Um, no, I guess as long as this is going out and get some airtime. Hey, if anyone's excited, and like one of one thing is we're hiring, we will likely be hiring throughout the time, as long as things go. Well, anytime someone listens to this, we'll be hiring. Hey, guess what?

Ryan Rosztoczy 1:08:37

There's live on the air. What what types of roles you guys looking for right now?

Mike Flanigan 1:08:40

Yeah, some of the main ones we're looking for in our software. But also, I mean, really, like a cross over to the stack of like, like electronics engineering, like all electrical engineering, mechanical design engineers, particularly software engineers. Fear, like, rushing to the ML seem like machine learning and give us randomness. Yeah, there's, there's posts that go up on our careers page. But yeah, people are pretty sharp. I guess actually, to clarify, one area that we're not really hiring for right now is like BD stuff. Like, we'll probably be expanding our business Feldman, like, hopefully six months from now, but currently, oh, man, we need to solve this production problem. So

Ryan Rosztoczy 1:09:19

yeah, awesome. Cool. Great. One last thing. And it's okay, if you don't have anything, but I've been asking everybody. If you had one piece of advice you would give to somebody who was thinking about starting a company or who had just started, what you might say.

Mike Flanigan 1:09:40

I think accelerators are great. Like if you can do an accelerator. I think it's so worth it. And we have investors who are like, oh, like you did an accelerator if you gave up 6% of your company to go to that accelerator. That's not worth it. That shows you a bad business sense. Like I'm not gonna invest in you. It's like, okay, sure. Like, accelerators are so valuable because it seems If you always feel like your company's unique, you should feel that way because that means you have a unique differentiated thing. But it turns out that like, these accelerators really do, they're onto something like, starting a company is not unique. It's like there's tons of the same check marks that you need to solve like, check. And so they can give just great advice and really help so you can get into and it's harder, it's well worth like hair, pulling out time and applying to them and interviewing and getting rejected, like, keep going.

Ryan Rosztoczy 1:10:26

I love it free, free advertising for Tech Stars. there real quick onto that, that investors saving. It's so funny. It's like yes, 6% of what if the outcome at the get go is so binary? You're talking about a zero or a one. Like if you can up the chances you get to a one. Go for

Mike Flanigan 1:10:46

it. Exactly. It's like you can Yeah, exactly. Yeah, you're completely on it.

Ryan Rosztoczy 1:10:53

Fan Haiti, this has been so awesome. I'm so glad we were able to connect and glad to have you back in the US. I really love how Mike hammers home the value of an accelerator if you know what you're trying to get out of it. I think really clear that see SATs turned into a different company going through TechStars so that was great. Thanks for joining. I'll see you next time.

View Details

Welcome to another episode of the technical founder, the show where I meet with engineering founders and we deconstruct and demystify the science and art of building technology businesses. My guest this episode is Nicholas Blanchet. Nick is the Co-Founder and CTO of Ohi, a platform that enables ultrafast same-day delivery. Nick is a fantastic model for aspiring technical founders. He transitioned from finance into engineering in pursuit of becoming an entrepreneur. His goal moulded how he approached advancing in his career and enabled him to gain experience leading teams in high growth environments at ElleVest.

Nick is a systems thinker and this extends beyond his appreciation for optimization problems and software engineering - I found his thoughts on reducing sprint volatility, distributing knowledge, and driving engagement in a remote environment to be very insightful. We also discuss build versus buy, when to tackle technical debt, decision making blindspots, and the importance of minimizing feedback loops.

‎The Technical Founder: Nicholas Blanchet [CTO, Ohi]: Leading Through Growth, Optimizing for Remote Work, and Doing What Gives You Energy on Apple Podcasts‎Show The Technical Founder, Ep Nicholas Blanchet [CTO, Ohi]: Leading Through Growth, Optimizing for Remote Work, and Doing What Gives You Energy - Feb 1, 2023Apple PodcastsNicholas Blanchet [CTO, Ohi]: Leading Through Growth, Optimizing for Remote Work, and Doing What Gives You Energy0:00/68:001×Highlights[4:01] Effective founder dating processes

[9:30] Evaluating startup ideas as a founder

[19:36] Managing technical debt

[24:07] Reducing sprint variability

[34:03] Build vs. buy

[39:51] Process change management

[44:06] Decision frameworks, blind spots, and minimizing feedback loops

Transcript (Provided by Otter.AI)Announcer 00:12

Welcome to the technical founder

Ryan Rosztoczy 00:25

Hello again, this is your host Ryan Rosztoczy. Welcome to another episode of the technical founder The show where I meet with tech founders to deconstruct and demystify it the science and art of building technology businesses. My guest today is Nick Blanchett, because the CTO and co founder of Ojai a logistics platform that enables same day delivery nationwide. When I was first introduced to Nick, he told me how, when they first started, they were ordering batches of products that office and fulfilling those orders themselves. I just thought that was a great example of doing something that doesn't scale in pursuit of understanding the deep problem. So Nick hits me as somebody who's super deliberate, the Ohio that he leads today is much different, they last fundraise was a $20 million series A in October of 2021. I really hope you enjoy this conversation with Nick. Oh, let's hop in.

Nicholas Blanchet 01:24

Ohio is building the platform to make instant commerce happen. We connect ecommerce platforms like Shopify, big commerce among others, to a network of micro warehouses and delivery carriers to enable very fast delivery that can compete and is actually faster and cheaper than, you know FBA or Fulfilled by Amazon and the Amazon promise of prime. So that's what we're doing. We've been doing it for about three years now a little bit longer than that, when Ben and I sat down in a bar for the first time and started mapping out sort of the plan.

Ryan Rosztoczy 01:59

Okay, I actually, I do want to talk about that. Singing a bar mapping down the plan, because when last time we talked, you made it pretty clear to me. I mean, sounds like you've always had your gut, your eyes set on being an entrepreneur. But you mentioned that a lot of the idea came from Ben. And so I'm curious, like, what did that meeting look like? Did he have an idea for Oh, hi, mine is looking for a founder? Why'd you guys get together in a bar and start chatting about this?

Nicholas Blanchet 02:31

Yeah, for sure. So it was it's definitely been Ben's idea. He has a great founder story about like, how he came to realize that this needed to happen at the scale that we're trying to achieve. But we were introduced through a mutual friend at the time, Allen, who said, like, hey, Ben's got a great idea. I've started helping him on some of the technical things, but he needed someone to really be a partner with him and building the business. And so that first first meeting was really making sure that we've added together that's super important. The number one reason, the number one of the number one reasons that startups fail is because of founder problems. And that can come from a host of problems. But the personal is definitely one of them. And so we want to make sure that we could we could get along, which became pretty clear, fast. All right. And then the next one was obviously me evaluating the ideas like, Hey, can I poke holes in this? Can I actually add value to what he's trying to do? And that became apparent pretty quickly, too. I have, you know, eight years of startup experience before that, learning from previous startups, like simple reach nella vest, with the idea, like you mentioned, of going and founding my own company. But when you're told a great idea, like what Ben had for Alhaj, it's much it's very nice to be like this. This is a market and an opportunity that we can jump on right now. Super complementary, complementary skill sets, which is something that I think everyone should look for in every aspect of life, but especially when you're founding a company with someone,

Ryan Rosztoczy 04:01

I love it. I do we will dive into your career a little bit before I but before we go there, you're right, like founder fit is critical. And so you guys mitigate inertia. How long did it take? Like, did you go through a series of like in person meetings? Or what did that process look like before you felt like Yeah, this guy I really vibe with we can do some good things together.

Nicholas Blanchet 04:28

Yeah, that's a good question. I mean, it was pretty informal. It's not like there was a formal dating process. At that point. It was, you know, we had that we kept chatting, texting. I helped him a little bit on some ideas that he was walking through. You know, just like in the dating life, being introduced to a close friend is super helpful. And so, you know, I took a lot of faith that that my friend had a lot of respect for Ben. And, you know, it all sort of matched up pretty quickly. So I think it It probably took like four or maybe five months total, like, be set be like me quitting my job and then deciding to join him as a co founder. And that that first introduction. But there was a, there's a bunch of different conversations that we had between there making sure that we're aligned in a couple different ways. And we wouldn't mind sitting next to each other for a very long time.

Ryan Rosztoczy 05:23

Did the dating analogy is amazing to me? Partially, because if it works out, you end up spending your lives together.

Nicholas Blanchet 05:31

You spend a lot of time together for sure. Yeah. Every every every early stage company, you know, maybe not nowadays with the remote world. But, you know, we sat together for hours and hours. Like, at that point, I wasn't married, but I was spending more time with him and my now wife.

Ryan Rosztoczy 05:49

Yeah, well, I mean, the other thing, too, is just really resonates with your process, which sounds very organic is I've seen things recently, it was like, I saw an article on LinkedIn that was like, five, co founder dates to have before you make a decision, you know, to cover all the bases. And I was like, Oh, that seems very structured. But the heuristic of being introduced to someone through your network, I think, eliminates a lot of the need for that structure, because you sort of have this filter of trust of evaluation of their character that has it sort of he's already gone through that. Right. If your friend is introducing you and recommending him, you don't necessarily need the hyper structure framework for evaluating someone.

Nicholas Blanchet 06:36

Yeah, I think that I think that's certainly true. But I do think that the conversations that we had probably answered a lot of the questions that you found in that article, I was I was asking you about like long term objectives, like, you know, where he thinks he's particularly strong, where he needs help, like, we did a lot of the sort of informal slash formal questions. We just didn't have like an interview setting. It was it was a little bit less formal than than that. But we did make sure we covered a lot of grounds there. And that, and he was intentional about it, too.

Ryan Rosztoczy 07:14

I love it.

Nicholas Blanchet 07:15

I get the impression that it was just randomness. And it's working out really well, right now, because of that. It's a lot of things that need to align there, it is a hard thing to evaluate.

Ryan Rosztoczy 07:25

So so obviously comes in, you know, he's evaluating you. You're evaluating him, but you had specific things you're looking for in the idea. Do you remember any thing that really stuck out to you, that you were looking for that you saw in his vision for Oh, hi.

Nicholas Blanchet 07:45

Yeah, there's, I think I was sort of developing a structure for evaluating startup ideas. Selfishly, for my own ideas, I was trying to figure out which of my ideas had any sort of feet behind them, which ones I wanted to spend time on. And so I used a lot of those same sort of frameworks or questions for any idea that was presented to me. And I still do that a decent amount with different startups that that I look at, but one of the market sizes, you know, one quick one is just like, is this a marketing opportunity? But I think one of the things that I've realized, more importantly, than just like the TAM, or the market opportunity, is the timing. Is this the right time? Is there a technology advancement that is enabling this uniquely for right now? You know, instant commerce is not a brand new idea, you know, it's a relatively old and reused one. But one thing that I recognized with the timing now is, you know, the Ubers, and TaskRabbit, has changed sort of the labor structure underlying how delivery can happen. And if you look at UPS versus FedEx, as just to sort of neighbouring delivery solutions, they're there, they caught on to this as well, and probably two years behind where we are now. But you know, it's it's super interesting to see how that's taken into account. And some of that is driven by technology. Some of that is driven by sort of the way people look at work now. But that was one fundamental that I saw shifting and said, This is a huge market, and the timing is looking very strong. Obviously, you can't get timing perfect. And obviously, the pandemic changed and accelerated that in a lot of ways. But that we didn't know that that was going to happen when we started. So

Ryan Rosztoczy 09:30

I love this idea of I mean, what are you looking at? Are you using like, kind of angel or seed like VC investment frameworks? Is that kind of what your baseline was? Or?

Nicholas Blanchet 09:42

Yeah, I think some of its obviously borrowed from that. I think one thing that's specific as a founder is you need a problem that excites you. As a technical founder, you need a technical problem that is exciting. And I think in my previous roles, especially in ad tech, I wasn't disillusioned. But I found the idea of working with physical actions and process very interesting for me that the idea of being able to go and see how your the technology is actually impacting the world in a very direct way, was super exciting for me, I got a kick out of that almost right away when I made that first API call that called a Postmates, to come to our office. And all of a sudden, we delivered our first package, which was a little Snickers bar. But pretty exciting. Like, you don't get that in a lot of other tech spaces, necessarily, like, obviously, you can interview users, you have a bunch of analytics, which we do as well. But that physical aspect, it was pretty unique. And I think there's a couple other sort of math challenges that fit my background really well, from my perspective that I found, exciting to be working on. And the cool part about it is that a lot of that has been realized, we were working on some really interesting sort of forecasting, allocations, supply constraint type of problems that I was really interested in college. And I got to revisit now,

Ryan Rosztoczy 11:07

with Ohio, I love that, yeah, not just the interest or passion for the bigger problem, but also the smaller technical challenges to solve along the way. It's great that you also just really resonate when you're talking about this framework for evaluating the startup because, like, unlike a VC with a portfolio where you might apply this framework, you know, across a bunch of investments, by being a founder, you're betting the vast majority of your time on one idea. So like the the importance of getting it right is even bigger, it's so awesome to hear that you approach it so structured.

Nicholas Blanchet 11:49

Only Elon Musk and maybe Jack can, you know, be the CEO and launch multiple startups, but a startup founder, you might only get three shots at it and one shot if you're lucky with the first one and lucky and skillful, but you don't get to build a portfolio necessarily, you really have to choose your first ones. And they have to be exciting day in and day out there. There's a huge roller coaster that comes with building any early stage company, and you have to make sure you you're on the roller coaster with someone that you like, and you have to make sure that that roller coaster is bringing you down an interesting path that will engage you.

Ryan Rosztoczy 12:22

Yeah, love it. Um, so I mean, one thing that strikes me during this conversation is this idea that like, it sounds like you were very deliberate in this process. When we were talking earlier, it also sounded like you're really deliberate about your career before. Oh, hi. I mean, I would love to just go and step back. Because you basically have the idea of being a founder in mind, from what I remember. So I would love maybe if we could just start kind of early, early in your career, how you were thinking about that?

Nicholas Blanchet 12:55

Yeah. All right. I think you the way that you just stated made it sound like I had a lot more foresight, and I really did, honestly. But I did, I think it was you know, it was driven actually by more of an emotional fundamental envy card. My my brother, who graduated university two years after, after me started his own company, I was about two years into, into a finance role that was not super engaging. And so I was looking for new things to be doing. And he was having the time of his life building a startup, and I was like, Alright, how do I sort of pivot into that, and that's when the strategy that you were alluding to sort of came into play? I said, Look, I have a pretty good technical background. You know, I have some of the skill sets that would allow me to be an engineer at an early stage company, how do I make this happened. And then a couple of things fell into place, I think most specifically, and sort of advice for others looking to found a company is that I because I knew I wanted to do this, I was able to make sure I was learning the opportunity or taking the learning opportunities, I needed to add these other early stage companies. And so I was able to have very explicit conversations with my managers being like, this is the type of problems that I want to be learning from you about how to solve so that when I'm by myself, you know, trying to do it on my own, I don't have to learn on my own dime I'm learning here. Or any of that that's helped substantially. It exposes you to a different business side of a startup than if you're just trying to solve the technical problems, which is super important. And I don't want to minimize that. But that's, I guess, assumed. There's a lot of other stuff that goes into founding a company as an even as the technical co founder, that you would just need to learn sort of besides that,

Ryan Rosztoczy 14:57

oh, so no, I love that and if I remember Ever I, you had been talking to it was you had a dialogue with your CTO right at LMS, where you said, like, Hey, this is why I'm here. I want to learn this stuff. Do you remember any of the things you learn that were not purely software engineering? That really stood out to you?

Nicholas Blanchet 15:22

Yeah, there's a lot of like details there. But one of the things is that pretty quickly, the role of the CTO naturally will move away from, you know, writing code. That transition is incredibly hard. It's an it's a very hard transition from ISC to, you know, em, or engineering manager, or like the technical lead. And he encouraged me to take that job, even though I was very interested in continuing to be technical. I love the technology. I love writing code. But here's like, Nick, if you want to be a CTO and a leader, you're going to need to learn how to manage and how to lead. And it's one of the biggest soft spots for early stage CTOs is that they, they've never managed a proper team, explicitly as a manager, and so make sure that you have that experience. That's, I think that's hard that that management experience is hard for a lot of more technically inclined people. And so it was super helpful to get some of that experience, especially in that context, like wanting to do good at it was was very motivating for me, because I was like, Look, I'm not going to have a lot of structure going into the next situation. I think the other part of it was sort of the more operational side of things, the conversations that you need to be having with the CEO, the conversations that you need to be having, with with the different parts of the organization and LMS, we had a compliance investment groups that we needed to have good relationships with so that we could understand the context of the business. And how do you develop that as an IC, you don't necessarily need to have that as much. And so I was encouraged to really make sure that I was communicating not just internally to the engineering team, but across the entire organization. And I think that that's served me pretty well. The third part is just the budgeting. accounting. Accounting was my least favorite class in college, and I don't like it any more now. But making sure you have at least a sense the numbers and what moves the needles so that you can make some informed decisions, especially in different cash environments.

Ryan Rosztoczy 17:36

Yeah, well, and I mean, if I'm remembering right, you went through that transition, I see the manager. Wow, Elvis was growing pretty rapidly, right?

Nicholas Blanchet 17:47

Yep. Yeah, yeah, I was in the first five engineers there. And then that quickly, got, that quickly escalated, I forget exactly what it was at the end. But we were running multiple teams across multiple different technology stacks, which was pretty excited that needs to be accounted for. And that's you think you learn at once, but it especially at such a at the scale that we're talking about. It's so people dependent. If you have a really great product manager that's really solid at communication, that that's a different problem set than if I'm just picking on product people now. But if you have a product manager that's really great at process and requirements, but a little bit weak on the communication side, your role as a CTO will be slightly different in those two situations. And the process that you want to put out will be slightly different. So the solution, the problem sets are sort of the same, but the solutions can be pretty different.

Ryan Rosztoczy 18:53

I love that nuance. That's what I want. This is what I wanted to ask you about it because that Elvis experience with your growth at Ojai now seems directly applicable in terms of you're not just managing a team, you're managing them through growth, as things are changing, which you're doing again, what in terms of like the challenges around that growth, specifically around the team? Do you could you give me broad stroke percentages of like, issues are technical people or process like, Do you have a feel for that at all, like how much and either any of those becomes a big challenge inhibiting your growth or success?

Nicholas Blanchet 19:36

Yeah, from like the technical side, I think where my head goes really quickly to is managing technical debt through the different phases of growth. And trying to figure out when you should be paying it back. Which technical debt you should be paying back is, is like always a it's always a tricky question. There's no easy answer there and that again depends very much on the situation. You know, looking at when you have product market fit, what part of your application doesn't have high code churn, like, there are definitely some tools there that you can look at, you know how much time and effort you should be looking at your technical problems. And that's not just building the product that's really more about an attendant on that side. I'm like the people and process but I think it's a little bit, it's a little bit different that the people, the people problems, and I'm going to be repeating things that from people much smarter than me, but, you know, it all comes down to who you hire. Now hiring decision is probably the most important and, you know, there's, there's, there's different startup approaches, there's, you know, hire, hire fast, or hire fast, fire fast, hire slow fire fast. But you know, the, the core concept there is, the better, the better you are at identifying skill gaps in your existing team, and filling those with high skilled people is super critical. And that's one of the hardest things to get right. You know, there's a lot of different conversations and great books about hiring the right people. But I would definitely continue to spend as much time as possible, making sure that that decision is made correctly, because with the right people, you know, getting to the third one there the process, it makes the process a lot easier. If you have you can have great process, but the wrong people and it's not going to work. Whereas with great with great people, the wrong process can probably work. And so it definitely makes sense, especially when you're hiring someone to make sure that you're getting the right person. And then the process part, you know, some of it is just iteration, it's listening to the team. I think, I think the process is where experience gets you the most gets you the furthest in terms of like being able to identify what process is going to work. And then being willing to experiment and making sure that your team has the mentality to allow you to experiment with processes well. There's, there's different different people react differently to process changes. And so you need to make sure accounting for that when you walk through different types of processes. Some people be perfectly fine with a process changing every two weeks, some people want it documented in stone for the next two years. And you have to make sure you're you recognize that different personality and from a process perspective.

Ryan Rosztoczy 22:40

In general, would you say? Do you guys have a pretty cohesive, like the uniform engineering culture and process or is it team based at this point?

Nicholas Blanchet 22:51

It is it is pretty uniform at this point. One thing that I'm really proud of and happy about is that there's a lot of collaboration across the across the team. And a lot of that is not just like code collaboration and project collaboration. It's also process collaboration. It's trying to figure out, hey, what's what's working, I did something relatively new at Ohio that I hadn't seen or done previously, which actually worked out really well were reintroduced the role of like a scrum lead, which is not a novel concept, but it's just not one that I had heard of, or is not one that I had experienced before. And that's that's been super beneficial, because that's where a lot of that collaboration comes from. That's where a lot of the structure is, it's also helping with some of the senior engineer burnout that can be symptomatic of the especially the earlier stage engineers, just getting overloaded with questions and management and losing some of their interest in the underlying technology. And that helps their

Ryan Rosztoczy 23:52

Oh, okay, love it. You just been me describe brief summary of like, what that role looks like. I mean, I haven't I've heard about it a ton too. But I've never actually worked at a org that

Nicholas Blanchet 24:07

I sort of felt the same way. I was like, Well, why don't we try this and there's tons of literature and stuff out there on like, what that role can look like? Well, what we've done is basically sort of, there's a lot that goes into running a good stand up, there's a lot that goes into running a good you know, sprint kickoff meeting, a good spring grooming meeting, whether that's ticket grooming or otherwise. And making sure that sort of the the Agile process, that sprint process is working effectively and not actually a process that's just hindering the rest of the engineers from focusing on what they want to do. And having someone explicitly responsible for making sure that they that the rest of the team is is getting the most out of that relatively common sort of cadence has been super helpful and so they they make sure that they're Taking better notes, they make sure that they're doing this, they're they make sure that the, that the sprint is being sort of burned down properly, if that makes sense. So like, you know, in previous roles, it was a combination of the Tech Tech Lead, and the product manager trying to manage that burn, or that Mark manage that burndown chart. Now there's one person, and there, they have a lot of flexibility into how they achieve it, they reduce sprint volatility, they are the person that product has to go to if they want to inject anything into a sprint. And so it's it's taken a lot of sort of the nuance out of that kind of communication, which was super helpful.

Ryan Rosztoczy 25:37

And would you say a key benefit from what you're describing earlier? Is it that it gives, like deep work time back to the engineers?

Nicholas Blanchet 25:45

Yeah, it gives us specifically the tech lead. If you have a tech lead on your team, it gives them a lot of space. So you know, the role of that now has shifted from like managing a sprint, making sure that the backlog is groomed properly, all that stuff. It gives them time to focus on the projects and making sure that architecture behind the different project is set up correctly, making sure that the engineers aren't blocked on a code review or a technical issue. You know, they I'm not sure that it necessarily improves the deep work time because there's so many other requirements for a tech lead to be acting on. But it ideally would give them some of that back as well.

Ryan Rosztoczy 26:24

Okay, and then makes the other focus more high leverage, basically. Yeah,

Nicholas Blanchet 26:29

exactly. And usually, the way that we've had this before is that it's usually a more junior member. So it's a junior or mid level engineer, that gets to be the scrum lead. And one advantage for them is that they get to see the under workings of like how to run a process here. Like that's something that I think a lot of junior engineers don't see enough of, is that they get they get their, you know, one or two story point tickets, and they just try and turn through that instead of like taking a step back behind. What's the point of this, like, why am I working on this? How is this fitting in with the rest of the team? Code reviews, they're, you know, they might be always saying, Oh, the code reviews are super slow. It's like, Well, did you recognize that there's like, actually, six other tickets that need code review, and your tech lead is, is struggling to keep up with that, or whatever it might be. And so it gives them a much better perspective. And what we've seen is that the anyone who is a scrum lead quickly sort of evolves and grows into a higher, higher level engineer much more rapidly than if they don't have that opportunity to learn that structure.

Ryan Rosztoczy 27:30

What a good fit foot like for you guys to match up. Seniority need for growth and mentorship with a need for the overall process. That's just such that sounds like such a good fit to me. I love it. I mean, I could see how direct how that would be directly beneficial to somebody who's Jr, uh, you just the all the habits, you would learn a successful project delivery would be so valuable.

Nicholas Blanchet 27:55

And they realize how important that estimation is. And they're like, Oh, this is why we do story points. This is why we have that conversation. Whereas a lot of times that, you know, they're just like, why are we estimating like, just as like, actually, this is important, because this is going to be communicated to the rest of the organization on when this project is going to be delivered. And they get that kind of insight. One thing I'll just caveat with this, is that throwing, you know, that responsibility without proper backing to a junior or mid level engineer should not well, that shouldn't be done at all. Yeah, I guess what I want to say is like, you need some support structures for them as well. And so that is not like a nothing in terms of a cost from like a time perspective. And so, especially initially, it took a lot of my time to sort of first identify exactly what I was expecting of them, but then also, like, codify that and make it very clean, make sure that they felt good about the process, and also making sure that they felt empowered to make the decisions that they they shouldn't be making, even though they're they might be a little bit more junior from a technical perspective. But that happened relatively quickly. But it's it's certainly should not be thrown thrown to the wolves situation for these. This this granulates.

Ryan Rosztoczy 29:11

Yeah, I love that. Very good caveat. Quick question. I'm curious, I don't you might not know. But do you have a sense for a gather we track we basically track our time on the Engineering Team voluntarily to understand how much we can actually focus on deep work? Do you have a sense for like how much time your engineers are able to spend doing either the thinking about feature development or the feature design itself versus other stuff?

Nicholas Blanchet 29:40

I don't actually I don't have a great sense of that. I think it is very dependent on the person and the the sort of the role within their team and the role that they like doing. I also think it depends a little bit what you would consider like deep work I think it In engineering, a deep work is very, like deep work is obviously good on its own merits for like the deep thinking, the creativity, the problem solving. One of the things, especially in a remote world that I try and encourage a lot of is, is the pairing, it's actually making some of that deep work a little bit less deep and more social, is trying to figure out like, how do you engage the team? How do you make sure that you have an engineering culture when, you know, people might not have seen each other for six months or something like that. And a lot of that, I think comes down to pairing it's so code reviews, even right now, we have, we've started sort of informally developed a process of like going on Hangouts and doing pair code reviews, so that we can talk about the code together. And so, you know, the optimization for deep work is great. I think, in a remote world, it's might be slightly easier to do the deeper work, but you're missing a lot of the social aspects that you do need to have successful engineering organizations. And, and some of that requires you to actually be like, deep work is not the number one priority. It's doing good work in a collaborative fashion. Yeah,

Ryan Rosztoczy 31:07

I love that, um, somebody said that, that really resonates with me. Do you have any idea like, I think we probably will spend about an hour to a week pairing I feel like more might be beneficial. Do you have any, any sense of you got a sense or any of that?

Nicholas Blanchet 31:26

Yeah, so I'd say like, one of our leads, spends, like, about half of his day pairing on various things. Wow. Which, which is great. And, and the other members of his team aren't just love it. Like, they know, like, this is the greatest thing that could happen to me, they're learning. He's a great guy. And, you know, he enjoys it, too. He's seeing them grow, he's able to push projects forward. And, you know, it's definitely a lot of zoom time for him. But I think he gets a lot of energy from that. And then it gets, he gets time to work on his own stuff, too. And he's still a major contributor to the codebase. And a lot of ways. So I think that's he's also improving his feedback loop on the quality of his tickets and the quality of his architecture, much faster than if he just waited for everyone to finish their code and push it out to GitHub.

Ryan Rosztoczy 32:16

And I assume this is like, this is like a probably very senior experienced engineer, and you're trying to diffuse his like knowledge, essentially, in culture is at what's gone.

Nicholas Blanchet 32:26

Yep. Yeah. And he, I mean, he volunteered for it. And I've encouraged it. But yeah, that was a more senior. Furthermore, juniors, like they also do it too. Like they They love having that one of the things that they've started doing a little bit more frequently is doing the code reviews with each other before bringing it to the more senior engineers are like, hey, like, can you just check this for me? Like, what do you think of this solution? And that's been cool. And it's just like, yeah, like 50, minute calendar invites are perfectly fine. And normalizing that a little bit more, especially within an engineering, I think, is good. Outside of engineer, I think that's normal. But for engineers, because of this focus on deep work, you lose some of that, you get the notation of like, do I want to interrupt their deep work? And so there's been some conversations in retros, and such about, like, how do we time this properly? And we've generally been respectful, and if anyone's having, you know, an overload, and they make sure to flag it, and they're like, Hey, can we try and schedule this earlier in the day when I have, you know, more of these, and then I can get to that deep or from the afternoon?

Ryan Rosztoczy 33:29

I love it. That's, that's really good to hear. And something for me to think about? Yeah, not over indexing on, on deep work in remote environment.

Nicholas Blanchet 33:39

Yeah, I think the remote environment is a key part of that, like in the office, you know, you do you almost have the opposite problem. And so the focus on deep work is very real. In a remote work, you know, you can take a look at some engineers calendars, and it's hopefully pretty empty, especially at the ice level. So you want them to engage a little bit more actually.

Ryan Rosztoczy 34:03

One thing you mentioned that was on your mind the other day, that I think is a really interesting topic for technical founders is the idea of choosing your technology stack. So I was curious. I mean, if you are open to maybe you could walk me through some of those decisions with Ohio. What's your guy's sack? How have you thought about making those decisions? Any like learnings?

Nicholas Blanchet 34:28

Yeah, so the technical stack of an early stage startup is almost entirely decided by by by the technical founder. And so it's, it feels there's a lot of sort of weight there. And it's very interesting. One of the things we had previously spoken about was like the build versus buy, which is which is part of the technical stack conversation because what you build that needs to be backed by some Technical stack, and then what you buy is going to be an integration point for you, most likely in a major way. And so those are, those are things that it's really good to develop sort of a strategy for how you approach and everyone will have a slightly different strategy. I read a really good article recently that it's like, when you're building Build, Build boring, you want to be building, you know, on on technology that is robust enough that a lot of people would consider it boring. And it's very hard advice to take, especially in the early stages of a company, because you're, you're pumped up, like you want to build the next level of technology. And there are definitely some some startups and some ideas that would require sort of really pushing the boundary there. Ohio is not one of them, we did not need a new framework or a new language to be invented for us to be successful. What we needed was something that was stable, that was reliable that we could find high quality engineers with experience. And and so we, you know, one of the things that we chose was Python early on as the core of our back end technology. Obviously, you know, one of the largest programming languages out there has robust frameworks in a lot of way, almost any sort of platform as a service supports Python out of the box super easily. And so that was a relatively easy decision, also, because of its support of the different data parts that I previously alluded to. And so yeah, Python, and then we went with Django, which is the largest, you know, web framework on top of Python at this point, flask. And obviously, there's a couple other ones. But that gave us the most out of the box functionality that we could build quickly on top of

Ryan Rosztoczy 36:49

why that's really resonating with me, right now, one thing I never thought about, if you combine the thought of stack selection with build versus buy, is a ticket to the extreme. Let's say in a situation where you want to do a lot of buying like was it gather, like we're not gonna, we're not trying to write a bunch of new functionality, anything that's adjacent to what we're doing, we want to just pull in, maybe it's like a chat feature or payments or whatever. Like, we don't want to write any of that ourselves. If there's a tangent there, though, which is, if you use a ubiquitous language and framework, like for us node for you, Python, you can pull in, I mean, there's packages that wrap libraries that make the library much easier to deal with, then wrapping that, you know, the fetch and, and the API yourself. And it just seems like a small thing. Because it's not that hard to write code to communicate with an outside service. But even if it only saves you a day or two at a time, those things compound, when you end up pulling in 10 Plus tools over time, something I just never thought about how easy is it to pull in things you want to buy? versus maybe something that's not so pervasive like elixir in my mind, you know, you might have to write a wrapper for each of the services you want to use. It's just a little bit more you have to add on. So I think there's a lot to that decision. And it's also like a very one way door, like, once you once you're set up and going, it's not a small thing to decide to change any part of that stack.

Nicholas Blanchet 38:30

Yeah, that's great. And I think that that brings up an analogy, or like a question that every decision should sort of be put in front of it's how easy Can I choose another door? Once I walked through this one? It's okay. If I make this decision today, what's the switching cost? What does it take to sort of switch change my mind, and if the idea of changing your mind is high cost, you want to take the time to make that decision now correctly. And it's super important to take your time and do it because you don't want the cost of getting it wrong as much higher, whereas some some decisions, it's much faster to change. And so figuring out which ones you can try and make informed decisions for sure, but make those decisions faster, because you know that that switching costs is a little bit lower. And that's it's sort of what you're getting at, there's like once, if you're writing more code, the switching cost is generally lower pulling in a different package integrating with a different API. If you're buying something, no switching costs tend to be a little bit higher. And so it makes more sense to be doing the research on what you're buying and making sure that you're informed. informed about which vendors the best option there, especially if you're looking at a larger scale, where there's vendor contracts and stuff like that, that you're gonna have to be signing.

Ryan Rosztoczy 39:51

Okay, so then tell me that maybe the maybe I'm sort of growing in my interpretation of a question I asked you earlier, which was like vote how much What percent of growth issues you would think came from technical process people through the lens of like one way doors, even though refactoring and technical changes are a pain, it's still if the three things that compare our technical debt process that and people that tunnel, that's probably the easiest one to reverse and then probably process and then probably people, which means that the amount of time you're spending working on those problems is probably inversely correlated, like you're probably people is where most of the time is it? Does that resonate with you? Is that true, or that

Nicholas Blanchet 40:38

that certainly resonates with me like people using that analogy is the hardest one to reverse. Even when even when you're doing performance management and having those hard conversations and trying to encourage growth, that still is the hardest decision to reverse from an emotional level than anything else. It's much easier to switch a Python package obviously. Like, that's just like, so true. And so take your time on the people, like you want to make sure you're getting those crack. And, and you're trying to help them be as successful as possible. On the process, I think it's, I think it's a large step from the people side, like the process can be pretty easily changed. Again, it ends on organizational side. But you can also scope processes and process changes to different teams that are more receptive or more agile from a process perspective, and then roll it out slowly. A lot of that is like, a lot of that is how well you're communicating as a leader. The better you communicate as a leader, the better process changes are going to be rolled out across your organization. So that that says like, relatively easy, I think people are process and technology choices are probably interchangeable in terms of like, which one needs the most time I think there are definitely some technical questions that should be considered deeply. Knowing that refactoring and making some of those changes is is hard and costly from a time perspective.

Ryan Rosztoczy 42:14

That okay, I'm just curious your the way, you just talked about process change of Navy inserting a process into more receptive or adaptable team first and then extending that just hits me like you're talking about refactoring like, that feels like a software engineering thought, like, Okay, I'm gonna establish this pattern here. And then we'll we'll have it take over the COVID. From there. Did that influence that thinking? Or where did you get that from?

Nicholas Blanchet 42:44

I think that's, I don't I probably I obviously lean on some of the technical learnings. But I think that's an experience thing. A lot of people are just just are less receptive and finding the teams that like incubating the new ideas. Or the those are the ones that you should you should be testing with. You know, it's just like your early adopters of your product. Those are the be the ones that you should invite to your beta and not the ones that you know, are that that don't like change that email you when you change your UI a little bit. You want to be talking to the clients that are more receptive to the change first, and then is the same type of structure there, too. So I think that that pattern can be applied in a lot of ways, technically, and, you know, in terms of just how you roll things out and feedback that

Ryan Rosztoczy 43:31

Yeah, that's great. That's super great. Seems obvious. Yeah. I had not really thought about that. Okay, well, and then so just like to kind of leap into this, you know, talking about technology sec, and build versus buy influences that have you come to a place where you do you feel like you've got a good grip on you either a framework or something more organic for making decisions around build versus buy.

Nicholas Blanchet 44:06

I think I've continued to refine a framework, whether it's or not, I think time will tell. And that's one of the harder parts is that a lot of these decisions cannot be evaluated on like a daily or weekly basis, but they're generally going to be evaluated in the success or failure of your startup. And that makes it feel like pretty high stakes, but that's what you're doing as a founder. And so you have to sort of get used to that. But yeah, I think there's you know, there's a couple of decisions that I made that are we're definitely mistakes early on, like one of the decisions that I am constantly paying for it in a couple different ways was our our client side application is built in React, which is very stable and the engineers love working with and then because I had felt view was going to be easy for me to learn and be able to have sort of more of a full stack approach from a technical perspective, we introduced view as one of our sort of internal admin type of front end frameworks. And that was certainly a mistake. I'm one that could go back three years and change. For that, for everyone's sake, it would have meant a little bit more slowness upfront, but it would have meant a lot less pain right now. And we're refactoring that that's definitely part of what I consider allies technical debt, and early 2023, we should be stabilized on React explicitly, or exclusively.

Ryan Rosztoczy 45:37

Well, so what I love about that, when I was at least with my brother, he was the technical founders, the first startup we did, and he had a thought to the importance of like how nuanced these decisions get. I think they started with Django, which, for you guys makes a ton of sense for the types of problems you're trying to solve all the all that stuff. For them, it was a big mistake, they I don't think they're quite realized at the time, the need for a massively scalable, distributed system that was gonna come their way they needed something that could handle tons of data coming from vast geographical distances all the time and to handle it really well. And which that's it pythons not great at that, for them ended up being after multiple tries elixir. But I guess the nuance here, like when you're talking about view, that would seem like a very common sense way to go. Also, I but sometimes these things you don't realize the fit of the tool to the problem you need to solve until later.

Nicholas Blanchet 46:47

And I don't think there's anything inherently wrong with view, just like there's nothing inherently wrong with Django for the like, it's, it's all situational. Now with with our Django platform, we hired a bunch of great Python and Django engineers. And so they were, they're able to bend Python and Django, to what we needed to do relatively quickly, efficiently. With a view, almost all front end engineers now are comfortable, very comfortable with React. And so we never developed internally, like a skill set around view and how to build that properly and scalable. And, you know, until probably very recently, we didn't have a front end engineering organization that could support two different languages. So in two different frameworks. And so that's why it was painful, not anything inherently wrong with view. It's just, we weren't, it wasn't right for us. And it isn't right for us right now. So that's, that's when it gets a little bit nuanced. Obviously, three years ago, I probably could have seen a head a little bit, but that was a hard thing to have sort of identified. And then obviously, how you react to that is, is important, too. But just like You're like the the decision to go with Python, for a massive, massively scalable solution. You could see it working out either way, you know, it's easy to look back and say like, well, obviously, you needed something that's, that's performing in a different way. statically typed language or elixir or whatever. But, you know, pi Python, there's definitely some solutions out there, that could have gotten you a lot, maybe a lot closer or wouldn't wouldn't have worked at all from day zero. So

Ryan Rosztoczy 48:26

yeah, and there's nuance in there. I think what I'm hearing from you, too, which is like, especially around languages, probably mostly aware, the level of experience your team has in that thing can be a big change, it can make a big difference. If you have an expert Python engineer, they can probably build a system that will work as well as, you know, something else designed specifically to solve that problem.

Nicholas Blanchet 48:52

Yeah, exactly. What one of the things that you should also be evaluating is like, what blind spots are you developing as an organization because you don't have different types of experience necessarily. So like, one example that I'm looking at right now is, we don't have an event driven system. But a lot of what I'm sort of seeing from a process perspective is event driven. And so we haven't, you know, hired, you know, experts in event driven, we have one senior engineer that that does have some experience. And so I've been picking his brain trying to learn more, to make sure that we're not sort of making a mistake in how are architecting that's just because we don't have that experience. And I think, to some degree, that also has to do with the technology and build bias solutions is like, the type of experience that you have is going to determine, you know, preset the different types of tools that you look at. And so everything that we have in our back end is Python. And so we're going to look at Python packages first. Whereas there might be a much better solution someplace else that we're just blind to because we don't have that experience. We don't have that person that's saying Like, actually, you know, what's really cool is that elixir solves this problem in this way. And so maybe we should actually think about restructuring as an end, it's important to start getting those opinions especially as, as the tech base continues to grow, but then you need to make sure you can support it.

Ryan Rosztoczy 50:16

Oh, my God, dude, I love that so much Dishman, the whole conversation, even though it's great in general, this idea of tooling, blind spots, and how biased your decisions will be based on just purely what you know, and what you're blind to, is a game changer, and maybe something for me to really think on. And investigate their big nuance. And what you said is like, it's not even if you could figure it out, let's say like a possibility space of tools to use, and you can identify the problems to that they would each solve Well, which you can't get to, but let's see, could there's still the problem of how much work will it take to go out and adopt and use that tool and then support it? So it's a super nuanced issue, but I love that I've never even thought about that. Like,

Nicholas Blanchet 51:14

one thing, you know, engineers have a large tool set in front of them, just naturally, they can stay, we look at the world from a toolbox perspective, or like, we have all the tools, especially from a software perspective to like, solve these things. But one thing that highlights I think this this, like blind spot is, is people that are generally less technical, I have a great conversation with someone on our operations team, really smart guy, like really good at what he does. And I was walking, he was walking me through some of the processes he had put in place. And it had to do with like, basically data transformation. And I was like, I started listening a little bit more closely. I was like, okay, like, this is interesting is like, yeah, so what we did is we actually, we have someone that's like, basically, like, I'm simplifying this a little bit. But by like, we we don't know how to do this properly, is what I heard, even though that's not what he said, because it was like a very simple data transformation. I was like, Well, have you looked into like using a local tool like Zapier to automate this for you so that you don't have to do that step is like, Oh, I didn't even know that tool existed. And he was like, he was like blown away that Zapier didn't exist, which to me, I don't even know what Zapier was, I feel like I was born with Zapier. I don't. I feel like it's almost second nature that I was like, Yeah, loco, like Zapier, like there's a bunch of other tools in that space. And for him, he was just like, Oh, my God, I can use this for all these other things too. And like exposing him to that one tool meant all these other problems were now like, much more easily solvable. And so he's been paying me every day asking, like, Can you hook this up? Can you hook this up, I'm like, I'm gonna teach you how to use Zapier. And now you're gonna solve your own problem. Example, like a tool that you might know very well, but others don't. And so like sharing that tooling, and I think, not to just harp on this forever, but I think one thing that I've been trying to figure out a little bit better is, you know, local development, the tools that senior developers have to build good software locally, is dramatically different in a lot of cases than what the more junior engineers are using the biggest, like, you know, some of the biggest accelerants that we've had is when we have those, those pairing sessions that I was talking about earlier. And the senior engineer was like, why aren't you using like, linting in your code editor, and the junior engineer was like, Oh, I thought we had to run like the lint command every time he's like, no actually install the plugin. And it's like, this is this doesn't have to be a high tech conversation about tools. It's like a plug in here, a plug in there. And all of a sudden, you know, this junior engineer was, you know, writing twice as much code twice as fast because they didn't have lint failing on them every single time.

Ryan Rosztoczy 53:58

Yeah, I mean, just to keep it with, like, go on that for a second. The thing about local development is that that is where I feel like your highest gain for reducing feedback loops exists. And if you use it properly, you can get them down immensely. And if you don't, you're still stuck in this space of I have a lot of extra time to do stuff that really resonates with me.

Nicholas Blanchet 54:24

What the feedback loop comment that you just made really resonates with me like the number one thing Junior in any engineer can do is make sure that that feedback loop is like fast as possible. And I think that is applicable locally and in these you know, in every situation that we're talking about is how do you get that feedback loop tighter so that you know it just increases your learning rate exponentially?

Ryan Rosztoczy 54:46

Yeah, maybe it helps me I've been trying to think in my head like where's the balance between like we can all you can all write commands to make things simpler to reduce work, whatever, but like, at some point, spending an hour automating something is not worth it. You know, when you're gonna do it once a week, and it takes a second or something like that, and I'm always like, is this worth, you know, doing a little thing, right, like writing a little script right now, to automate this, but maybe the direction my brain will go with that is if it speeds up, if I can speed up local development by doing it, that is probably worth it or take something that isn't currently doable locally, and shift it, that's probably also worth it. Yeah, super in the weeds.

Nicholas Blanchet 55:28

What, but I think that's an important conversation, because like those feedback loops are critical to growth at every level, locally, or, or anything else. One thing that I'd add to that conversation is, if it's taking you an hour to write that script, and it automates a couple, maybe a minute or two a week or a month or something like that, the payback period is probably still going to be pretty good. Where a lot of people will get into trouble is if they write that script for an hour, and then every week when they run it, they need to maintain it for five minutes. And so like where I see the biggest mistakes made here is not that initial thing, it's how much or perceived the perceived maintenance of that tool is. You can qualify that as technical debt or whatever it might be. But if if you write that script, and then every week, you need to change it because the input structure changes or the API changes or whatever it might be. That's not a, you didn't develop a scalable solution you developed, like another layer of abstraction on top of that five minute process, which might be more interesting to you. And there's advantages to that. But you're, you're running into the same problem. You're now just spending that five minutes maintaining the script, instead of actually copying and pasting or whatever it might be. Yeah. So going back to the Zapier example, like if, if this if this person, I'm not gonna mention his name, but if he needs to maintain Zapier for the same amount of time that would take him to like, copy and paste things back and forth, didn't actually gain anything. He just introduced a new type of work. And to some degree, I feel like that's sort of what all engineering is at some scale, but maintenance maintenance is costly.

Ryan Rosztoczy 57:09

Oh, man, I love it. I love it. I love it. Yeah, it's it's just another layer of abstraction that makes it feel like things are are more manageable, but they're really not. It's just one that your brain agrees with. Versus does this fundamentally remove work from the equation? Love it. Love it. Love it. Yeah, I mean, but I mean, that's part of our job, right? Like, we have to create more work for ourselves as engineers, because we systems and keep getting more efficient. Now we have AI to help us if we don't just create unnecessary layers of abstraction won't be out of shops.

Nicholas Blanchet 57:45

I guess that's true. Yeah, no, it's true. You got to make that layer of abstraction so that only you can do it now. That's that's the only way now. I'm kidding. That's not what makes your

Ryan Rosztoczy 58:00

the key to being a technical founder

Nicholas Blanchet 58:04

is making everything so confusing that only your specific group of engineers can actually do it. Yeah. You should, you should very much be going for the opposite. Because I promise you as a founder, and as a technical founder, there is plenty of work to get your business off the ground that you do not need to be spending time reworking or making things too complicated for yourself.

Ryan Rosztoczy 58:27

I love it. Love it, love it. Kind of freeing to as a software engineer to realize that it's not even worth spending time on a lot of that. Ah, really quick. We're as we're kind of getting to the end of time, you're actually how am i Are you do like five minutes, or do you need to wrap up right now?

Nicholas Blanchet 58:47

I got a couple more minutes. Yeah.

Ryan Rosztoczy 58:48

Okay. I do want to just touch super quick, like you had mentioned, I just think it's quite timely right now you had mentioned what it was like to lead through a changing startup environment where a year ago, the consensus in the industry and among startups was essentially like grow, grow, grow, get growth at all costs, and we've seen a shift there. Can you just talk a little bit about like, what that's been like for you?

Nicholas Blanchet 59:23

You're measuring like that the shift that happened? Maybe like four or five months ago. Inflation reared its head and yeah, I think what's what's the most interesting for me is and I have a little bit of a business background, but like, the idea that margin matters and that like the unit economics matter, is something that feels so natural to almost everyone. If you talk to people outside the startup world, and I was having a Christmas party as I was talking to someone that's in construction, and he's like Yeah, like margin, like, yeah, your margin matters, your revenue matters. Like you guys weren't taking that into account. Like, I was like, for the last eight to 10 years, that hasn't really been part of the equation, like for early stage high growth companies that are that are generally VC backed, that hasn't really been the equation, it's mostly about how fast can you grow? And there's a little bit of efficiency, like how efficient you are getting that, but, you know, six months ago or whatever, that that's been flipped, so I've actually, like, what, what's what's, what's the speed at which you can be profitable? And how much growth you actually need to achieve? Do you need to have to achieve that. And it's, it's been, I think it's a healthy, even if it's a painful, but a healthy, sort of, what's the word I'm looking for here? Correction is I think it's a healthy correction for the focus is obviously painful, there's a lot of turmoil right now. And obviously, that the job is being lost is is not fun for anyone going back to like the things that are hard to do. But it's, it actually makes engineers and the technology that we build higher and higher leverage. The the work that we're doing on the engineering side, is the highest leverage work that can be done within a startup, right? And so it will bring increased focus on how you're achieving your goals, how you're looking at what you're building, the product prioritization is going is already is already tighter, like you are not going to be able to say let's build, you know, six things or 12 things are let's to xr roadmap, because we're expecting to hire a bunch of people, you're going to have to be like, what actually matters? What about our product is actually going to move the needle here. And it's going to be a great it is has already encouraged a lot of great conversations about what are you building? Like, what do you want to be building? What what's unique about your company? How are you approaching these conversations? And it's pushing a lot of the focus sort of away from the reactionary like, Okay, well, we don't have to be perfect about this, because we have the growth here, the growth hides a lot of what what would be inefficient in, in, you know, the past 10 years or the past eight years. And now we're looking at like, Okay, now we can't hide behind the the top line numbers, how does the actual functioning of a business work? And that's, that's awesome. I think that's, like, really cool to look at. And while a lot of us like engineering, it's about efficiency, it's about how do we make sure that everything is efficient from user workflows from, you know, the different internal automations that you might be able to support? And so I think that that, it's a very, it's a hard one to have, obviously, it's a hard adjustment to make. But it just means that what we're doing is even more important for our companies to be successful.

Ryan Rosztoczy 1:03:07

But yeah, I ball what I love about that, I mean, it sounds like your vision for leading through that change is a very positive one, which is like, this sounds very motivating and clarifying for you and your team.

Nicholas Blanchet 1:03:21

Yeah, I think one of the harder parts like the the, obviously, if you're going through layoffs, that's going to be hard. But one of the harder parts is is D prioritizing some of the technical debt that engineers have grown emotionally attached to, if you are reducing your, your, your capacities to building if you're reprioritizing, on the super important things, a lot of this technical debt conversations is gonna come back, and it's gonna be like, Well, is this actually an important part for us to be focusing on? How do we make these trade offs and it is going to make some of those trade offs not worth it in this environment, you're just going to die. This is technical debt that we're going to have to assume for a while, because we can't just grow out of it, we're not growing out of it, we're going to live with it. And we have to figure out how to do that properly. And that can be demotivating, if you're not structuring that conversation correctly, it can be really demotivating if someone's like, we really need to fix I'm going to make something up but like our CI process, we have a great CI process. But like if your CI product process is broken, as decided that well, that's actually a very bad example because I think CI going back to our feedback loop conversation is super important to to like get quick. But there's there's a million other pieces of technical debt out there that that someone will say like this is a very high thing you're gonna have to say no to that and that that's also true on the business side, but leading engineers do that know can be a little bit more challenging.

Ryan Rosztoczy 1:04:51

Yeah, I love it. No, it's it's really cool to hear you talking about that. I think it makes a lot of sense to me. Cool. Okay, well So one question I've been asking everyone. So I'm curious if you've, if you've got an answer for this is just any piece of advice you'd have for somebody who is looking to start a startup maybe just got started. I know a lot of people who listen to this are right in that space. So any advice for, for technical founders who are just getting started?

Nicholas Blanchet 1:05:25

Um, I mean, I, it's, I think it is a little bit hard, because I feel like I'm just getting started too. Even though I think you could argue that I've done a little bit more than that. But it, it always feels like you're just getting started to some degree, it always feels like you're, you're you have a new problem in front of you, that it's, you know, there's an insurmountable object of some sort that, you know, you might feel as unique to yourself and your situation. I think that the truth is, is that it's, it's not necessarily like it is, there will always be another growth problem or another conversation, that's going to be hard. And so it's figuring out sort of where you get your energy from, where you lose energy quickly, and making sure that you're organizing yourself your habits around those two areas, because the most likely reason you fail is because you lose energy, obviously, if you run out. But if you're losing energy every day, you're just not going to make it because there's going to be another question, there's going to be another hard day. And the hardest part about founding a company is, is getting through each of those every single time, you cannot stop. So you need to make sure that you have the energy to get through it. And for me, a lot of that is coming back to our conversation. It's finding those structures that make things take less energy, it's figuring out which of these processes, you can reduce where you need to where you can afford to move fast, because that tiring decision can be made quickly and efficiently. And then where you need to like actually, take your time. Spend the time doing doing the fun things I like one of the things I still try and do is write some code every day. I don't get to it every day. But I try and get to a once a week. And that gives me energy. It makes me reengage with the codebase. And it makes me feel empathetic for the engineers that I've told you can't work on that technical debt project because I feel like I like I'm like this is this is a problem. You're You're completely right. And I think it helps them respect the fact that I feel I really do actually feel them. So anyway, yeah, keep your energy up. It's hard. It's hard. It's very hard. Find, find where you get that energy and just keep going with it.

Ryan Rosztoczy 1:07:41

And that's a wrap. Thanks again for joining me. And I really love at the end Nick's comment about finding what gives you energy and keeping up that practice. So his practice of coding I think is a phenomenal one. Thanks, and we'll see you next time.

View Details

Welcome to another episode of the technical founder, the show where I meet with engineering founders and we deconstruct and demystify the science and art of building technology businesses. My guest this episode is Julianna Lamb. Julianna met her co-founder Reed McGinley-Stempel while they worked together at Plaid - and they maintained a friendship and correspondence as their careers evolved. This proved incredibly fruitful when, during covid, they realized they had a big opportunity to change the world of authentication.

It has been amazing to watch their team scale and improve the product and the engineering behind it. Kudos to Julianna and team - I think you will enjoy this one.

‎The Technical Founder: Julianna Lamb [CTO, Stytch]: Decision Making, Founder Market Fit, and Building a Company From The Start on Apple Podcasts‎Show The Technical Founder, Ep Julianna Lamb [CTO, Stytch]: Decision Making, Founder Market Fit, and Building a Company From The Start - Jan 18, 2023Apple Podcastsulianna Lamb [CTO, Stytch]: Decision Making, Founder Market Fit, and Building a Company From The Start 0:00/53:041×Highlights[06:29] The beginning of Stytch and Founder Market Fit

[17:12] Growing effectively through hyper scale

[32:38] Effective self-management through ups and downs

[40:12] Rules of Decision Making

[50:34] Golden Advice for Future Founders

Transcript (Provided by Otter.AI)Announcer 00:12

Welcome to the technical founder

Ryan Rosztoczy 00:15

Hello again, this is your host, Ryan Rosztoczy. Welcome to another episode of the technical founder, the show where I meet with tech founders to deconstruct and demystify the science and art of building technology businesses. My guest today is Julianna lamb. Julianna is amazing. She's the CTO of Stytch Stytch is an auth platform that provides simple, really easy to implement API's and SDKs. So developers can set up flexible, secure authentication in minutes, we use such a gather we have from the beginning and love their product. For anyone out there who's had to build, rebuild or evolve some homegrown system like I have, you'll understand just how useful this product is for developers in November of 2021, Stytch raised a $90 million, Series B, which officially made them a unicorn. What is incredible about it, though, is that less than a year earlier, they hadn't even raised this series A yet. Talk about hypergrowth.

Julianna Lamb 01:33

Yeah, Stytch is an identity and access management platform, we started the company sort of leaning into modern authentication options like passwordless authentication, we now support sort of a whole range of different products, including passwords themselves. The sort of thesis behind Stytch is that authentication is really frustrating, both for developers to build but also for the end users interacting with it trying to log in to their various applications. And so we wanted to make it much easier, both for people to log in, but also for developers to build their authentication, do so in a way that is secure, it's keeping the bad guys out. But it's making it really easy for those good users who want to get value out of their products, etc. To get access and engage with with the product that you're building. And let you focus on that, instead of spending a bunch of time you know, trying to become an expert in half a dozen different authentication products and spend a bunch of time researching that building it, maintaining it, etc. It will offload all of that to us and, and we handle it all. And you get to Yeah, build whatever is interesting about the product that you're trying to build instead of boring authentication features.

Ryan Rosztoczy 02:53

Okay, so couple of things. We don't spend the whole time to choose a product, but I am a huge fan. So I do want to sit in this for a second, which is, I mean, we've you guys, we've used you guys, since the start, like we needed flexible solutions implemented fast. Found you guys super easy to implement great documentation, all that stuff. So huge fan. But when you talk about like handling and keeping the bad guys out and letting us do what we want to do, I've sort of taken that for granted. Like how it changed my mindset. Because before and like earlier gatherer, I was always worried about like, Okay, I'm gonna implement this, where are the holes? What's the problem I'm causing, like, you would almost default, there's this habit of defaulting in the industry to like locking down the gates. Because you just don't want to be at risk. And you don't really understand to a high degree of complexity, like how things work. So but because you guys handle that, and I sort of have faith in your solutions, like that's your bread and butter. When we're thinking about like, auth, we're not thinking how do we keep people out? We're like, how do we do this as flexibly as possible? So it's easy for people so that we can give users what they want. And it's like this whole change in perspective. So anyways, yeah, just is pretty mind blowing. So love what you're doing.

Julianna Lamb 04:12

Yeah, I think we're selling authentication products, but also hopefully selling some peace of mind as well, both from like the security perspective, but also the like, reliability perspective, like making sure that that email magic link that your user is getting is landing in their primary Inbox tab at the time to inbox is really low. All of those like last mile details, whether they be on sort of yet the security side of, you know, thinking through every single possible sort of attack vector for account takeovers, or thinking about email deliverability like all of those in the weeds details are the things that we live and breathe every day and you shouldn't be expected to live and breathe. A very different product and you know, thinking about your Um, and user experience and optimizing for that.

Ryan Rosztoczy 05:04

You also it kind of hits me as I was talking to Gary from Expo. And he was saying their long term vision is that analytics is in this space where it's going to be used by most businesses, but it's not going to be any of their primary core competency. And so that's kind of the space that they're gearing up to play, it feels like you guys are in the exact same space, which is like, probably everybody is going to use you. And no one wants to go that deep down that rabbit hole.

Julianna Lamb 05:32

Yeah, definitely, I think they'll like, market is so competitive for whatever you're building today that anytime you can save on building something that isn't undifferentiated is super valuable time to spend on your own product, your own users and sort of optimizing that experience and investing in that. And so I think we have already started to see a lot of this sort of like, shift towards people using more API companies, platforms, etc, as building blocks for their product so that you can get to building the interesting stuff that you're trying to build faster and spend more time on that.

Ryan Rosztoczy 06:14

Love it. Okay, so let's take a step back. So I don't actually know this. When, like, Let's go early days when you guys you and read or thinking about Stytch. What was that like?

Julianna Lamb 06:29

Yeah, so Reid and I had worked together at plod. I was on the engineering team there. And he was a product manager. I left plod in sort of spring 2019 to join a company called very good security, where I was a product manager. And so after I left plaid, Reid and I had stayed friends, we basically had like a monthly coffee catch up on the calendar. And so we would get coffee and talk about whatever was sort of top of mind for us. And so one of those coffee chats, we were both complaining about building authentication, I was working on a project at VGS, to get rid of auth zero and replace it with a solution built on top of key cloak, which is an open source tool. And Reid was working on building some new authentication features at plaid. And they had sort of looked at the market for authentication vendors, and they ended up building a lot of this in house. And so we were basically like complaining about how frustrating this was and how there wasn't sort of, you know, the vendor on the market that solved our needs. Here are two separate companies facing similar problems. We were basically like, Why isn't there the stripe for authentication? Yeah, it's really developer friendly, easy to integrate. Um, that was December 2019. And then I mean, we kind of like left for the holidays. And they thought a little bit about it, but not too much. And then back in SF in January, I think we had like another conversation, we were kind of like, maybe there's something here, I don't know. And then we started like kind of floating the idea with people. And basically continue to do that. Pandemic hits, and everyone is now sitting at home, right and looking for things to do. And so I think that made it really easy for us to be like oh, like, friend that we haven't talked to in a while want to like get on a zoom call with us and hear about authentication and like, tell us your problems and see if we can help solve them. And so we ended up spending sort of a bunch of time, while we were all locked at home, basically kind of doing this customer discovery, talk to someone and they're like, oh, that's like a really interesting idea. I have this friend that ran into this problem, like, you should talk to them. And then you sort of like keep doing that. And I think momentum just kept building where we kept hearing like, frustration time and time again, with however people were doing authentication. The like end result of what that was that they were building that it was frustrating for users, right that they were struggling to log in, but they were also investing all this time and building it and we were like, yes, that's that's the problem that we should be solving. And so ended up leaving our jobs and fundraising in June of 2020 and started the company.

Ryan Rosztoczy 09:34

Okay, so how did that part happen? Because, like, hard enough to, you know, I mean, get to a point where you feel comfortable that you've got a big problem and you want to focus on it, but then you need the time to do it. So how did you go from Yeah, let's do this to let's have the time like did you raise like a friend's friends and family or seed round or what did that look like?

Julianna Lamb 09:56

Yeah, I think we didn't really Have a plan. When we started doing this. We had this idea we didn't bested some and kind of like building out a rough pitch deck, because we were like, Oh, we're gonna start this company, we should have a pitch deck, I think that's what you do. I had spent some time sort of like playing around and building a very, like, rough call it prototype of some of these products. But it was pretty, pretty minimal in terms of what we had built. I remember Yeah, it was like a Sunday. And then I think, May of 2020, or something. I was like, sitting, I was sitting at my parents house. And I was like sitting outside, just like writing a bunch of code. And that's when, yeah, a lot of sort of, like the initial product ideas got turned out. And so similar maybe, to how we kind of had those initial conversations, I think we were like, oh, maybe we should, like, get some feedback on our dock. And like, see what our friends that are VCs think about this, because like, we're going to do this, we should probably go raise money, and started to have some of those conversations. And I think pretty quickly, um, people were like, introducing us to like partners at their firms or like other VCs that we should talk to. And then like, all of a sudden, we were raising a seed round. And I think we like kind of stumbled into it. We definitely had done a lot of prep work, but I don't think we like knew what to expect. We'd never fundraised before, we didn't know what that was going to look like. It's June 2020. And so I think like, times were kind of wild. Generally, one of the benefits of fundraising on Zoom is that you can do it really quickly. Because being from zoom call to zoom call, you don't have to like track up and down Sand Hill Road. And people's schedules were relatively like free, I guess, compared to maybe normal times. And so yeah, I ended up raising a seed round that benchmark led in in June. And then I think, after that, it was kind of like, okay, we raised this money, like, the two of us aren't building this company, like we raised money to build a team and company that's going to like, build this product. And so started focusing pretty quickly on hiring engineers and sort of building out the team. Before we kind of like dove back into building product after,

Ryan Rosztoczy 12:34

okay, so I do want to talk about this, because that's so just so crazy and good to hear. Because of I look at like your guy's history. I mean, while we were using it as paying attention, I would say, Wow, these guys are the gods of fundraising, like you, like you must have gone in already with tons of experience and knowing what to do. But that's so organic. And so let's just do it. That's amazing to hear.

Julianna Lamb 13:02

I think they're just like a lot of what I would call founder market fit. So I think we had spent so much time thinking about these problems, both Claude and then at BGS, as well. Um, and so I think it all happened fast. But like the build up to that was many, many years in the making of like, building our sort of like, opinion of what authentication should be, what product we were going to be building. All of that we had pretty high like conviction in and like depth of experience in. And so I think that enabled us to kind of move pretty quickly and to continue to move really quickly. Because we kind of like, knew what we wanted to build from the beginning. And so yeah, I think it can seem like wild maybe from the outside, but you like sort of peel it back. There's like many, many years of like foundation being built before we actually like went and did this.

Ryan Rosztoczy 14:01

No, I love it. That's awesome to add. And it just reminds me so much of the expo guys. They're iterating through ideas, trying to figure out what they're going to land on pivoting, pivoting, pivoting, but they were all data engineers or using a ton of data at McKinsey, and they landed in in the data space. That makes so much sense. It's just so good to hear. Okay, so more questions and because I want to get to one of the most impressive things for me with you guys, is that, as we've known you, if anything, it's felt like your feature velocity is increased, which is you've raised a bunch of money you read you raise 30 million series A and July 2021 and 90 million Series B five months later. I would expect doing that that you guys essentially ground grind to a halt. You're focused on scaling growing the team. You just kept coming up with all kinds of products. How well Kenny. Oh, I guess with your upcoming, your upcoming talks you're doing that might be a big part of it, right? engineering teams. But yeah, like, let's go there. How, how do you do that? That's great. Yeah.

Julianna Lamb 15:11

Yeah, I think it's something that we spend a lot of time thinking about. I think it's also really important for us to strike the right balance of shipping new products, but also investing in sort of foundation, things like reliability of our platform, etc. And we're critical infrastructure for our customers. And so we can't, like move too quickly and break things. Because if we break things, then our customers end users can't log in. And that's really bad. And so we take that very seriously, as well. And I think that's like, a really chat, a really big challenge to sort of manage prioritizing both that like high velocity, culture of shipping new things and sort of consistently building new products, but also making sure that we're reserving the right amount of time to work on things like testing failover, all of those types of reliability investments. I think, something we were, I guess, maybe a little worried about doing the series B was that it would make our team maybe feel like we've kind of made it in a way that I don't think we had yet. Right. And so I think that's something that hasn't really been the case. But I think it's also something that we were thinking about when we did that round is how do we make sure we maintain kind of like lean startup mentality, and not lose sort of that like culture, the velocity, the sense of urgency that we really have a lot still to do here. And so I think, a couple of things with that. One is that we have been put, I would say, it's fairly conservative in terms of building the team, at least compared to how much we've raised. And I think there's a lot of reasons for that one is just having really high bar for talent. And so it takes a really long time to find great people. But also knowing that it really slows down the team if you hire too many people too quickly. And so wanting to have the right balance of like, continuing to build the team and like, make sure that we have the people in place to go and execute on what we need to do both on the go to market and engineering and product side. But also not growing so quickly that your engineers are just like doing interviews all day and have no time to actually build features. Or maybe that you're bringing on so many people that now you're just like onboarding people, and again, don't have time to build features. And so I think it's been a pretty intentional sort of like, growth to make sure that we maintain kind of like, Coulter, protect time of people on the team can maintain that velocity, but also still grow and make sure that we can, yeah, support our customers, scale those customers and still build new products.

Ryan Rosztoczy 18:16

Again, like just so good to hear. I mean, my brain would also just go I would say, okay, 30 million, a 90 million be your hyper scaling, you're just you're hiring massive amounts, you know, you your culture is shifting underneath your feet. Sounds like that's not at all what hap what has happened and what's happening today.

Julianna Lamb 18:35

Yeah, exactly. I think there definitely have been some growing pains. We went from like, a little under 30 People at the beginning of this year to I think about 60 By the summer. And I think that was like we we managed it. But there were definitely moments where was like, wow, the way that we communicate, it doesn't work anymore. Now we have like a product team. What does it mean to have a product team? We had no PMS before. Now we have a few PMS? Like how do they work with engineering and design? How does that change people's responsibilities like all of those things. And so I feel like there was a little bit of a, like, definite sort of figuring out how to work with the bigger team. And now I think we're at a place where we've been growing a little bit more steadily since then. And it feels really good. Because we're like, bringing on people and creating functions for the first time. Like, I don't know, we hired our first content person recently. And it's like, wow, now somebody owns content that's magical. We spend so much time on that before. But it's also not bringing on so many people at once that you kind of have to do that pause and reset and like, figure out okay, we have all these people like what do they all do now? etc.

Ryan Rosztoczy 19:50

I mean, well, one thing I would just say you guys have done amazing like we talked about the future of velocity, but my perspective would also be that over time and even like small latency issues have just gone down dramatically. Like if I don't even know unless you guys have great like the downtime detectors and warnings and all this stuff, but like, I can even remember the last time it happened that I was like, Oh, is there something going on with Stytch? Like, you guys have improved in that quality direction? Just massively, too. It's so cool.

Julianna Lamb 20:20

That's great to hear. That's highest price.

Ryan Rosztoczy 20:23

Do you think this company building stuff that you guys focus on it intentionality? Deep? Was it helpful that right after you got that seed, you were thinking about building the team? Like, have you essentially always been doing this? Or was there ever a period where you? It was you read maybe a couple of engineers just heads down hustling?

Julianna Lamb 20:44

Yeah, I remember, like, right after we signed the term sheet for the seed, I think read slapped me something like we get to build a company that was like, what we were excited about, was building the company from day one, I think we're really passionate about the product that we're building. But I don't think you can build a great product without building a great company, as well. And so I think it is something that we've been really intentional about from the beginning, sometimes in ways that feel almost comical. For example, our first engineer joined, there was one of her and we ran onboarding sessions. So I would like trade off. And I would talk about like product at Stytch. And then I would talk about like engineering, and read would talk about, like, go to market and do like a competitive overview. And so we had this like, kind of structured onboarding of, basically, how do you bring new people into the fold, share your perspective, share company, culture, and norms and all of those things. We had values written down before anybody joined, we had a company mission, all of those things. And so what that looks like has evolved a ton. I do one onboarding session now instead of half of them. And leaders on our, on our team do all the others now, which is really cool to see that we actually have functions that focus on these different areas. And there's Yeah, a bunch of different people that you get to meet throughout onboarding. And basically still get that sort of like, introduction to what is Stytch? How do different teams operate? What is the culture? Or what is the company sort of that bringing you into the fold. And I think that's one of the things that set us up for a lot of success. As we've grown, the team is being intentional about like, what company culture and norms are sharing them out in a very sort of proactive manner. Giving people structured onboarding to because I think it's pretty overwhelming to join a startup generally, but then to like, join remotely, potentially, and just be like opening your laptop on day one and not know who anyone is, or like what anyone does. It's pretty scary. So we try and like, give you a structured of a sort of first week as possible, and help introduce you to the team and company. And I think that kind of sets the tone for just what culture is like at stage.

Ryan Rosztoczy 23:27

It's so good. Okay, so then what it sounds like, to me with all this scrub is it sounds like you're probably not coding a lot. In a while, how long has it been? And do you remember when you first like stopped?

Julianna Lamb 23:46

Yeah, I think I stopped writing code probably. Pretty completely by like, winter 2021. Um, I think we had like five, or six engineers on our team at that point. And so I think it was, I was still like reviewing some PRs probably at that point. But, um, it became pretty clear that like, the amount of time that it took to do sort of engineering, management, product management, all of that was, as well as like, tons of time on hiring other founder things that was a full time job, and then some. And I think there was sort of a gradual, like, exit from writing code where I would like still be writing code, and then I'd have like a PR up and then I'd have like three days of Back to Back meetings and like, knock it back to the PR for days. And then I was like, holding other people up. And so I was like, this is not productive. Like, I'm slowing you all down by still trying to contribute here. I'll still write code for some of our hackathons. Um, so I'll like jump in occasionally. But um, Yeah, it's been a while since I have been like, in the weeds day to day, I would say that, um, the past year, I've been managing managers, basically, that was another big shift. So there was the shift from like, kind of being, I guess, hands on in code to be more manager than there was the shift to like managing managers. We hired a head of engineering who's joining in a couple of weeks. So that's gonna be a whole other shift of like, now I don't even manage managers, head of engineering, and he manages managers, which is wild.

Ryan Rosztoczy 25:37

Oh, ah, okay. So I do want to talk about that a little bit. I get to talk about my brother all the time. He's a senior director right now. So he's doing this. He's managing managers and that transition. While we would talk about a lot when he was first going through it was this, like, he would try and grapple with the emotions of my work. Where do I see what my work is doing? And how do I know if I'm doing it? Right? And how do I know if I'm doing the right things? When there's no immediate feedback? Was that true for you? Or what was like the big the hardest part of that switch?

Julianna Lamb 26:08

Yeah, I think one of the reasons I studied computer science in college was that I really liked how tangible it was like I would do a project for a class and be able to, like, build something, see the impact of what I was doing. Whereas a lot of other classes that I was taking, it was like, Oh, do this like problem said, and like, write some proofs or something like that. And it's like, Okay, I like wrote some numbers down. But what I didn't build anything. And with software engineering, computer science, you get to like, build things. And you get to see, you have such a tight feedback loop for what you're doing of seeing the impact of you, like, fix a bug, and it works. And that's amazing. Being a manager, it's very rare that you see immediate results from anything that you're doing. And so there's definitely times where I'm like, I should like, fix something at work, because it's so rewarding. But I also think like, getting to build a company getting to see people succeed, all of that is super rewarding as well. And I try and make sure that I appreciate that from time to time, I think that's not something that I'm great at. But because there aren't maybe as many sort of like, tactical milestones where you like step back and sort of appreciate all of the progress that we've made as a company and have to like find those. And sometimes they like, surprise you or I don't know, or hackathon that we did a couple of weeks ago, like seeing everyone in the office and just like looking out and seeing like 70 people that are part of Stytch it, like it never gets old. It's so amazing that all those people like want to work with us and build this product. That's so rewarding.

Ryan Rosztoczy 28:03

It's so awesome. So would you say today, your initial thesis, do you feel like is still proving out? Or have you guys done any big turns throughout the process?

Julianna Lamb 28:15

Yeah, we've definitely evolved a lot of things. I think the original sort of like thesis that authentication should be easier for developers and easier for end users still holds true. I think we started the company very focused on passwordless authentication. And I think both from a security perspective, but also user conversion perspective, I still think that sort of a trend to bet on that I think will drastically improve how we log into our online accounts. But I think we realized that not everyone is there today, not everyone even knows what password list is. In fact, probably most people out there don't know what it is. And so there's still this sort of like gap to close in terms of consumer education on what password lists is education for some companies to on what it's going to mean for their conversion stats, their fraud, stats, etc. And so we built a passwords product, which I think is probably like the biggest surprise because she started out like very heavy kind of like password list messaging. And I think the way that we've thought about passwords is kind of like a bridge to password lists where we want to meet people where they are today and help guide them on this journey to password list and educate them about what that is. Some people are going to be ready for that right now. But not everyone is and we want to meet them where they are. The company mission from day one has been eliminate friction on the internet. And so I think we still very much like hold true to that mission, even though we like talked a lot about password lists, our mission was never to be password list. That's like a means to the end. Eliminating friction is what we want to achieve. And there's a lot of different ways to do that from building a better passwords product to leaning into these passwordless methods as well.

Ryan Rosztoczy 30:21

I, it's kind of interesting, I actually want to think about this for a second to be a part of like, these waves, like innovative waves changing things, because the way you describe it is exactly right. It's not like you guys, like, Oh, we're gonna make passwordless super easy. And then everyone's gonna get it and do it immediately. The change happens on like, the actual user level, at the end of the line, like, do they learn what it is? Do they know how to do it? Do they try it? It's not the most scalable part of the wave. But for us, it's like, Okay, we have a very small subset of your users, each of our clients as a smaller subset of our users, and they're communicating with their users about what it is and how it's like, it's not this huge wave that blasts out it's like, all these little interactions progressing forward over time. Pretty crazy, just be a part of.

Julianna Lamb 31:12

Yeah, totally. And I think the more consumers see, like, more examples of password lists, right, or more sort of explanation of what it is, the more comfortable they'll get with it, they'll understand why it's good. And from a security perspective, why it's good for for them in terms of like not having to manage all of these passwords, etc. But I think if you don't sort of think about that education piece, and that it will be like a slow ramp to sort of like permeate, it would be pretty overwhelming. I think, for most people, if all of a sudden, they like, didn't log into any of their accounts with passwords, right? Like the average consumer probably would be like, very scared about what that means. It's like, it'd be like a huge shift, right, in terms of how we think about authentication. And so I don't think you just like flip a switch on something like that.

Ryan Rosztoczy 32:09

No, totally. Cool. Okay, so one thing that's interesting to me is, you seem like in a very good mood. And in general, you seem like you're in a very good mood about Stytch, I would assume you also dealing with quite a bit of stress. I'm curious, like, what is? Have there been any things on this growth that have been like super hard or very challenging for you? Yeah, lots of benefits. What's been the hardest?

Julianna Lamb 32:38

Yeah, I think, like, they're hard parts of every day. And there's good parts of every day. And I think you kind of have to be somewhat even keeled about all of those, I think you can't let the good things get you too excited day to day, because you might then have to jump into another meeting where you're hearing bad news or something like that. And so then you need to like, sort of, at least for me to sort of manage it is like, you don't want to go like too high on the highs or too low on the lows. And so kind of thinking about it all together in terms of, you know, on aggregate, like, how was this day? Sure, there were like, some rough parts to it, there were some exciting parts, like, overall, it's probably net positive. And I think you want kind of like net positive overall, that that means that that things are going well. But I think that's one thing that's kind of been an interesting lesson is that I think meeting to meeting minute to minute, can vastly sort of range in terms of the conversations you're having something might be going really well on one side of the company not so well on another side. And I think having that sort of, like higher level perspective of like, how are we doing overall, are we continuing to like, build momentum and velocity, in a lot of different ways is sort of how I think about I guess, like tracking how we're doing and also kind of like, internalizing the success that we are having. So I don't know if that is like, it's not really like a specific thing, but I think like kind of day to day, you have to just like manage high levels of like both stress and excitement. And for me, I think like, making sure that I have time to to reflect and like, step away from my laptop and take my dog for a walk or whatever it is, is really helpful because sometimes you can get like too wrapped up in generally the bad things I feel like those are easier to get. And you can lose that perspective and you can like, you know, only focus on like, the challenges of the day instead of sort of having that more bird's eye view of like, okay, well what happened overall today like, What progress did we make? Like, we maybe took two steps backwards here? But like, do we take three steps forward overall, and it's kind of what you want?

Ryan Rosztoczy 35:10

Well, okay, so I love this. So one of the things that just reminds yourself so much is like, how Warren Buffett would describe the stock market, let me go on this tangent for a second, in terms of your like internal emotional regulation, which is like, you know, the prices are gonna swing dramatically every day, that does not mean the inherent value of that thing is changing that much constantly. There is an underlying thing there that you can pay attention to that is different. And so it helps to deal with the ups and downs of the motions of dealing with like stock price changes, which is essentially kind of what you're getting at, like. Understand that all those emotional peaks, highs and lows aren't reflective of the big picture. But you're also not saying regulate it all and be average all the time or even manipulate it into being positive all the time. And you're saying, I want to be aware of it and understand where the big picture is. So if it is good overall, appreciate it. If it's not pay attention to this just a powerful framework, it seems. I'm saying it seems like it's obvious and something that I should have been thinking all the time, but I don't think I've ever thought of it that way.

Julianna Lamb 36:24

Yeah, I think you definitely want to spend time on the bad things because like, oftentimes, I think, if you don't address those, they become worse things, they become bigger things, etc. So I think try and kind of like, face those things head on, but also not let them like, take over and take too much time as well. I think we could probably be a little bit better at like, celebrating some of the wins. But I think it's the type of thing where I don't think you start a company if you're like, easily satisfied. And so I think there's always something more we can be doing. And so I'm always like kind of thinking about the next thing or like how you can be doing better, which I think makes it really rewarding for me to be building the company because we get so many opportunities to like go after really big goals, but sometimes maybe lends itself to not like recognizing those wins that you're having along the way quite as much as as we maybe shed.

Ryan Rosztoczy 37:27

Yeah. That's so funny. Every company has their own culture. I know one thing my brother did during COVID, a couple of his teams landed like these huge company goals. And and he basically sent them all like some celebratory gifts that they like, all opened on Zoom together. And I was like, Oh, that's so cool. Great idea. On one in startup world, too. It's just like this thought of our things not going well. It's so important. And it does change how you frame negative emotions from this is detrimental to this as a useful tool, which is are we doing the right thing? Like can we be doing something different? Or can we do in a different way? So important?

Julianna Lamb 38:08

Yeah, totally. And yeah, treating everything as a learning experience to where you hope that you learn from? It may be challenging thing that comes up and don't repeat it so that you find yourself facing new challenges. I think that's another thing that I think a lot about is, are we like learning from our experiences and mistakes and all of that and using that to get better? Because I think if you've never had issues, never made mistakes, like, that's just probably not accurate, you're probably just not recognizing them for what they are. And so treating them as learning opportunities is super valuable as well.

Ryan Rosztoczy 38:51

When you say that, are you thinking like small mistakes like technical mistakes? Are you thinking like bigger organization level mistakes or across the board?

Julianna Lamb 39:03

Across the board? Yeah, maybe it is a bug that you ship to production and learning from that mistake. Maybe it's not having as rigorous of an interview process as you should have and making a miss hire. It can it can range a lot from things that are like, very easy to learn from, you know, you write a few tests for it to things that are much larger, organizationally, company level, all of those types of things. So big range.

Ryan Rosztoczy 39:36

Yeah. Well, the reason I asked I'm just thinking about like, the difference is in how you handle them. And the thing that sticks out to me is the bigger, less direct mistakes, like slower evaluation and feedback loops generally feels right. It seems like it's just harder to synthesize what the cause was in Still slowing down the rate of feedback seems like a potentially useful tool, anything that like sticks out to you that's like good about evaluating the not easy stuff.

Julianna Lamb 40:12

Yeah, I think there is like a fine balance to between maybe overreacting or reading too much into like one instance, versus taking some time to sort of like, see how things are going overall, and like gathering that as a data point, but maybe not like overcorrecting? I think something that I try and think about is making sure that we are like, moving quickly and making changes, particularly when they're really easy to reverse. We actually have this is sort of one of our values within our onboarding sessions. It's basically about kind of an ownership mentality. But we have this like diagram that is basically like high reversibility, things, you should just do low reversibility, things you should spend more time on and get buy in feedback, etc, before you take action. Because you don't want to like kind of have analysis, paralysis on everything. You want to be spending your time thinking about, like decisions that are really hard to reverse, basically. So I think, something that I had never really thought about before starting the company, but I've gotten like consistent feedback from people on this, that I'm really good at making decisions. And I think the reason for that is that I kind of have this like, mentality of how impactful is this decision? Like? How reversible is it? What are the ramifications of getting it wrong, and then acting as quickly as possible, like getting the information that you need to make an informed decision, but sort of not overthinking it, because I think a lot of times, especially my role is to unblock people, it's to like, give them I don't know, sign off on something, budget for something, all of those types of things. And I think it can be really easy to like overthink all of those, but most of them are probably not like that consequential, whereas something like, I don't know, changing management structure or promoting someone into being a manager, or those types of things are like, extremely hard to reverse. And so don't do those on a whim. Spend a lot of time figuring out, you know, making sure that you're gathering data points, you're really understanding as much as possible, like what that decision is going to change what the like success rate is potentially of it, what maybe the downsides are just like, really sort of overanalyzing those decisions. And so I think it's a really, like, important thing to think about is like, how much do you read into individual things? Or how quickly do you act on data that you're receiving, because not all of it is actually going to be like, representative of maybe some like larger systemic issue, some of it might just be like, a one off thing that especially at a startup, like, your n is pretty small for a lot of things, people on the team customer is all those things. And so, especially in the early days, yeah, making sure that you're not kind of like overcorrecting on something that isn't actually a real issue.

Ryan Rosztoczy 43:32

I'm gonna two big takeaways for me in there. One we have like these principle engineering principles that we are sort of like guiding rules of thought for us sound similar a little bit to what you mentioned with your values and, you know, act fast on one way on two way decisions. I want to make that more prominent. So that's one takeaway for us for sure. Like, I've heard that a bunch, but it's not sitting in front of me all the time. So I'm not so sure that I actually act on that in a good way, or that thoughtful way. The other thing is how right you are about personnel decisions being one of those two way doors that I wouldn't necessarily immediate think, but there's so much to that decision and I've just seen the destructive power of poor leaders so much and it's so hard to claw it back once it's done that is just a huge takeaway. That is definitely worth a lot of time and evaluation one thing that I would I think it'd be really interesting is just to talk about for a few more minutes, you and Reed's relationship early on once you started the company so what were like the early days you're like working on building that coming together. What was that like? Like you have gotten coffee you had worked together. But being co founders is a very a different experience.

Julianna Lamb 45:03

Yeah, I think, um, we had worked together enough, Claude that I think we kind of like, knew each other's working styles knew each other's strengths. We have like, pretty complementary skill sets, my background is all in engineering. His was doing consulting before he joined pod and then doing some go to market stuff there before joining the product team. And so I think, making it clear, like what our sort of roles and responsibilities were from day one was pretty easy for us, because I think it's like pretty clear where our strengths are, I think the area that we have a lot of overlap in is product. But I think the like complementary skill sets make it easier to kind of like, know what our swim lanes are, and feel good about giving the other person feedback. But also know that like, you're coming from a different point of view. And that's like, a very, maybe different type of like perspective. And so that can be really helpful to to have that more maybe like zoomed out view of like, not being in the weeds day to day on either side. And so I think that's something that we like, talked about early on. And I think having the experience at plod, both working together, but then also seeing how Zack and William built plaid gave us a really sort of like shared framework for how to think about company building role of founders, we modeled a lot of things sort of, after how they split up the company, but didn't do it exactly that way. Because we have like, slightly different sort of skill sets and areas of interest. But I think having that shared kind of like language of what it means to be a founder, how you think about the division of responsibilities, was really helpful. I think we've also, sometimes, I think, for better or worse been very good at keeping the other one in the loop. I think sometimes you have to, like realize that. I don't know, we don't like both need to talk about everything. But I we can and we do talk about a lot of things together. And so I think that's probably just like our personalities. To some degree, I don't think we ever like I don't know, talked about expectations on like, how much we run different decisions by each other, etc. I think so you from myself, like I'm the type of person that likes to talk things out. And so I really appreciate having read to go to to like, run a decision by him or like get his feedback on something that I'm thinking about even if he's you know, maybe not super in the weeds in the context on like, a decision and we're gonna make on how to structure engineering teams like he'll he'll still have like interesting questions when I walk through an idea with him. And so that's super valuable. And so I think that ends up resulting in us like, just like communicating a lot, which makes it easy to evolve the relationship to because yeah, in the early days, it was the two of us. And we had to figure everything out just the two of us. And now it's like, figuring out how to manage the managers under us and like, set high level company direction and very different types of problems. But I think the way that we work together hasn't evolved much for I think that's probably for the best. Like, I think we have had just like a strong sort of collaboration from day one and continue to do that. It's just the topics that we're talking about have evolved. Sometimes they haven't evolved, sometimes we're still talking about, like how to get into our SBB account or something. Most of them happen.

Ryan Rosztoczy 49:08

What I love about that is it's like you kind of sounds like you're the fact that you like to talk things out as a way to like reach understanding is a forcing function on good communication. That's great.

Julianna Lamb 49:23

Yeah, I think, yeah, definitely, um, makes it like, easy to sort of ensure that you're keeping the other person in the loop because I think yeah, I don't like to make major decisions on my own generally, I think it's always good to like, get sort of feedback, especially going back to what we were saying about kind of like the highs and lows. Like you want to make sure that you're not like actually some like really big high point and not realizing it and make like a rash decision because you're like feeling great. Conversely, you don't want to like make a super emotional decision. Then because you're like, at a low point. And so I think sort of always having an outside perspective, or someone else's perspective is really valuable.

Ryan Rosztoczy 50:09

Awesome. Oh, that's so good. Um, cool. Okay, so one question that I've been asking everybody. And I would love to hear your advice on this is just for people who are either thinking about starting a company, or have just started on that journey. Do you have any advice that you would tell?

Julianna Lamb 50:34

Yeah, I think I'm really spending the time on like, figuring out what you're building, what the sort of like unique value prop is. And if you have a co founder or co founders, like, making sure that you're really sort of like, turning over every leaf in terms of figuring out like, what you're going after, and how you're defining success, I think that type of like, upfront communication can just let you like, run so much more quickly, once you really get going. Writing code takes a long time, but figuring out the product that you're building. And then changing it once you've written code is going to take a lot longer. So the more sort of like upfront diligence, you can do, I think, always better. Some, one of our values at Stytch is fail fast, basically, for that reason, like figure out the ways that this goes wrong as quickly as possible and sort of continue to have that mindset. I think on sort of the like, more company building founder dynamics, I think, another really important thing is like what success looks like is one founder, you know, trying to build a company that gets acquired in a few years. And like, that's what they are working towards. That's what they see as a success. And the other person is like trying to build a company to an IPO. Those are like very different mentalities. And so making sure you're on the same page about kind of like, how you measure your own success. And the company's success, I think, allows you then to like, focus more on the day to day and know that like, the end goal that you're working towards is shared and the same and have that trust that the decisions that the other person is making are in the best interest of like that shared goal versus maybe over optimizing for a different outcome for example.

Ryan Rosztoczy 52:42

And that's a wrap, head over to the tf.com and subscribe if you haven't already to receive the latest episodes, and also my newsletter, the pourover, where I'll go over one tactic one resource and one insight that I'm noodling on from the latest episode with Giuliana

View Details

Welcome to another episode of the technical founder, the show where I meet with engineering founders and we deconstruct and demystify the science and art of building technology businesses. My guest today is Mike Carter. Mike has been an engineer at Otto and Uber, and he was the founding engineer at Kodiak Robotics. Mike has been an entrepreneur in residence at Ajax Health, and before he joined the world of autonomous startups, Mike was a member of the Stanford dynamic design lab, and a part of the team that became famous for creating Marty, the autonomous drifting DeLorean, yeah, drifting. Mike and his co-founder, Jesse Buckingham, were accepted into Y Combinator is winter 2023 batch. I cannot wait to see what they do for the future of the space.

Mike Carter (YC Winter 2023): Cultivating Insight and Tackling Existential Problems0:00/74:191×Highlights[19:46] The concept of an operational design domain (ODD)

[29:10] The benefits of reducing feedback loops

[36:18] Build teams and systems that build solutions

[41:03] Finding insight in disagreements

[46:25] How to tackle existential problems

[46:25] Storytelling and communication are critical founder skills

[1:06:02] Founders must operate from different viewpoints and levels of abstraction

Transcript (Provided by Otter.AI)Announcer 00:12

Welcome to the technical founder

Ryan Rosztoczy 00:26

Hello again, this is Ryan Rosztoczy. And welcome to another episode of the technical founder, the show where I meet with engineering founders and we deconstruct and demystify the science and art of building technology businesses. My guest today is Mike Carter. Mike has been an engineer at Otto and Uber. And he was the founding engineer at Kodiak robotics. He was also the entrepreneur in residence at Ajax health, before he joined the world of autonomous startups. Mike was a member of the Stanford dynamic design lab, and a part of the team that became famous for creating Marty, the autonomous drifting DeLorean, yeah, drifting. Mike and his co founder, Jesse Buckingham, were accepted into Y Combinator is winter 2023. Batch. All right, let's get to the show. Super excited to be talking to you. Really happy that Alex put us in touch, especially with you starting YC in winter, because I'm sure we could not have talked after you started that.

Mike Carter 01:29

Well, it's it's always busy, sir. Thanks for having me. It's really I'm excited to chat with you. And I think having listened to a few of your podcasts now, I'm excited about the concept of your podcast, you know, focusing on technical focusing on tools and strategy and the things that, that people like us are interested in to become entrepreneurs. So thanks for having me.

Ryan Rosztoczy 01:50

Yeah, awesome. I mean, I'm especially excited about this, because I think we're gonna get to go pretty deep and explore some really fun stuff there. So I'm glad you mentioned that. Before we kind of get into your past and experience in AI, I would love if you could tease Vilma, for us for a second. For sure.

Mike Carter 02:11

Yeah, absolutely. So we're not saying too much about what we're doing at the moment. So it definitely will be a bit of a tease. We saw my co founder Jesse Buckingham, and I been working together for a little while. Both of us have backgrounds in logistics. And we're both very excited, I bring sort of the, the technical background, he brings a really powerful commercial and sales and business background. So in a lot of ways, it's kind of a perfect complement of skills, both with familiarity and logistics. And we're very excited about what AI can can do there. Especially as the the industry as a whole sort of continues to digitize. There's a lot of opportunity, we think to to do some pretty powerful things with efficiency. And automation and logistics.

Ryan Rosztoczy 03:02

Yeah, well, we'll definitely be following you cannot wait to see what you guys do. Yeah, I'm with Jessie real quick. How did you guys like connect? Because that finding that like really strong commercial sales go to market founder, I think is so important. How'd you guys meet? Yeah.

Mike Carter 03:21

So really funny coincidence, same reason that that we met by introduction from Alex Avery, he, I think he needs to be the master matchmaker and in our world, but So Alex, Alex, and I played water polo together at Stanford, and Alex and Jesse went to the Stanford GSB together. And it was funny, I was catching up with Alex and talking about some of the stuff that I was interested in and working on. And, and he was like, You should chat to this guy know, Jesse. He's, he's, like, amazing, and also really interested in the same things that you're interested in. And then we met up like, the couple days later, and we're like, Well, okay, there's, there's pretty good match here. And both of the things that we find exciting to work on the ideas that we had had, and also just like, you know, personality, working style, and and skills, the sort of complementary skill sets.

Ryan Rosztoczy 04:11

Oh, man, awesome. So okay, wait, so that happens. That's hilarious. Because Alex, when it was starting gather, he also reached out to me and that's how I met gather. And when I got back into the startup, so yeah, he

Mike Carter 04:24

clearly has a knack for bringing people together.

Ryan Rosztoczy 04:27

Yeah. How far were you in your decision process to like build your own startup at that point? Had you already decided to go down that path or was meeting Jesse kind of like a catalyst for that?

Mike Carter 04:39

So I had already started started that path. And it was interesting. Because so I left my job my full time in April. And that was, to me that was the big sort of decision point. I think there's a lot of there's a lot of cool projects that started side to side projects, but a lot of time So those projects, stay side projects unless you really like leave and start working on them and sort of roll the dice if you if you know what I mean. So, so I had already left my job and decided that this was exploration that I wanted to do had a bunch of sort of concepts and ideas that I thought were interesting and promising. And so it was basically in the middle of doing a bunch of sort of field work and diligence on on those concepts when I met Jesse. And, you know, he had, he had been doing sort of a similar exploration process, I believe. And we sort of realized that as we came together our ability to cover that ground and rigorously do those explorations, which just like notched up, at least from my side, all these like commercial aspects that I had been doing my best with, you know, but but but really like bringing in somebody who lived and breathed, you know, the kinds of things that you have to think about when you really want to go out and sell something like that. That was a huge compliment to the things that I was doing.

Ryan Rosztoczy 05:58

That's awesome. So great to hear to rolling the dice. Yes. So important. I mean, I think about it, like even with this podcast, you know, doing it on top of the job, it's just so hard to give it the focus and attention I really want. Won't be willing to die. So don't worry, Alex, not anytime soon. But a fair way to put it. Yeah. Okay, cool. Actually, there's some there's some tidbits in there that we're gonna come back to for sure. I'm, I really want to unpack some of that exploration that you guys are doing. But before we get there, I would love to just like take a step back and kind of talk about your early career. So you did I know you did your biomedical engineering BS at Stanford, mechanical engineering post grad. When did you get into, like, autonomous vehicles? Was that? Yeah, you're doing the mechanical engineering degree?

Mike Carter 06:54

Yes. So it was biomechanical engineering was my undergrad. And the reason for the sort of the bio prefix there is because I started out probably like a lot of people as pre med. So coming out of high school, I, you know, generally interested in a lot of things, and I wanted to do things that helps people and help society. And so one of the first places that I looked was was, you know, the idea of going into becoming a doctor or surgeon or something like that. And, you know, pre med was great, mostly because it was like a challenge that I found that, you know, you go through chemistry classes and all the requirements. And that was, you know, it was it, I liked it, because it was a challenge, but it wasn't what sort of like, kept me up at night with excitement. And it was actually through a conversation with my brother, where I was, I was thinking about, like, hey, you know, those engineers seem to be having a lot of fun. And I talked to him and he was like, just like, remember what we did as kids. And he was specifically talking to, you know, what I was doing as a kid. I was always like, in my grandpa's shop, trying to help him with stuff like he was a mechanic. So I was, he was like, go build things. That's what you've always done. That's what you've always loved. And so that's, that's what pushed me. Yeah, that's what pushed me in the, in the direction of mechanical. So biomechanical ended up being like, it almost like tells the whole story like started up bio, and then became mechanical. And so that's what when I switched into mechanical, oh, went into self driving research at the same time.

Ryan Rosztoczy 08:24

I love that I thought about biomechanical early on I did you ever take. I can't remember the name of the class. But there was like a humanities class that was like, sort of like an intro to pre med it was with this really old physician professor. And it was kind of like about the ethics and morality of of being a physician. Did you ever take that class?

Mike Carter 08:49

I don't think I did. Did you say the name of the professor,

Ryan Rosztoczy 08:52

I can't remember now I have to look it up afterwards. I remember I was like, pretty convinced I was going to be a doctor and I took this class. Yeah. I think it was like week three. I was doing an SSD at the time. And I think like week three. It was some sort of course. And it just became very clear that you had to be comfortable with people dying all the time. And I was like, Absolutely not. Like can that cannot be like my default state of expectation, like, you know, if you save someone great, but in general people, and I just quit the class and went full engineering after that for a

Mike Carter 09:28

year. Yeah, I know what you mean. It's kind of like being a goalkeeper, right? It's like the the expectation is that you save some some of the shots sometimes, but mostly a lot of time the goal, the ball goes in the goal and you're like, well move on. Yeah. Very different than building and you know, feeling that that fulfillment and success of like, this thing didn't exist. And now it does.

Ryan Rosztoczy 09:49

Oh, yeah. rapid, rapid constant. Positive feedback. Yeah. Yeah. Okay. So so you go into engineering. You ended up being a part of that team that creates a Marty, can you just can you talk a little bit about what Marty is and what you were doing there? Because I think it's one of the coolest things I've ever heard.

Mike Carter 10:09

Absolutely. Yeah, Marty was it's super, super fun project. So it was Marty is the name of a car that we were working on. It was a DeLorean. So hence the name Marty, kind of a shout to the Back to the Future movies. And I think we had some some acronym that you know, made sense. It's sort of a backronym for why I was called Marty as well. But it's so within the dynamic design lab at Stanford, this is Chris Cody's Lab, mainly studying control of autonomous vehicles, basically near stability limits to near the the edges of handling bluffs. So if you imagine driving a car, there are some very sort of like stable equilibria for cornering or turning things like that, where small perturbations, you're likely just to sort of like come back to something stable. Where we're working on sort of the the frontier of that kind of autonomous control is, what do you do when you're actually a small perturbation could send you way off into some other part of, you know, the state space. So drifting is a great example of that drifting is a, it's an unstable equilibrium, it's a saddle point. So if you if you end up like adding a little too much throttle that you can spin out or a little too less, you know, less throttle than you need, then all of a sudden, you're not holding a drift. So basically, we were studying autonomous, drifting, how do you stabilize a drift with an autonomous vehicle? And we did it with like, the coolest platform possible, which was a DeLorean.

Ryan Rosztoczy 11:38

Okay, that's just the coolest thing ever. Guys, we need to study really challenging problems, we might as well have as much fun as possible doing it.

Mike Carter 11:48

And that was, that was the I mean, so one of Chris's sayings was, life is too short for boring cars. So it's like, just a lot of cool points along with that project. And, and also John go, he was the sort of the lead on that project, he just tons of like, both engineering, brilliance, but also lots of like, color and character and great sort of presentation, the sort of skills, but also, like, he had a flair for, like, let's make this as cool as it possibly can be.

Ryan Rosztoczy 12:17

Amazing. I've seen the videos on the on the website and in the media. So that worked. Exactly right. Um, so I mean, this questions there, I have not delve that deep into engineering. And so the idea of like, testing a system at its limits, or evaluating it, or trying to understand it, that's fairly foreign to me, but pretty important, even in just software engineering, maybe think of like maybe in chaos engineering is a little bit similar. Like what happens when you push the boundaries? Yeah, you just give me a little bit of like, an overview, like, what are you thinking about? What are what are you trying to assess? What are some of the challenges of assessing that stuff?

Mike Carter 13:05

Yeah, absolutely. And this also ties into, you know, that project that we were talking about is, is very much it's like an academic setting. And the idea is to push the boundaries of sort of knowledge of how to do those things. But it starts to feed also into just the rigor and practice of developing self driving vehicles, where what you're really doing is trying to design a system that's robust, and can handle a lot of sort of a lot of difference circumstances, situations that you may not necessarily sort of, like from the from the Gates expect, and behave in a reasonable in a safe way. So a lot of what we do in that kind of context is, you know, you obviously tried to predict what might happen and as much as you can you design for it. But then you also basically say like, there's also just going to be situations where something fails, and you try to make your, your failure modes safe. So we talked about sort of a minimum risk state. So you know, if something isn't working, make sure that you can catch that it's not working, and that you can fail into some state that does a reasonable thing for that situation. So if that's just stop it stop. You know, in some cases, you actually can do better than stop you can like pull over or something like that. So that's when we started talking about more like, you know, self driving self driving development for specifically what we were talking about with Marty and the DDL. That was a lot to do with like, Okay, what if you encounter things like your your your tires, let's say ice, what have you encountered a situation where your tires no longer have the grip that that you think that they do and your the way that you're actually measuring the vehicles motion? It's not going how you sort of would expect if the tires had full control had full friction. And so it's basically being able to design for their case and say, okay, yeah, if the wheels start Deciding we still can can do something reasonable.

Ryan Rosztoczy 15:03

That I mean, it just sounds. It's so interesting here, you're talking about this, I know nothing about mechanical engineering, but it the word you're using sounds so similar to software engineering, the idea, you know, you have maybe a failure state is an exception, and you want to catch it. And, you know, in a lot of cases, stopping is what you want. Or in software, maybe you want to let the program keep running. But often you can do much better. So maybe you give some notes to the user, maybe you're doing you're retrying, an API call, but it's essentially capturing failure states and then trying to figure out how to work with them. That, yeah,

Mike Carter 15:43

well, it's funny that you say that, because I've also sometimes wondered why controls engineering, and sometimes autonomous motion planning is sort of taught in academia as a sub discipline of mechanical causes, especially controls, you know, you as a, as a mechanical engineer, and most people take like a controls class, which controls today is like, very much software engineer, you know, especially when you get into the world of digital control. And I, you know, from the history of it, it comes from the fact that we had to build like dynamical systems or like bridges that didn't collapse and things like that. So it makes sense that you want to understand frequency responses in those contexts. But the way that we actually do it today is is so software based that, you know, I think that's where the tie tie in comes. Because if you build something in the real world that has some electronic actuation, you're writing software, so you kind of have to do both both sides of this.

Ryan Rosztoczy 16:35

Yeah. Yeah, it's so interesting, I think just so important to you, it makes me realize that like, yeah, it's not just cool. Let's make a DeLorean drift. And that'll be awesome. And we'll learn the mechanics of cars and the process. But it's crucial for safety. Like, what is yeah, when you hit that ice patch? Or? Yeah, wow. Okay, well, so very cool. But I do want to keep going, because we can start to unpack some of this under the context of companies as well, which I think is important. So you move from the your postgrads career and doing working at the dynamic design lab, you end up at auto? Yeah, it's like what that looks like for you. And then I would love to just understand it auto and Uber, some of that, how those lessons converged into like working at companies applying the technology in the real world,

Mike Carter 17:32

for sure. So auto, I mean, that whole stage of my career was just such an exciting adventure. Auto was one of the earliest groups doing self driving trucks. So it was it especially in those days, there was just a lot of exciting work going into the transition from autonomous vehicles as like this research concept, mostly pursued by like DARPA and academia into companies that were actually like, trying to make a product out of it. And so Otto was was really exciting, because it was a it was an effort to basically say, Okay, we think that the the highway trucking on the highways is a good first use case for for autonomy. And it was also you know, there was just a ton of excitement and energy around it, a lot of extremely smart people brought to you know, came came together to work on that project, it was acquired within like a matter of months, by by right CG. So it was, you know, a lot of really exciting stuff. Uber, ACG is Uber's self driving research group. And that brought with the that acquisition brought with it like a whole host of other interesting challenges of, you know, we had been working on a self driving truck, Uber, obviously, you know, to connect it to its its core business function wanted to be moving people around. So they had been primarily targeting self driving a robo taxi concept in cities. So marrying those two together was like an it really interesting sort of challenge it. In retrospect, part of the reason why I ended up leaving Uber was because I wanted to be working on trucks and sort of logistics applications of this technology. And putting those two products together under the same sort of development organization was in my view was like a major challenge, being able to design two products, both autonomous that at the surface level, had some similarities, but had fundamentally different operating domains, fundamentally, sort of different technical approaches to some of the solutions. It was holding both back and in my opinion, and so being able to focus on just trucks at Kodiak, which was my next step was in my in my view, the right way of doing it.

Ryan Rosztoczy 19:46

So I'm really excited to get to Kodiak bow want to sit in like audit over space for a second. I mean, what that makes me think of is like, it sounds like the Insight at auto and that you guys had was a Um, this is a the idea of autonomous vehicles and the use cases that can be applied is super complex. There's a lot of work to be done here. We think self driving trucks is probably would, I don't I don't want to trivialize it with easy, but like the most viable, you know, next step for this tech is that kind of the approach that you guys were taking or the thought behind that?

Mike Carter 20:24

Yeah, along those lines. So I mean, I think a lot of what goes into this kind of product strategy in the autonomous world is just a recognition that building robots is, is hard. And building robots that have to work in the real world, you know, the wild world is even harder. So you know, building robots for a factory, you can sort of scope the the things that the robot will need to do and the things that it will need to react to, but the the roads, which feel to us as humans feels sort of structured, there's still a lot of variation in the situations that you can encounter. And then if you go and look at, like, you know, drive through the middle of New York City, or San Francisco, and you know, even good human drivers will sometimes be a little overwhelmed that you know, just how much is going on. So we basically took the approach of the highways is the most structured environment, in terms of driving. And so let's see if we can solve that problem first. And then if you if you take that step and say now, what is what produces value that mainly drives on highways, you pretty quickly get to trucks?

Ryan Rosztoczy 21:28

So it I mean, is it fair to say that what you're trying to do is like bound the system contain complexity so that you can work in sort of like, a more knowable space?

Mike Carter 21:39

Yeah, exactly. And in those days, the concept of an odd sort of operational design domain was, it was still still sort of like being discussed and formalized today. That's a pretty formal term in the autonomous vehicles industry. But we were basically trying to take the odd the design domain and say, Okay, let's, let's, let's try to make sure that this is scoped. So that we can actually make a safety case at the end of the day that we can like, kind of break down the situations that we need to be able to go and test and simulate and sort of certify that the vehicles behavior will be correct and appropriate, and all those things.

Ryan Rosztoczy 22:16

So you're the I mean, I was just really hitting me hitting home with me, on one end, you're like bounding the problem space in the system that you're working in. Because on the flip side, you're gonna have to go like deep with the problem, like the, the first order like solution that is acceptable to the world is a really, really mature one that is very safe, cannot have trucks killing people. Which means that the degree to which you have to solve the problem is like a mess.

Mike Carter 22:49

Yeah, and one of the major challenges of building a startup in, in that environment, you know, because in some ways, if you just think about it, from from, like, the most basic statistical perspective, if you have a vehicle that works like 99.99% of the time, it's still terrible vehicle, you know, if point oh, 1% of the time, it's crashing, or something like that, you can't deploy that. So there's all of a sudden, like, you have to get really into the safety case. And you have to really like understand what what some of those, like, how you might mitigate all those risks in all the situations that you encounter. So the fewer situations that you have, the better.

Ryan Rosztoczy 23:30

It reminds me a ton. I mean, to me, that means two things when you have a technology problem like that, and one is you're going to need time, and you're going to need capital. It reminds me so much of leave the first startup I did with my brother, and our biggest it was also a real world system, we It wasn't as complex as like autonomous vehicles, or we didn't have to make robotics function. But we were on tractors in farms, we were collecting data without human intervention from those things, trying to use ml to understand that data by adding in the real world layer. And these like systems of working in, in like farms, just made everything so much more complex than we were ready for. And it took to get to solve the problem we were trying to solve to the degree with which to which it needed to be solved, which is basically more than 99% 99.99%. uptime. And data integrity was what we needed. Yeah. Imagine, yeah, imagine a farmer drives a tractor out to a field for, you know, a 30 minute period, the location doesn't work anymore, and then somewhere else, and he's sending workers out over there to where he thinks the thing is, but it's not that right. So we had to solve this problem to an extended degree. We just weren't ready for that we weren't ready for the complexity of the system and the degree to which we had to solve the problem. So to hear that and what it means to me now is time and money. And so to hear you talking about an autonomous robot, it makes sense. There's so much capital going into.

Mike Carter 25:07

Yeah, totally. It's actually funny that you say that, because I realized only after having left the self driving world, sort of how different it is as an entrepreneurial environment, if that makes sense, like the first time that I learned that people raise series A's, like once they have a product and users, and they're like, ready to grow, like, that kind of blew my mind that the, the amounts of capital that you need for any self driving project is just like, so high in the numbers that people you know, if you just look at the news and and see what people raised in, you know, like the middle of the last decade, those numbers were just so astronomically, much higher than what you would see for like, you know, your standard SAS business that it took some recalibrating after I left.

Ryan Rosztoczy 25:53

Yeah, I mean, well, I think there's a big takeaway there for like, first time founders, which is sort of, can you at least have a prediction of the complexity of the problem you're going to be solving and the degree to which you'll need to nail it, because that should really inform how much money you're trying to raise. And I actually, I do want to die. So let's, we're still not to Kodiak, but I still I want to dive here deeper, because this is super interesting, because I've never experienced that side of the entrepreneurship like capital raising paradigm. I've always been in like SAS web application SAS world, so you know you're doing, you can fund spikes and and seed stage startups very cheaply, you can move super fast to try and find product market fit everything is about iteration and exploration. I have no idea what it is like when that is not the beginning. So let's give me a little like walkthrough of like, how does the game change when you're trying to raise money? There's some assumption there that the problem is so big, you should you should be able to find product market fit essentially, or Yeah, can you just walk me through what that's like?

Mike Carter 27:05

Yeah, I happy to this is also just for context setting, this is also something that I'm doing a lot of reflection on. So you know, these are, these are thoughts in progress to a good degree. Because I think that there's one element where the project is so big and so difficult that like, you know, you just have to raise a lot of money. And the first thing that you do there is you say, Okay, well, we're going to need to have an amazing team. So you do a lot of hiring that kind of thing. And there's, there's, I think a lot of those things are true and necessary for a project of that size. But I think there's also an element where, you know, I think the whole self driving world did get a bit of that disconnected from reality, you know, in the last decade, and especially, you know, this is not just self driving, it's sort of like a macro economic trend as well, where capital was cheap, and people were willing to invest a lot. And, you know, a lot of people talk about the quality of diligence in the last, you know, second half of last decade not being super high, and all that kind of thing. So, I think that there's sort of two sides of this, where, on the one hand, yes, it's a big project, yes, like one of the first things you have to do is raise a lot of money and build a team that can do it. On the other hand, I do and I would love to sort of like, do some retrospective thinking about how some of those projects could have and, you know, the continuing ones can push more to be like that SAS company, you know, to be more focused on getting products in front of users getting feedback, thinking about how the product because because, you know, it's easy to say like Yeah, great. Everyone wants vehicles to drive themselves. But but actually going in and doing a bit more of like, okay, great if we do get this this vehicle so that it can launch, it doesn't have a safety driver, and all that kind of thing. Like how exactly does it fit into the logistics of today or into the, you know, transportation or the you know, how people move around in cities, all those things? There's, there's some good work on that, but not to the same degree, I think that a SaaS company has to get out there and really like trial by fire until they find that product market fit. So I think, you know, it does it is sort of necessary because of the scope of the problem. But I think the industry can do probably a better job of that as well.

Ryan Rosztoczy 29:10

Well, maybe I mean, it's making me think like, maybe you can have confidence and the ability to raise more money, because the total opportunity is the humongous and everyone accepts that. But that doesn't mean that where you land in the solution space is going to actually work. Like maybe you're at one of your key insights you had it's like that I mean, being an auto and that Uber acquisition just seems so powerful, because without that, like my gut would say if I'm Uber, Otto Otto has what they think is this like next most viable application of the technology, that's great. We want to step function that into taxis. But it turns out that the shape of the solution for trucking doesn't actually work for cars, which means the Gam for that product is totally different than Robo taxis. And so But I mean, what you're getting at, and I hope you guys like, can now is like, what shapes? Can the solutions take? And what are the actual markets that those will be viable? And?

Mike Carter 30:12

Exactly, yeah, and it's where the project is sort of complex is self driving some of that you have to try like it, it's much harder to sort of model and simulate out, you know, many, many layers of interacting algorithms. And some of that stuff, you know, the, the cycles are just expensive, and they take take time. So that's, I think that's part of it. But I do kind of, I think the general wisdom, and especially something that I'm trying to apply as much as, as possible, in this phase is like, find the cheapest way to do those experiments. And whether it's a big project, you know, massive atomic scale project, or a smaller sort of sasco project, I think that the the wisdom applies, generally of like, there usually is a cheaper way to get some, some information. And sometimes you just sort of have to ruthlessly go after that. And it's, it's sometimes even as an engineer, like not the most fun thing, you know, a lot of engineers, our gut will be like, Oh, I know how this perfect, like, immaculate, elegant system that I've got in my mind is gonna look and I want to build that whole thing. But often, that's like, a lot more expensive of a path than the, like scrappy, quick experiment that you could run.

Ryan Rosztoczy 31:26

Oh, totally. Yeah. 100%. Yeah, I mean, just think about things we do that push that to the limits. So the opposite of what you're doing in autonomous vehicles, where you've got a, you know, have whatever, six figure plus safety, you know, we would do things like, say, let's say we have a third party provider of some course, financial system, or authentication or something. Yeah, we could engineer a solute redundant solution around that, like, that's, you would think that'd be critical people can get into our app or pay, that seems like mission critical, we could engineer a solution to that that, you know, was was massively redundant. And we had a lot of confidence in. But it would take a lot of time. Yeah. In general, when think things will go down for a few minutes, let's say even 20 minutes, that hasn't happened. But let's say that happen. Yeah. And, you know, we need to send out an email later apologizing to some users and helping them do what they tried to do. Yeah, that's totally acceptable to us, like the degree to which we have to solve those problems is so shallow, that it would be a huge waste of time and resources for us to engineer that stuff more. So one thing you said that I think is like, critical is reducing feedback loop iteration time, like, increasing the frequency of feedback loops. That's huge. Do you have you had any? Have you just started thinking about that stuff? Cuz Yeah, I mean, I think that's critical.

Mike Carter 33:01

Yeah, I mean, I think the way that it looks in autonomy, people are actually starting to do and that I'm not saying that as in like, I am this genius who like they're all doing what I think that they should say, I'm also like observing and seeing what what I think is working, which is actually like reaching out to the future partners, you know, starting to work with those partners early. I think that that's, we see some companies doing that well. And I think those are the ones that are actually building products that will fit in, you know, and will be useful to those partners. So I think that's, that's a big, that's probably, I think, the best strategy for this.

Ryan Rosztoczy 33:38

And when you say, partners, this is gonna be the next thing that's going to get when you say, partners, you're thinking like, would a GM or like a parent company or an Uber? Are you thinking like industry partners that could use your technology?

Mike Carter 33:51

Yeah, I think it also depends on what kind of autonomous vehicle you're building and for what space so like for if you're planning to be a technology provider, it's it could be like the end user. So for trucking, it could be like a trucking company or something like that. Or if you're planning to integrate with an OEM it could be that oh, yeah, I'm just basically getting closer to the people who will be deriving value from from the work that your your robot is doing. I think that's the big element here. The big key.

Ryan Rosztoczy 34:20

I love that. Yeah, Hunter. One of the episodes I'm going to be doing that comes out in a few months with Giuliana, it is awesome. One of the things that was most impressive to me about stitch there a unicorn now, after only a couple of years is that her injuries were still responding to my feature and support requests and still coming to me for feedback after they were unicorn. I'm like you guys, you have a business but build and run like quit. Why are you responding to my support request? But it was because they were maximizing that closeness to them and that feedback loop. So, you know, and they maintain that to a really high degree. So when you say, building those relationships early, getting as close as you can to those people and the problems, I love that.

Mike Carter 35:13

Yeah, totally agree. I mean, it's all important. And the minute you lose sight of those things, I think you could go, it's easy. It's funny to see how quickly you can go in the wrong direction when you're trying to try and imagine that you know, what the problems are?

Ryan Rosztoczy 35:26

Totally, I It's so seductive to like, as an engineer, in particular, because you're like, I need deep work time, I need time to synthesize, build solution. But if you get lulled into that, and you're then yeah, it's, it could definitely go.

Mike Carter 35:41

This is actually one of the big reasons why I love the concept of your podcasts because there is this tension for for especially the engineering type brands that are working on problems, it's really easy to think that you understand the problem. And the problem evolves. And it's very, it's sort of elusive. So I think, you know, you bring together the sort of like business thinking and technical thinking, and probably, you know, I'm imagining it appeals to a technical audience, obviously. So it's cool to be able to discuss these things, because I think that there are people who do it super well. And learning from them is really cool.

Ryan Rosztoczy 36:18

Awesome, great. That is great to hear. That's exactly what I'm trying to do. Okay, so let's I do want to jump into we have a lot of really interesting stuff left. So I would love to talk about post Uber, because I me, that's when your like, real kind of founding career path starts to come together. So can you talk about what happens after you leave Uber?

Mike Carter 36:44

Absolutely. So I joined Kodiak robotics as a founding engineer, and Kodiak founded by Don Burnett, who was also an auto on Uber, so I had known him a bit from there. The I alluded to this a little bit earlier, but the the concept was to focus on trucks, where the, you know, the Uber projects are brought together to autonomous products, and there was a decent amount of just sort of extra cycles, you know, regression testing things, like when you made a change on the truck to break the car, and vice versa is basically to put those things aside and say, like, Okay, this problem is hard enough as it is, let's focus on that problem for tracking for the highway, etc. And so it was just an incredible experience. I think Kodiak for me, you know, one of the most exciting projects to join, brought together, you know, the team that they came together was just like, the highest quality. And it was, to me, it was one of the one of the most interesting learnings for me, there was, as you know, having started so early and doing quite a lot of hiring and building the team, I realized that we weren't actually building a self driving a truck, we were building a company that could build a self driving truck, which I think like I tried to keep that in my mind as sort of like general wisdom for what I'm actually doing as an entrepreneur, I'm not just building a thing. I'm building like a company and a machine that can build and can maintain that thing, which is sort of a mindset shift, because it makes you realize that it's it's about, like, the competencies that surround and the skills and the and just the the know how that surrounds a product, which is actually, you know, sort of like the the iceberg, you see the product of the surface, but there's 90% of what's going on is actually less visible.

Ryan Rosztoczy 38:39

Yeah, it's so interesting to me, you're not because you're you're not working on a problem where you can bootstrap some simple software application solution. And then as that sort of takes off, you realized you need you realize you need more expertise. You're dealing with problems that are so challenging that you just from the get go do a lot of these Yeah, exactly. So let's real quick talk about that, like, how do you how do you go about discovering what's under the iceberg?

Mike Carter 39:12

Yeah, a lot of so Kodiak was in this sort of beneficial position where we started in 2018. So there was a lot of false starts in the self driving industry before that, that that were really great lessons learned. And a lot of the folks that we brought in, especially early had had lived through a lot of those, you know, the first attempt so it was it was great to bring together people with experience on on the problem. And then also just sort of like being really disciplined. And one of the things that we we pushed was to sort of like mine for these principal disagreements, right? Where we you really quickly realize when you bring people together, especially intelligent people who have worked on problems before that there are like, areas where they see the solution space differently and and really like flushing those out and not being not sort of like bumping off of each other and going off off in different directions and building different things, but really like getting to the bottom of it and so many conversations, what I loved is especially like, you know, early architecture days, we had long conversations where we were like, you know, going back and forth debating what the right approach was. And ended up in a position where our strategy was better than either of the opinions coming into it, if that makes sense. So like, a lot of this, like really cool principle disagreement, obviously, like, starting to build as early as possible in the self driving world, that that looks like building in simulation, just because simulation is such a powerful tool. And doing that in a way that, like, helps you iterate quickly in a digital world, you know, sort of as the analog for the SAS company who can iterate more quickly with their customers? That's sort of the best tool that's available, I think, in the self driving world. So a lot of building and simulation first, and then when we got our trucks, obviously things got got real and got exciting.

Ryan Rosztoczy 41:03

Yeah, okay, cool. I was gonna ask about that. Really quick. That's, I mean, it sounds like this is generally seems like a must have theme for startups to me. But, I mean, sounds like you're building a culture of really high trust, would you default to? Like, okay, when you have two very smart people with two very different views on how on what a problem is and how to solve it, then there's sort of this concept of like, how do you understand which pieces of those views are good and correct? Would you generally default towards you know, somebody had just a lot of experience in a space? Or you had a prior relationship with someone? Or what does that look like on an early team?

Mike Carter 41:48

Yeah, I think, sort of, by and large, most of those disagreements, when you really unpack them, and you have the conversation, you realize that the assumptions that people were taking into the disagreement were different. It's usually not like somebody's right. And somebody's wrong, you know, like, so it's almost never a situation with smart people were like, Some, somebody's just messed up some logic, right? And usually, it's like, it's usually you, you basically, like, surface what each person's assumptions were. And you find out that, like, somebody had made an assumption that you hadn't thought about, and you're like, Oh, you're right. Like that is actually irrelevant. So your your opinion is like, we should go with whatever you thought was the right thing was and usually, like, both sides have realized something and have baked in assumptions that the other haven't and which is why I say like, most of the time, when you have those kinds of disagreements you really like, push them to resolution, you end up with a solution that's actually better than either of them coming in.

Ryan Rosztoczy 42:45

Yeah, I love that. Okay, other other lessons learned around? Yeah, founding engineers, you're doing team building working on teams? Yeah. Other lessons learned around hiring, getting those teams to work effectively.

Mike Carter 42:59

Oh, wow. So so many, I mean, the Yeah, I think I think at the end of the day, like, Kodiak has done a really good job of staying lean. And I think, to Kodiaks credit in a lot of ways, because the momentum of that industry was to grow, like astronomically quickly, people were raising huge amounts of money and hiring teamed up super, super fast. And so I think that probably one of the hardest things when you know, you have to grow, is to keep the bar very high. And it's, you know, making sure that you're hiring, and being discerning about like, what you're hiring for, not just sort of like scooping up people, there definitely is when there's a lot of hype around an industry there tend to be these sort of like talent, land grabs, and be and people do a lot of these things. But being I think it's it's a sign of discipline to basically work from the bottom up and say, like, these are the things that we need to do. We think that these are the people that we need to actually do them, and then like, go out and find the best people possible for for those things. So I think it's mainly a discipline question. And hiring takes time. You know, hiring is, it's, it's, it's never a good thing, if sort of, like the first person you talk to is like, you know, on your team two days later, and you haven't thought about who else you might hire and all that kind of thing. It's, it's hard to go out and make sure that you have the conversations also depends on on the market. And and, you know, when when there's tons of people at big companies giving out huge offers, that makes it even more difficult to convince people that like, they should take a risk on your startup. So I think hiring is hard. It's important to be disciplined about it. And like, it does pay off. It's sort of this roller coaster where it's, especially as an engineer, and you think, okay, I could spend an hour on this interview, or I could write code for an hour, and you will immediately see the progress made, you know, the code that you wrote, where as that that hour that you spent in an interview may never talk to that person again, right? Like, it's easy to feel like it's time not well spent. But then once you sort of put in the work, put in the hours and eventually make the hires, and you start to see that that person has actually like cranking out work, and it's really high quality. And, you know, if the goal is always to hire people who are better at whatever it is, then you are you see that as higher quality output, then then you would have done, that's when you start to say like, Okay, wow, that was actually time well spent.

Ryan Rosztoczy 45:24

I love that way of thinking about it. I mean, I've definitely had that frustration, same exact thing. It's like, Oh, I've got to talk to a stranger. Again, it's probably not going to be that great and blah, blah, blah. And I can be shipping features, about the way say, of, there's a possibility of a an extended bar increase. I mean, I love that a lot. It helps. I think I'm gonna like, keep them I might, because I think it just helps them, it makes them maintain that discipline. It's so clear how important that is. And it makes it something totally worthwhile. I think we have gotten good at that, but only by not being good at it to start and realizing that. So looking forward to some of the people we'll be working with soon, for sure. Okay, so you're at Kodiak building teams also doing engineering. One of the things that really stuck out from chatting with you earlier was that Kodiak, you are working on safety. Right? Is that right?

Mike Carter 46:27

That was definitely one of the big focuses for me, I was motion planning was sort of like the main sort of engineering hard sort of coding and algorithms focus. But safety was, in some ways, it was sort of like a thing I accidentally ended up working a lot on, if that makes sense. Maybe that needs more explanation. Yeah. How

Ryan Rosztoczy 46:47

does that happen? Yeah.

Mike Carter 46:49

So the way that that happened was, we sort of getting a semi truck takes time, you can't just sort of like, show up, especially in 2018, when everyone was ordering semi trucks, you couldn't just sort of like show up and drive went away. So there was like a, I think it was like an eight or nine month lead time on Sam is at that point. So for the first nine months of Kodiak, we have done everything in simulation. And obviously, you can make quite a lot of progress. And we and we had made quite a lot of progress on our software stack. But then the truck showed up. And it was super tempting to just like, you know, get the truck built up, and then go and try to drive it. But one of the things that I realized is that safety for a company operating or building a safety critical system that has to operate on public roads is an existential question, right? It's like, especially if you just raise money, and you're probably going to need to raise more money at a major safety incident, especially that early would have been, you know, probably prohibitive for further right. So I think the, the big sort of like the insight that I had there was we have to nail this like we can't be like from the beginning, we need to be super disciplined about how we approve new operations, how we decide whether software is ready to like actually go in and test on the vehicle. And it probably is that like, it sounds obvious in retrospect, but but the the industry was maturing as we went, and I think Kodak did a pretty good job of like helping, you know, contributing to the maturation of the safety story in the industry. But But what we did basically was like, we realized that this needed to be we had to nail it. And we basically started from the first parking lot tests, doing a pretty in depth review of like, okay, what are our what's essentially our safety case for this operating domain, right? Like if this if something were to go wrong, if there were bugs in the code, or if there were a system failure, or a hardware failure or something like that? How do we know that we're not going to like crash into an employee's car or like a tree or something like that, basically, making sure that there was always a failover, or some some way that the driver could take over the system would stop itself or something like that. So started from that first time when we needed to go and like, drive a truck. And mainly because I sort of had been thinking like, wow, we really need to nail this. Got myself involved in a lot of the discussion. And then that sort of evolved into me doing a decent amount of the analysis. And so did a lot of safety work, just because it felt very important. And it wasn't necessarily like I done Systems Engineering at Edinburgh. So it was somewhat familiar territory, but like my main focus had been software and motion planning algorithm work. So it was a little bit of like a side job in some some ways, but I ended up putting a lot of time into it. And then we built out a team that's like doing it I think superbly now. So it's it, it was sort of like oh, this needs to be done. You know, like every startup story is something like needed to be done and I happened to be in the in the right seat to do it at that point. So

Ryan Rosztoczy 50:00

Well, so what's so fascinating, we use the word existential. That's exactly what I think in my head. It's, it's not just a problem that you have to solve to the nth degree, like we're talking about earlier. But it's also existential, like the consequences of any failure are massive for the company and other people's lives. And it's also not just a software problem, like you said, you know, you need like real, real life elvers human controlled failures. So, when you're facing a problem like that, like, what was the where did you start like?

Mike Carter 50:39

Well, the The nice thing about starting when you just need to do like a parking lot test is that it's like, pretty simple, you can make sure that there aren't people in the parking lot, right? Like, there's, there's all these simple, simple steps to make sure, it's a sort of, like, increase the safety margin that you have. And in a lot of ways, I think, you know, these things can be iterative. So like, after driving the parking lot, we wanted to be able to drive like, at slow speeds at the test track, you know, and what does it take to go from, you know, two to five miles an hour in a parking lot to up to 25 minute test track or something like that, you basically do this, you basically do like a git diff of like, what you want to do, right, versus what you're doing today. And you say, like, what else could go wrong? So that I think is helpful to be able to do it incrementally. But the final safety story, you know, this, there's pretty well established ways of doing functional safety in the automotive domain. There's like ISO specs, there's 26262 is the one that everyone loves to rattle off. And then there's also like new specs emerging for like autonomous vehicles and things like that. So there are people who are working really hard on doing this in like a very sort of rigorous and standardized way. And that's what it looks like in the future. But as a startup, you know, a lot of times, if you were to try to do that from square one, you'd sort of like only do that, and you wouldn't really make progress on your, like real products. And especially if you're starting at a time when those specs don't exist, you have to do something. So I think this is like, knowing what the delta is between what you're doing now where you need to go next. And then also having like, long, long range sight on like, where do we need to go? And at the end of the day, I think it's sort of like having that forest and freeze view. That really matters.

Ryan Rosztoczy 52:25

Yeah. Well, you said it perfectly, does not. You said it very clearly and simply. But the idea of getting safely to work at a startup and essentially doing the equivalent of planning long term industry regulation.

Mike Carter 52:46

That's a challenge. I mean, there's also you know, we were talking about the magnitude of the of the task for building self driving vehicles. It's it's like kind of hard to express sometimes just how big that project is.

Ryan Rosztoczy 52:57

It really is. Okay, so but you take a little detour, and you get maybe that experience gets you excited about startups, because you end up going to a fund. We'll talk about that.

Mike Carter 53:10

Yeah, for sure. And I think you said it well, like, that experience definitely got me excited about about startups, I knew that wouldn't be a, an exciting course for sort of, like, my future was it to be continuing to try to like, find, find these opportunities for outsiders maybe like leverage contribution by finding problems that were like early and I could put all my energy and time into and that kind of thing. Ended up going to a fund called Ajax health. And it's so you can hear from the name that was in the Health Tech and med tech space. Very different from self driving. There were sort of two reasons behind that one was personal. I lost my mom, and she had always wanted me to go be a doctor. And I basically said to myself, like, Okay, well, I'm not gonna go to medical school, although she, if you were alive today, she probably still tells me I should be going to medical school. But I said to myself, like, I'd like to go and explore that domain. Because it is, you know, that there are people doing amazing work, then it really is impactful. When people come up with solutions to major health problems, it can be like, you know, literally life changing for a lot of people are life saving in a lot of cases as well. So I wanted to check it out. And I also realized that, you know, as I've said, self driving is sort of like this crazy, like, sometimes disconnected world from the rest of entrepreneur ship where they like some, the rules of the game are slightly different. And so I wanted to basically go and like, learn more broaden my horizons, and, you know, to use the cliche there about what it means to build startups and build companies. So it was a really good opportunity for me to do that and kind of like generalize more than than just sort of like being a robotics in The self driving world kind of guy. So that was the sort of what what led me to go on and join Ajax. And my job there was partially to be a part of the fund, where there was sort of inbound deal flow and things like that, where people were using more AI and software in the med tech world. And so Ajax wanted to like increase their fluency in those topics. So that was sort of my contribution to the fund. But also the they asked me to start or help certain one of the companies that they had been interested in starting became a portfolio company called atrium Excel, that was working on non invasive diagnostics for cardiac arrhythmias. So it's pretty fun, it was sort of like this really awesome opportunity. It's to learn more about what investors think about business, you know, that as from from sort of the top down from the capital side of the table, but then also, like, be operating and work on this, this portfolio company that they just started.

Ryan Rosztoczy 56:04

So okay, so I mean, powerful story, like that is crazy and awesome. And also very interesting that it's tied back to how you even started college. Yeah, exactly. But you work on the investor side like that, I have no experience there. I mean, I have friends who are VCs, but you know, I'm not spending a ton of time in that space. Was there anything that really stood out to you as interesting, different than you expected? Or us useful to have going back into the entrepreneurship? World? Yeah, that's your side?

Mike Carter 56:46

Absolutely. I think the one of the biggest takeaways for me is, investors do a job where they need to know about a much broader range of things, then like what somebody's like, my myopic focus in a startup would be so they they're like, generally very good at knowing about, you know, knowing a medium amount about a lot of things. And in almost all cases, if you've been working on a startup, like, you know, a lot more about that specific thing than then then the investor does at least like that. That's kind of how it should be probably. And so one of the biggest things for me to sort of learn about is like, how do investors like, gain familiarity and do that kind of diligence, because it's obviously required to, like get quite deep when you make those kinds of investments, and then how to, like communicate as as somebody who's building a startup who, who like knows all the millions of engineering considerations that they're going to be making, how to communicate, like, really what matters to an investor and like, be able to again, like pick, pick your head up above the trees and be able to say, like, this is where it goes and why. So a lot of it was about communicating, like a lot of learning was about communication. And like, how do you actually like, tell the the story of what you're trying to do in a compelling way. But also, like, at that point, you know, that there was a lot of calibration just coming from the self driving industry where things work differently, all of a sudden had to like, learn a lot more about how investing and you know, rounds of fundraising works in the more general sense in the like venture sense, rather than like, these crazy, massive 100 million dollar rounds.

Ryan Rosztoczy 58:24

I really liked that perspectives. I mean, I think there's an emphasis on storytelling and pitch text, which I think is important, but the perspective you just gave is more of like, how do you effectively communicate when the depth of knowledge is so different? The you don't get stuck up in the weeds that don't matter? How do you talk to them about the ones that do in a way that actually understand? That's really interesting.

Mike Carter 58:55

You Yeah. And I think the I like the you put it really clearly that this is the difference between storytelling and communication. And then a lot of ways like, you do a good job communicating when you tell a good story. But people think storytelling is like, Oh, you're kind of like lying in some you know, like, it sounds like you're trying to paint the rosiest picture where I like the I've always been kind of the type of person who can tell the best story when I understand and believe the thing that I'm saying, like, all the way from top to bottom. And then it becomes a question of how do you say it in a way that doesn't just like make sense in my brain but make sense in the brain of like the people that I'm talking to, which is, you know, it's not always chronological, and it's not always it's like, there's definitely some skill I'm definitely still working on it of like how to how to say something in a way that it's best for the other person.

Ryan Rosztoczy 59:52

Yeah, well, I mean, just thinking about the power of reframing there, from the storytelling to communication if what you are doing As an engineer is trying to understand a problem as deeply as possible and as clearly as possible, and then communicate it like that, to me, it would feel like when you are talking to investor one, you're probably going to come off as significantly more competent than most entrepreneurs, but two, you're gonna have a lot of conviction, because there's no manipulation of the facts in your mind to try and get the money. You're expressing things you're working on expressing things is how you see them, which means there's big opportunity, you probably believe that fundamentally, because you understand the space. Totally. I love that reframing. Okay, so, investor side, you learn a lot, but you also become the CEO for company at the portfolio in their portfolio. And yeah, that probably gives you your first taste of not just founding engineer, but like full operating. Yeah, startup building. Yeah. What was it like,

Mike Carter 1:01:02

um, it was really, I mean, I always enjoy jobs the most, when I know that I'm learning fast, and learning a lot. And so it was, it was one of those kinds of situations where there's tons to learn, you know, the, the figure speech that people use is to have the monkey on your back, and definitely had it there were like, at the end of the day, had to make make decisions, and, you know, hiring decisions, hiring plans, you know, product strategy, r&d, strategy, all that kind of thing, that would have been like, you know, Kodiak hadn't had lots of other people around me and Don, making, you know, those kinds of decisions, etc. So, so for me, it was, it was really cool to feel that, what the weight of that responsibility and like, make sure that I learned as you know, just soak up as much knowledge as I could, and as much experience as I could, for how to do those things. Well. So that was really cool. The company itself Atrio mix, was was an interesting case, because in a lot of ways, it was like born from ideas of from the Ajax ecosystem, a lot of a lot of people were like this should exist, this shouldn't exist. And then as we started to, like, build it, we realized that each person that had been saying this should exist was saying, like a slightly different things should exist, if that makes sense. So a lot of the the task was actually to go in and like do this deep dive of bringing people together and saying, like, okay, there's like, four or five different versions of what this vision is, let's, let's really, like hone it down and get in get into alignment about what this is, you know, and I think a lot of companies have this experience where they, they have to figure out what the company is before you can really like make a ton of progress. So it was cool, doing, you know, being sort of the person accountable for making sure that that that vision became clear. And then at the same time, you know, executing, operating, making sure that the the team got built to do it, and that the milestones were met and all that kind of thing. Hmm.

Ryan Rosztoczy 1:02:57

Sounds like real leadership.

Mike Carter 1:03:01

We're, for sure. Well, has that it was real learning for

Ryan Rosztoczy 1:03:05

sure. Yeah. We're back to the theme you had earlier with. I Kodiak this idea of trying to like unpack a shared understanding, get a lot of smart people around you, and then unpack a shared understanding and then maybe just equally as important for you now that we have a shared understanding, how do we communicate it and make sure that everybody is in the same space?

Mike Carter 1:03:31

Yeah. 100%. As I said, one of the things that I'm so excited about about your podcast is, it's the entrepreneurs experience from the technical perspective. And so I think that there's some some really interesting, at least for me, there's been some really interesting learnings. Especially since I left my job in April, where there's, you know, I think the first lesson and I talked a little bit about this earlier is like, it's, it's pretty powerful to make that commitment. You know, when when you ideas sound amazing when you're when they're your side project, you know, and it's really easy to do like the the most fun parts of them as a side project that like, building the cool novel element of it. But at least for me, and as an engineer, right, I think there may be others who are engineers who are entrepreneurial, really interested. That's a part of my pronunciation there. They may have similar tendencies, where what they what they start to do when they think of an idea is like, Okay, I'm gonna start like building it and see if it's cool. And like, you know, by the time you're in doing sort of like playing that game, you've kind of already missed a lot of opportunity to get a lot of to get learning about what that would look like as a business. And it's pretty hard to do that kind of learning while you're still at a full time. So for me one of the one of the most important decisions See that I made was actually like leaving the job to go and really go and investigate. And it also frees you up to, like, be flexible to be able to change the thing that you think is the best idea. And like really learn, because you haven't already built like a thing, you know, you haven't built a or you haven't got something in progress that you'd really like to finish building. So maybe for me like this is mostly just sharing learning is, is when I when I sort of saw this, this journey more as let me go and figure out what a good business would look like, and then do the fastest, cheapest, like experiments to go and validate hypotheses and learn about what that problem really looks like. It it what it ends up actually being is sort of like staving off the temptation thing right away. So I think that's been a really interesting learning for me, sort of since since leaving that full times. Building right aways is actually often like the wrong thing to do. And there's a lot of other learning to do first.

Ryan Rosztoczy 1:06:02

Oh, my God, I love that. That's so good. So I think one of the things that can be misleading about and I am so glad to hear you say that, because I think that will resonate with me. And hopefully I can hold that in my own mind. Because it is so tempting to go do the fun thing just start doing. So yeah. But I think what a lot of people miss. Usually when people are doing that is because they have years and years and years of experience in the problem ahead of time. And so when they do get to the solution, it's not They didn't just start building it sort of just already understand it really deeply. Totally. So to take time to have that period of investigation. I love that is huge. And I'm getting this thing with you which if I was a VC, I would definitely fund your guests company, which feels like you guys just as founders. What I get from you, at least as a founder is that it feels like you have a knack for knowing when to step back and take the long view, which is not normal. And in my experience, and really challenging for most people.

Mike Carter 1:07:13

I appreciate you saying that. There's really I mean, I think it's kind of like when you're writing code, and you're in the depths of some unit tests for some function, you know, that you're about to write. The view is very small at that point. But if you don't know why you're writing that unit test for that function that you're writing, like, you're gonna go in the wrong direction, and all of a sudden, you're building like the wrong thing. So I think it's kind of one of those things where being able to think and execute at different levels of abstraction, is kind of the name of the game. Probably generally, I don't know, I haven't thought about it. So generally, but certainly in software engineering, and certainly in entrepreneurship, I think it's kind of like an unnecessary way of thinking and just being able to think differently, you know, like, being able to try on different hats and not having like, a whole bunch of like friction to being able to make different decisions and change course, I think, you know, there's a lot of people will talk about this, but I really do subscribe to the the importance of it.

Ryan Rosztoczy 1:08:12

I love it. I really quick just on that whole exploration period. What does that look like? Like, do you would you write down? Okay, I've got some general hypotheses, this is what I think about this space, given my experience, and then I'm gonna get on the phone and just start talking to people and understand what resonates and what doesn't, or, or I'm gonna ask them about how their business works. So I can try and dig out some problem, like, what is what is exploration look like for you?

Mike Carter 1:08:42

Yeah, this is something that I feel like it. It's funny, because it's this skill to develop. And I certainly, excuse me, I certainly feel like I'm, you know, still in the process of developing it. But, like, I think that there are different ways of going about it, you can just go in mind for problems, and then like, figure out what probably a problem that exists and and start solving it. The challenge with that, you know, that's in some ways, like the most rigorous way and, you know, there's some fantastic books that talk about, like how to do that well. But you don't necessarily know what the magnitude of the problem is that you surface. So it could be like, some somebody's specific problem, and then the task becomes like, Okay, I need to, I may have found a problem, but is it actually one that I should go after insult? And then the other way of going about it is like, you know, you have a hypothesis or maybe you have like a technology that you're like, I think that this will change the game for XYZ. But then then you run the risk of being a solution in search of a problem, which is so both sides of these can have like their pitfalls. And I think that you know, there are people who subscribe to one or the other and like criticize the opposite one I you know, as I said, I think the name of the game here is being able to put on different hats and think in different ways. So I think I tend to like kind of alternate between like, you know, what are the problems that I think I know about what are the solutions that might be cool ways of approaching problems. But at the end of the day, there's there's just no substitute for like going out and talking to people. There's some folks who'd like to be sort of like secretive about what their ideas are. And I'm totally the opposite. I think the the risk is much higher, that I convinced myself of something that's actually a bad idea by not talking to people, and the risk of like somebody going and taking it and stealing the idea or something like that, because execution is what actually will, it'll come down to execution. So so I'm, I think, like socializing ideas, especially with people that you sort of, like know, and respect and admire, is really helpful. But also like getting outside of the bubble, like, like, if I just went to talk to the people who I know, think like me, I'm gonna, again, convince myself of something, but going in like talking to the end user or talking to the customer, or who you think might be actually experiencing it. There's just no substitute for that.

Ryan Rosztoczy 1:10:57

Two things in there. I love this idea that like, it's not a like discovery, and investigation isn't a linear space. And so, yeah, there's multiple approaches, there's probably a lot of good things baked into those approaches. There's pitfalls. One isn't going to be right, the idea of using multiple and shifting perspective, I love that, that I will definitely take that with me for sure. Yeah, I guess maybe on that last point, though, if I let an idea bake in my head until I know, it's a really good idea, it is probably the worst possible idea or worst possible solution. Like without fail. I'm just, oh, God, I learned that like, a couple of years ago, I can get it out in front of other people, it's gonna be better. Like if it sits in my head, it's kind of

Mike Carter 1:11:49

Yeah, I mean, it's, it's always fun reading like your engineering notebook from like, four years ago, or something like that, and saying, like, wow.

Ryan Rosztoczy 1:11:59

Yeah, totally. Love it. One question. I've been asking everybody. And this is fun, because you're just about to start yc is, you have any advice for people who are about to start a company, or have just started one. Um,

Mike Carter 1:12:23

I think I feel early to give advice. I you know, we're in an early stage here. And I think like, I'm learning so much, maybe, maybe the advice is like having that open mind going after resources that you know, will take you in directions where you're able to make decisions better, improve your processes, all that kind of thing. Maybe that's what it is. I you know, I've talked about a few things that are sort of like philosophical, in my opinion, of like, being able to try on different hats, taking, taking disagreements and like, actually looking for those disagreements, because usually, that means that there's an opportunity to, like improve the collective wisdom, man,

Ryan Rosztoczy 1:13:03

that was such a good episode, Mike had a lot of really great points and advice. Throughout the show. I'm just gonna call it a couple here. One that really stood out to me was this idea that when really smart people disagree, there's a potential goldmine there. If you can figure out why the disagreements are happening, you can get to a much clearer picture of reality. I thought that was absolute gold. I also liked how he talked about the founders role is a storyteller. And in particular, how, for him, the idea of a good story was one that was rooted in a deep understanding of reality. So taking the founders context and understanding of a problem or a new space that might not exist yet that they really have a lot of knowledge in and belief in and translating that into something that can be community communicated to the outside world, that might not be as familiar with the problems. Yeah,

View Details

2023 Season Trailer0:00/2:301×Prediction for 2023: we will discover there is no black magic involved in building technology and businesses. Join me on The Technical Founder as I meet with engineering founders, CTOs and CEOs and we demystify the work of building modern technology businesses.

View Details

View Details

View Details

View Details

View Details

View Details

View Details

View Details