Dan Manges - Co-Founder of RWX: Finding Your Co-Founder, Engineering Challenges, and Decision Making

Dan Manges  00:00

You just have to have really great discretion around what can wait and what does need to be in place right away. And I think that judgment is one of the most important things to look for in people. And I find that it's usually under emphasized in terms of interviewing, and hiring, and for people just in their own careers, is actually learning how to make better decisions and have better discretion.

Callan Harrington  00:21

You're listening to That Worked, a show that breaks down the careers of top founders and executives and pulls out those key items that led to their success. I'm your host, Callan Harrington, founder of Flashgrowth, and I couldn't be more excited that you're here. Welcome back, everyone, to a another episode of That Worked. This week I'm joined by Dan Manges. Dan is the co founder of RWX. RWX develops software engineering tools that optimize build, and test performance, reliability, and developer experience. Its flagship product Mint is a generation newer, continuous integration platform that gives engineers unparalleled capabilities to optimize their builds. Dan was previously the CTO of Route, a technology powered car insurance carrier, which he co founded in 2015, and took public via an IPO in 2020. Before Route, Dan was the CTO of Braintree, where he built a payments platform that PayPal acquired in 2013, for 800 million dollars. I learned a ton in this episode. We talked about the challenges unique to engineers and scaling engineering departments. Why these challenges make it so important to have good cross functional communication, and why it's critical to have great engineers right from the start. And growing up on the sales side of the house. This conversation gave me an entirely different perspective, seeing it through Dan's eyes as an accomplished CTO. Dan also gave great advice on what to look for in a technical co founder, and what he looks for in a non technical co founder. If you've ever thought of starting a tech company, this is something that's always at the top of everybody's mind, and how important it is to have the right co founder from the beginning. Now the part of the conversation that I found most interesting, and candidly, a personal wake up call, was the importance of decision making. More specifically, deciding what problems to work on now, versus which ones to put off until later. And I thought Dan's advice was excellent for anybody who's making decisions in a high growth company. So with that, let's jump into the show. Dan, welcome to the show.

Dan Manges  02:57

Thanks for having me, Callan.

Callan Harrington  02:58

I've been excited for this interview for a couple of weeks now. A place where I would love to kick this off is, you know, I know when you were at Thoughtworks, you were working on a problem that's even passionate to you now. Can you walk us through? What was that? Tell us that story a little bit?

Dan Manges  03:13

Yeah, I began my career in software engineering, working for JPMorgan Chase, spent a couple years in the enterprise, and then I joined Thoughtworks in 2007. And Thoughtworks is a small consultancy focused on helping enterprise companies build software. And that's where I really learned the most about software engineering. I worked with some of the best engineers I've ever worked with, and I was working on a fairly sizable team at the time. Engineers have something that they do, which is called like a build and test process, for code changes that they make. So every time a software engineer makes changes to code, it goes through a build and test process to make sure those changes are working correctly. This process is one of the most impactful parts of an engineer's productivity. Because it's a feedback loop. They're making changes, checking it, making changes, checking it, and running the cycle multiple times per day. Well, our project was really large, we had a really big team of engineers. And as a consequence of that, our builds became slower, the test took longer to run, and that feedback loop really slowed down. But interestingly, this was back in 2007, which in some ways isn't that long ago. But it's long enough ago that cloud computing wasn't a thing. So we had to try to figure out how to speed up this process. But we didn't have a fleet of cloud servers that we could go and get to make this process faster. So I actually wrote some code with some of my teammates at the time that we did all of our software engineering on Mac Pros, like the big desktops. And we recognized that we had a lot of them in the room. And largely we were working on them, but they weren't all being fully utilized all the time. So we actually wrote a distributed test runner that anybody on the team could take the code they were writing and run a command. It would take their code, it would copy it to every single desktop we had in the room, and distribute the test suite across all of those machines to run it in parallel, and speed up that feedback loop. That worked fairly well for that point in time. But it's pretty funny in contrast to the tools that you have available today, with cloud infrastructure, and ways that engineers can accelerate that feedback loop right now. Although in a lot of ways, I think these problems still exist, despite fifteen years of progress in software engineering.

Callan Harrington  05:25

Why is that? Why does this problem that's been around since, would you say 2007, why is that still there?

Dan Manges  05:31

Some of it comes down to the inherent complexity of software projects. I think, you know, a lot of people look at it as an engineering discipline. But in some ways, it's laughably primitive. There aren't great ways for engineers to solve problems and build software, and have a lot of confidence that they're doing it correctly. So it's not like construction, or civil engineering, or other types of engineering, where there's a lot of science and standardization and certain ways that people have discovered to do things. Software engineering is an interesting blend of science and art. And a lot of what you think would be a solved problem, as you look at mobile apps, as you look at web apps, and you see and feel like there's a lot of commonality across them. There's just so many different ways that engineers approach projects, which then makes it hard to build tools that build on top of that, because there's just an inherent lack of standards in the way that software is built, which ends up- the result of this is that engineering teams end up with a lot of bespoke solutions. They end up with tools that help on their project with their application that they're building, but are difficult for other engineers to use in other contexts. On top of that, you have most of the source code being proprietary. There's tons of open source, and you can kind of talk about the contrast between open source projects and proprietary code bases. But most companies consider their software to be intellectual property, which also makes it hard for some of these techniques that are being developed within one company to be released and shared and reused across other companies. And the things that do tend to become open source are certain things around tooling. But sometimes that's less helpful than seeing the ways that software engineering teams are constructing their projects and their code bases and their architectures as a whole.

Callan Harrington  07:22

So okay, you brought up a couple of things that are interesting for me, and I'm going to try to play this back for my audience and for myself, most of all. But what I'm hearing you say is how it's built, because software is built so uniquely across one company to another, or even maybe one team to another within the same company. There isn't uniform template and structures that people can use, because everything is so unique from each one to another. Is that, first, did I understand that correctly?

Dan Manges  07:50

Yeah, that's correct.

Callan Harrington  07:51

Is that why- I've always heard this, because I've been in tech companies, of course, I have not been on the engineering side. But one of the things that I always heard was, it's not as simple as just going out and hiring a ton of engineers, because they're not just going- it's not like these engineers are going to be productive from day one. Is that why? Because they have to learn kind of the unique setup of the code that they're going into with that particular company?

Dan Manges  08:15

Yeah, that is exactly why. And surprisingly, even if the engineer is familiar with the programming language that's predominantly being used to build a project, there's still so many different ways to leverage that programming language, other tools to use in conjunction with the language, certain web frameworks, other coding libraries, different conventions that people have in terms of how they structure their projects, that that engineer is going to have to ramp up on. And that's in addition to usually ramping up on the domain, and the business that they're trying to build, and the purpose of the software. It's really difficult to modify software if you don't understand the system and the business as a whole. And it used to be the case in software engineering, that people tried to approach us by writing very detailed and specific requirements about exactly the change that needed to be made. So that a product manager would produce that, and maybe an engineer would go take those instructions and try to implement it. But in practice, businesses evolve so rapidly, that trying to get that level of specificity around how the software should work isn't the most productive way to build products. You're really much better off having your engineers understand the business so that they can look at what the code is doing, relate that to the product experience, and the business's workflows, and then make modifications to it to try to provide a new feature or piece of functionality.

Callan Harrington  09:33

Alright, so this might be a spicy hot take here. Should engineering own product or should product be by itself?

Dan Manges  09:42

I think there's a lot of different ways you can do it. And there isn't one right answer. One thing that I recommend a lot, as I'm talking to engineers or people who partner with engineers inside startups or even later stage companies, is that it's a lot easier for, in my opinion, for engineers to understand business value, then it is for a product manager to understand engineering complexity and trade offs. So usually, I think a lot of companies tend to not utilize engineers as much as they should, because they assume that there are technical people that are just interested in technology and aren't going to be interested in the business. But if you can take engineers who have the ability to understand both sides of that, those are usually the best people to come up with high leverage solutions. So the classic, how do you get 80% of the business value for 20% of the effort, because they're going to understand the intimate details of what's necessary technically, to achieve a certain outcome with the product. And it's really difficult for non technical people to understand that. This concept is illustrated really well by one of the XKCD comics, where it's a dialogue between conceivably a product manager and an engineer. And the product manager says, I want to build a piece of software that would tell me if a photograph was taken inside a national park. And the engineer says, yeah, no problem, really easy. Photos are tagged with geolocation coordinates, there's a database available of where all the national parks are, I can pull that metadata from the photo, compare it to the database, cross reference it and a little bit of work, I can tell you if a photo was taken inside a national park. Then the product manager follows up with, "and I wonder if there are any birds in the photo." And the engineer says that's gonna take a research team of five PhDs and two years to solve. Because, you know, the first was a geolocation problem. And the second was like a computer vision image recognition problem. The technology for the first exists, but the technology for the latter doesn't. And to somebody who's non technical, those two problems sound very similar. Tell me if this photo was taken in a national park. Tell me if there's a bird in this photo. To somebody who's non technical, you would think those would be about the same level of effort. But they actually couldn't be further apart in terms of the difficulty.

Callan Harrington  11:58

You know, you gave me the only convincing argument why sales shouldn't own the product roadmap. I'm kidding. For everybody listening, I know product people are listening and like, no, that's a horrible, horrible idea. So you know, it is interesting, something that you brought up that makes me think about this is one of the companies I was at did a really good job, they really were very intentional about trying to bring the sales and the engineering teams together at events and things like that. And it was B2B for just to set the context for that. And when you just described that, I mean, I didn't think about this at the time, but it very well could be a lot of it is, part of it is, how do we get sales to not over deliver on what can- because, and I'm speaking for myself, right? I've been in sales my entire career, but how do we understand what's actually possible and what's not possible? And then from the standpoint of the engineers, what are the challenges that they're doing? Right? And you already get that within product requirements and things like that. But what are the kind of those challenges? Do you feel that that's advantageous? Do you think that there's benefits that can come from that? If so, what does that look like? Or doesn't really matter? If they- I mean, yeah, it's good for culture, the overall company, but I don't know what other additional gains that they're going to get out of that.

Dan Manges  13:11

I think the thing to really focus on is sharing as much context as possible in both directions. The thing that a lot of engineers will ask for is to be presented with problems and not solutions. I think that's a little short sighted, maybe, though. I think it's reasonable for like somebody in sales to go up to an engineer and say, I want to be able to do this, and just propose that solution. But I think it's helpful to also say, and here's why, or this is why I want this, this is what I'm actually trying to accomplish, because I think that's where you get that collaboration between people with different perspectives, different disciplines, who can come together and identify a better solution than anybody within a single discipline can. Similarly for engineering, sometimes it takes effort to share the technical details, and the trade offs, and try to figure out how to explain a technical concept to a non technical person. And I've talked to people that want to be able to short circuit that, and just want to be able to make whatever decision they want, and work without having to interface with other people and go through that effort. But if an engineer is willing to take a shot at explaining that, and sharing some of those technical details, and the trade offs, the other person isn't gonna totally get it, but they're gonna understand a little bit more of it. And then that helps them ideate and come up with maybe alternatives to what they were thinking or ways that they could approach a problem differently, once they start to understand, oh, like, this is easy to do. This is hard to do. What if we do this instead? Actually, if you're telling me you can do this tomorrow, and it's gonna be super quick? Yeah, I'll take that today. Instead of this thing I want that maybe it's gonna take multiple months of development effort and get put on backlog behind some other initiatives.

Callan Harrington  14:48

That's so important. I think it's so important from a sales leader perspective in that, like, truly I do think it's important understand that. Now, I've had some great CTOs that I've worked with that have went into the weeds. And I asked for that, I was like, can you tell me how this really works? Well, I didn't under- I understood 25% of what it was, because it's just way too tech- especially in like the blockchain world, like that was really, really, really technical. But I think the piece is important to know is, is this something that really is the example you just mentioned with the bird? I think that was a really good example in that, you know, I may have came to you and said, hey, like, our customers want the birds, every prospect like I can hit our forecast if you just put the birds in there. And if I know it's like, okay, well, that that technology may not even exist right now, so it's just not going to happen. Then I can go back and say, okay, well, here's, you know, number two, number three. Well, number two, number three still might unlock a piece of the market that we don't have today. If I'm hearing you correctly on that, is that essentially what you're saying?

Dan Manges  15:49

Yeah, definitely. And sometimes there isn't an opportunity for that. Sometimes there is no shortcut or high leverage solution or way to think about the problem differently that's going to massively accelerate the timelines. But sometimes there is, and that makes a really big difference.

Callan Harrington  16:04

Yeah, that's really interesting. A place I want to jump to is, so you were working in the consultancy. And you mentioned you learned a ton, which I, I tell people all the time do a year or two of consulting, because you have to figure it out. Like if you're selling something to a client, you've got to figure out how to do it. When you see these different pieces, you're going to learn so much. So I think that's such an interesting point that you made. How did you get involved with Braintree just to begin with?

Dan Manges  16:29

Yeah, I'll echo what you said around consulting. I learned a lot because I was working with really talented co workers on just a really talented team. And also, because Thoughtworks was very great at circulating ideas among different project teams. So I felt like I was learning not only what was happening on my project, but also what was happening across other projects in the company.

Callan Harrington  16:49

How did they do that?

Dan Manges  16:50

They would host internal events, bring people together, everybody at Thoughtworks traveled for the most part, but they'd have days where they would bring the company in. They would also connect people that were working with similar technologies, different projects, everybody had a mentor, that mentor had been at different clients, people would rotate between projects pretty frequently. So somebody would join your team that was just coming off another project with another client. And it was a very collaborative environment. And I think that helped, because I felt like again, I was learning not only what was happening on my project, but what was happening across dozens of other projects inside the company.

Callan Harrington  17:22

Do you believe that had a big impact on what you said to begin with of- because it feels like, and I could be totally making something up here, but it feels like in that environment, you have to have templates and structures in order to be successful. And I say that from the standpoint of people coming on and off of teams. My guess is you can't have this super long ramp period in an environment like that, is that correct?

Dan Manges  17:46

That's partly correct. But Thoughtworks also did a lot of pair programming. And that informed a lot of how I approach building software engineering at other companies I've worked at. Because I gained a really deep appreciation for the way that somebody can learn something when somebody is guiding them through it, as opposed to the experience that a lot of people have, which is they're dropped into a company their first day on the job. And they're trying to figure out how things work, how things are set up, why things are the way they are. There's a lot of institutional knowledge to try to absorb, and I think the best way to convey that knowledge is through direct mentorship, and collaboration with other people. That goes against what some engineers and even people, I guess, in other disciplines want. Where usually people complain about a lack of documentation. And it's a very frequent complaint I hear is, I can't figure out how to do this, somebody should write it down. And there are some good reasons for that. But I also find that trying to maintain and curate those knowledge bases is really hard. They go stale almost as fast as they're created. And I actually think people under appreciate and underutilize, embracing the fact that there's a lot of institutional knowledge in the people that are within an organization, and having those people take a direct effort to ramp up new people that are joining a project. Obviously, this, there's implications of this retention becomes super important. But I think that's a really good way for somebody to be brought into a company. So you asked me about the need for standardization, and even within Thoughtworks, I would say that didn't exist. The thing that we learned the most and circulated the most were probably the edges. Like what were the worst ideas? Like what should we not do on this project? Because somebody tried it on another project, and it did not work. And what were the best things? Like what should we really adopt? Because this was a great technique for solving this kind of a technical problem or structuring a code base or something like that. But it was really just the extremes, and there's a big area in the middle of just different ways of doing things that aren't impactful enough to totally shift the way that it's being done, but do result in differences that then, like we've been discussing, make it harder for engineers to ramp up make it harder to have technical standards across the company. And this is why it's so important for startups, especially, to really focus on having the best engineering team they can get to seed a company. Because that foundation that you lay, is so impactful for subsequent work that's going to be done. Because it's really expensive, and expensive in time and money and business impact, to go back and try to change those decisions and rework it. And usually you won't. You'll just live with something that probably isn't ideal, and have to tolerate that for a really long time. Because ultimately, you feel like it's better to do that than it is to carve off a big chunk of your engineering team and go back and have to rebuild something that you've already built.

Callan Harrington  20:50

So to play that back, what I heard at the end there in particular, is get a rockstar team right from the gate. Because if you if you don't do that, and you've got to rebuild this, as you're starting to really grow, it's gonna be a big problem. Did I hear that correctly?

Dan Manges  21:06

Yeah, absolutely. I encourage every startup founder I talk to to get the most talented technical team they can at the beginning. They're better off paying for senior engineering talent, than they are focusing on less experienced engineers, just because of that cumulative and compounding effect of the technical decisions that those people are making in the early stages of building technology for the company. For most companies, now there are some that maybe are truly prototype, truly R&D, not even sure if it's a good idea. And there, maybe they just need somebody to throw something together real quick, so that they can kind of play around with it, see how it might look, put it in front of some prospective users, and get feedback on it. But for people that do have conviction behind what they want to build, and how they want it to work, definitely better off just getting the most senior talent that they can.

Callan Harrington  21:55

Okay, this brings up a question that I'm really curious about is, how does a business founder, so somebody may come from a sales background, maybe I'd even throw product in there as well, but they're not technical, they're not the ones that are the actual engineer behind this; how do they find you? How do they find the technical co founder? What are you looking for when you're looking to join? And what did you look for when you joined Braintree? What did you look for when you joined Route? What was that?

Dan Manges  22:24

Yeah, I'm happy to talk about it from both perspectives, both what I would recommend a non technical founder look for and what a technical founder should look for. That was the seat that I was in in terms of a startup that they wanted to pursue. You asked me about that transition to Braintree earlier. And after a couple of years of doing consulting, I felt like I really wanting to work on something that I could pour myself into for the long run. Consulting kind of leads towards hopping in and out of things. I thought I was making good decisions on the projects that I was on. But the projects weren't long enough to really see the long term implications of what those decisions were. And I wanted to have that experience, I wanted one thing to focus on and pour myself into. Also, fundamentally with consulting, the business model is billing your time. I felt like in a certain way, the most value I could provide to my company was to bill more hours, which isn't quite true. There are other things I could do to increase the profile of the company, make sure the client was happy that the client would retain us, they'd refer other clients, that other engineers would want to come work there. But I really wanted to work on a product company, I really wanted to work on something where the value that I could provide, I felt like it was more scalable than what it was in consulting. And that's how I ended up at Braintree, a software engineer that I'd worked with when I began my career at JPMorgan Chase was there. And I'm eternally grateful to him for pulling me in to that opportunity. It was an early stage payments company, very small, just a couple of software engineers that were pursuing building some new technology in that space, and decided to join. It wasn't one of those like high profile, high growth startups, it was actually a more of a traditional payments business that had no technology at all. And then the founder there was interested in trying to build some software to close a deal that he couldn't close with the products that he had been working with before and really wanted to create some custom technology for that. And that's when I joined. And the thing we started down this path talking about, what you'd look for in terms of a technical founder, and what a technical founder maybe can look for in a domain expert or a business partner. And the thing that really attracted me both it at Braintree and Route was partnering with somebody that had really deep domain expertise, that really understood the space, understood what the opportunities were, and could help figure out the right applications of that technology. My career has largely been in competing in existing markets, like Braintree didn't invent payments, online payments. Route, didn't invent insurance, didn't invent car insurance, didn't even invent car insurance based on how you drive. Other insurance companies had done that. But there was this opportunity there to leverage technology in a new way to have a really disruptive impact in those industries, that people felt like otherwise were commoditized. And that's what I'd look for in terms of opportunities I pursued. In the other direction, I think it's always helpful for a domain expert or a non technical founder to look for a founding CTO, that is clearly passionate about technology, and has a deep level of technical expertise, but is also really enthusiastic about solving business problems. Because you want an engineering leader who understands that the technology is only useful in so much as it has some sort of impact on a business, and its customers, and the service, and the value that you're trying to provide. And some engineers do get caught up in technology for technology's sake. They want to use the hottest technology in the cloud distributed network, Blockchain thing, or whatever. And they're more focused on that than they are, like the customer, and the business, and the value that they're trying to provide. But if you can get somebody that is passionate about what the technology is in service of, but then also really has deep technical expertise, this now comes back to what we talked about a few minutes ago, around identifying those really high leverage and high ROI solutions so that you can try to accomplish really big things with really small engineering teams.

Callan Harrington  26:16

Do you have an example of that? Like, what would be kind of that high leverage situation? Or is that, this co founder has got deep domain expertise, they know where the gaps are, we've got a ridiculously good engineering team that could build a product to fill that gap. Is that- would that be an example? Or what does that look like?

Dan Manges  26:32

Yeah, I think an example is, using Route, I think we're not going to quite have enough time on this episode to go into the full level of explanation that would be necessary to really convey this. But it's pretty crazy when you propose building an insurance company from scratch. Insurance companies are- Progressive is a fifty billion dollar company that's been around forever, they spend hundreds of millions of dollars on technology projects, and you look at that space, and you ask: how can we create the entirety of the technology that we need to start an insurance company from scratch? And that's a really big challenge. I think the only way that you can do that is by having that scale in mind from the start and figuring out how to design your applications and systems, so that you can try to tackle that amount of effort with a small team in relatively short order. Which means some of the things that we've also been talking about, on this episode around standards, and architecture, and identifying high leverage solutions, are just so important to have embodied in the early founding team. And I was fortunate at Route to have several other engineers who joined in the early stage that were also very good at this and very focused on it. And that led up towards us being able to build a lot of technology in relatively short order with a really small engineering team.

Callan Harrington  28:00

So one of the things I'm curious about, and this could be a good example of that, what did you learn at Braintree that made it easier to really launch and grow Route? Because Route grew. I mean, as I understand it, from you know, it took a little bit to get product market fit. But once you got product market fit, it was a complete rocket ship. What was some of the biggest learnings you had at Braintree that you brought over to Route? And I would say, was there anything on the flip side of that where it was, because I already went through this, it actually made this a little bit more difficult for me?

Dan Manges  28:31

One thing that generally happens when people have gone through a startup experience, or high growth experience, or been at bigger companies, is you start to really feel the pain points that you have from having gotten to that stage. And you really want to avoid experiencing that pain again. And I think that makes it easy for people at startups sometimes to try to be proactive in solving problems that end up detract from whatever objective they have as a business and the thing that they're ultimately trying to figure out and prove. So, for example, I think there's a lot of activities that can go into building a company that aren't directly impactful to actually figuring out if you're building a valuable product, if you're putting things in your customers hands that they're going to find useful. And you know, that happens, especially on the engineering side. There's, you know, ways to structure your databases, that you're not going to run in to scaling problems. There's ways to deploy your web servers, and architect your infrastructure, and ways to set up your alerting and monitoring systems. Most of these things aren't a problem until you build something that people are using. But I've worked with somebody that always characterized these as champagne problems, because they're the problems that you only have once you're successful. And I think sometimes you have to be really careful not trying to solve those problems at too early of a stage, because you end up spending a lot of time on things that are may not be relevant at all, if you actually fail to build a successful business. At the same time, there are certain things that you can't cut corners on, like information security, you have to be responsible with your customers data, things like that, that you do have to make sure you address. You just have to have really great discretion around what can wait, and what does need to be in place right away. And I think that judgment is one of the most important things to look for in people. And I find that it's usually under emphasized in terms of interviewing, and hiring, and for people just in their own careers, is actually learning how to make better decisions and have better discretion around those things.

Callan Harrington  30:35

How do you interview for that? How do you evaluate that?

Dan Manges  30:37

I find that the best thing to do is to dive deep into situational experiences. So those are the classic "tell me about a time when" type questions. But really probing, not just in can this person recount what happened, but what did they think about their involvement, other people's involvement? Are they introspective around the decisions that they made, the factors that caused them to make those decisions and whether or not they were the right ones? I think if you can find a high degree of introspection, from people's past experiences, that usually bodes well for their ability to come into new situations and make good decisions. Because I'll find, as I've done that probing, you'll find people that are fairly arrogant, feel like things that went wrong are always the fault of other people and not them. You know, they'll blame the other people in the company they were in for those outcomes. They'll attribute failures to external factors. And sometimes that is the case, that external factors resulted in a startup failing. But I think you want people that are really cognizant of their own role and the decisions that they made, and the consequences of those decisions. I think the people that do that the best are some of the best people to hire in almost any role.

Callan Harrington  32:01

I totally agree with that. I think personally, as well, it's any position, if somebody that has the ability to say, here was my part in that, this is what happened. Yeah, we had some things going against us, sure. It's easy to put it on those other things. And like you said, very often those things are right, there was nothing that you could do, just it was bad timing. And sometimes bad timing can kill a good company. There's usually something in there where it's, speaking for myself, I brought on a team way too early. It's exactly what you just said, oh, man, just when you were saying that, I was thinking, I was like, I'm building on a team, of e a company that- we're probably two years from when we need that kind of team to be able to execute on this. As opposed to what I thought I heard you were saying was, here's the problem. We just need to rapidly iterate on this problem. And once we know that we can get this problem, and this starts being repeatable, and other people are agreeing with us that yes, this is the problem, and yes, you can solve this. This is great. Okay, now start building into that next piece. It's almost kind of like, you don't want to read a book of a problem you're gonna have in two years, you want to read a book to help you solve the problem now.

Dan Manges  33:11

Yeah, yeah, that's a great analogy.

Callan Harrington  33:13

That's so interesting. I love hearing that just in general, because it's something I personally struggle with, for sure. Even with this business now, like I'm looking two years ahead, like, this is two years old, like there's no chance. Doing that is not going to help anything I'm doing now.

Dan Manges  33:27

Totally. And I run into that with my current startup, as well. Built a fairly large engineering team at Route. We had about 250 software engineers and ran into a host of problems. So going into a startup now, I'm like, I really want to do a couple of these things differently. So, you know, next time I get to that point, I'm not gonna feel that pain so much. But there's a lot of things that we tried to do in the early stages of building the company. And fortunately, I have a great founding team around me that we work together to figure out just how to simplify things as much as possible. And some of those ideals that we had starting out building something from scratch and the way we wanted to do it, we've shifted because we recognize that it's just not important for us to solve right now. And, you know, thankfully, I have a team of people that are really experienced, that really understand that. And we're just intensely focused on how we can make an impactful change to software engineers' productivity through the tools that we're currently building.

Callan Harrington  34:17

Okay, so this brings up a question. You had- Braintree exited Pay Pal just under a billion, Route went public. Why do this again at all?

Dan Manges  34:28

I've been passionate about this problem for a really long time. I shared the story at the beginning of the episode around the efforts I went through fifteen years ago to try to speed up this feedback loop for engineers. I think there's two parts to the answer to this question. The technical part is I feel like software engineering has tremendous potential to improve products, improve services, improve experiences that people have across so many aspects of their life. And I've had the experience of doing this in certain domains, I've had the experience of improving the payments experience. Braintree was the payments processor for Uber, built the technology that every time somebody gets out of Uber, their system worked with ours to handle that payment, and create that experience. And that was really fun and rewarding. And I had the experience that Route of building an entirely better way for consumers to get car insurance, and to be priced more fairly based on their actual driving behavior, instead of primarily on the demographics or things like education and occupation, and had that impact there. But behind those efforts, is technology. And I feel like now I have the opportunity to improve that process and improve those tools and amplify even further the impact that software engineering can have across a lot of different aspects of life, to hopefully improve the quality of life for people in a lot of different ways. And having that opportunity is something I'm really excited about. I think personally, I also just learned that I like working on things like this, between Braintree and Route, it was actually about two years, and at a personal level, was the most difficult part of my life by far. I had actually left Braintree shortly before the acquisition, and moved back from Chicago to Ohio, and had some flexibility, so I didn't need to go out and get a job right away. And then that's when Braintree got acquired. And that really created a lot of flexibility for what I wanted to do from that point on. And you would think that would be like a very good thing. But I found at that time of my life, the question of what's meaningful to me, and what do I want to do with my life to be openly kind of overwhelming. And it was also difficult to talk about, because I felt like I was in such an incredibly fortunate position to be struggling with any aspect of that, was something that was hard to admit and openly discuss, which led to a period of really severe depression. So I very thankfully was able to work through that. And when I started working on Route, it made a really positive change for me. And I realized that I get a lot of enjoyment at working with talented and exceptional people to create things from scratch. And while I have a lot of different ways that I'm fortunate enough to be able to spend my time doing now, I want to spend my time doing this. And I think I've learned that through the experience that I went through before.

Callan Harrington  37:41

Man, I appreciate you sharing that story. And I've heard similar things from people that have went through similar exits, where it's almost kind of: what do I do now? It's one thing to think about, if I could do anything and money wasn't an issue, what do I do? But then actually having that option, there's a lot of options in what you can do. So I do think that that's excellent, you were able to kind of go in there and find that. So I appreciate you sharing that that story. One of the things I'm curious about is, it feels like, and I could be making this up, so I'm curious get- is RWX your passion project? Like are you so, like it's just hearing what you're saying in this problem, you know, that you've been working on this since 2007. You still came back to it. Is that your passion project? Is this your missionary type role, as opposed, not saying you were a mercenary at these other companies. But like looking at it, like you did kind of come in there, and grow these things up, and exit, and were gone. But this one feels like more of that missionary passion project. Am I wrong on that? Or what does that look like?

Dan Manges  38:46

No, you're absolutely right. And this is the thing that I want to be doing right now. I want to have a transformative impact on the way that software is built and the things that software, the outcomes that software is able to create, in a variety of ways. But I will say I'm also very practical, mindful of what it might mean to do that, what the challenges are, what the limitations are. I anticipate that I'll be pursuing this for the long run, but also learning a lot as we go. And I think it's a huge challenge for a variety of reasons. But I think the opportunity is there. And only time and a lot of effort will tell about the impact that we'll be able to make. But I certainly intend on pursuing this for quite a while.

Callan Harrington  39:34

What drives you more, the opportunity or the challenge?

Dan Manges  39:38

It's all in, in the outcome? Well, I don't know. Maybe. How do you think about opportunity and challenge differently? Or from your perspective, like what-

Callan Harrington  39:46

Opportunity is, this could be massive, well, it's 2007, the problem's still not solved. So then if somebody does solve this, you're gonna have a huge financial gain. You could build a giant company, all those other things. The challenge is this hasn't been done since 2007. I just want to see if I can solve this. If I can solve it, that'll help a lot of people. That's great. I'm excited about just trying to solve this. Route's a great example of this as well. There's something that- it's not, it's not my guess.... And I have a background in insurance. But all these carriers would love to do it in a different way. But they're giant, giant companies. And are they going to tackle this challenge? And what you need to do in order to underwrite in a different way? That's kind of passion around that challenge. What do you think that is for you? What's the bigger driver, I should say?

Dan Manges  40:36

Yeah, I'd say between those. For me, it's the opportunity. I know a lot of people are motivated by this isn't exactly what you described, but kind of the chip on the shoulder mentality, or the, I want to be the one to solve this, you know, type of mentality. I think, for me, that's not so much it. Like, I'd love it if somebody else would solve this. You know, I think this is about the opportunity that could result from being able to find and discover better ways of building software and to share those ideas. And I think just that concept itself is inherent to software development. It's why there's so much fragmentation now, because so many people are trying to discover better ways of building technology. And they're doing that to an extent to which almost every single project is bespoke in some way. But, you know, what I really want to do is actually make that impact, not just for the sake of proving that it can be done, but for the actual impact that it can have.

Callan Harrington  41:33

I want to ask this, because I think it's important.When you have a real deep connection to the company, and the company's mission, and this is really mission driven to you, do you find that motivates you in a different way on a day to day basis?

Dan Manges  41:50

I think it was fairly the same for me, in my past experiences. I think, what I looked at, especially going into Route, it felt like there was a low probability of success there. I already described how daunting it was to try to build this insurance company from scratch. But I looked at the opportunity as the kind of thing where, even if it failed, I would have been happy and proud, and have learned a lot, to have spent several years of my life pouring myself into that effort. And I think that's how I feel now. I think it's the same for me. I don't know if whether what I want to do with RWX is possible or not. I think I'm passionate enough about it that I intend on pursuing it for a very long time. But it's also the kind of thing that I think is worthy of pursuit in a way that even if I fail, I will have been happy to have given this a shot. I think that's how I think about it. So actually, from my perspective is actually more similar than you might think, on the surface, to my past experiences, even though this one is pursuing something that's more directly related to my discipline, my expertise. Whereas the others were applications of that in specific domains. I think there's actually a lot of similarity there.

Callan Harrington  43:09

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

Dan Manges  43:18

I think the advice I would have liked to have had then was to be more patient and take a longer term outlook on almost everything that I was trying to do. Like one quote I love is the one that people often overestimate what they can achieve in a year, but underestimate what they can achieve in five. And it's hard, when you're early in your career, to value experience because it feels unattainable, except through waiting. Like the only way to get more experience is to have more experiences, to like spend more time, to just wait. And I think I was always very eager to optimize, to learn faster, to read more books. And there's a lot of good that comes from that. But I feel like I almost just got lucky being in the situations I was in. It wasn't as intentional as maybe even it could sound in hindsight, when you when you have a little like revisionist history behind it, with the opportunities that I pursued, the people that I was surrounded by, you know, the things that I learned. And I think I learned a ton at every step along my career. But I think mostly because I was just surrounded by really great mentors and really great people. And, again, that wasn't entirely intentional. So now, you know, I've talked to a lot of people that want to be a co founder of a technology startup. And for a lot of people I encourage them to join an early stage company instead, like one that's a little bit further along, and just find the most talented team that you can. Don't even worry about like the problem space a ton, but just find the best people they can, really understand things from their perspective, being alongside them and those efforts, because they'll just learn way more than they will from any book or blog or article or podcast. Although some podcasts are quite, quite helpful. (laughs)

Callan Harrington  45:08

Only like one. (laughs)

Dan Manges  45:09

Hope everybody's listening. Yeah. So I think that's probably the most helpful advice I'd give.

Callan Harrington  45:13

I'll add to that, just one piece to that of the the relationships that you will build by going into those companies first. You never know when those are going to come back around. Never burn a bridge, never do any of that, you just never know when those things are going to come back around. And I've seen it with your team. Your team's followed you for years. Or I should say, you guys have worked together for years, right? And that trust, that's hard to replicate that, and so important when you're going in to build something like that.

Dan Manges  45:42

Eight of the first ten people I hired at Braintree were from Thoughtworks. And they weren't all people I'd worked with directly. Some people were second degree connections. But you take a company of hundreds of people, and you hire eight of the best ones, and you end up with a really talented team. And it was a bit harder for me in the transition to Route, because I moved from Chicago to Columbus to source in-network. But now at RWX. Again, I have some of the best engineers that I worked with at Route there and a few people we hired out of network or second degree connections, who are exceptionally talented as well. So a great mix of past experiences, but some new ideas and fresh relationships, and really grateful for those relationships that I built along the way. And yeah, I mean, you're totally right. It's hard for people early in their career to know what value might come from the kind of relationship they've had with somebody over five or ten years, because you just haven't had that at that point in your life, but it's a tremendously impactful thing.

Callan Harrington  46:39

Dan, this has been a blast, man. Thanks for coming on the show.

Dan Manges  46:41

Yeah, thanks for having me, Callan.

Callan Harrington  46:42

I hope you enjoy Dan and I's conversation. I love the conversation around decision making, and why it's so important to focus on the problems that you have now. If you want to learn more about Dan, you can find him on LinkedIn in the show notes. Also, if you liked this episode, you could find me on LinkedIn to let me know. And if you really want to support the show, a review on Apple Podcast or Spotify is very much appreciated. Thanks for listening, everybody, and I'll see you next week.