Building a Resilient Tech Business: Insights from CarWow's CTO David Santoro

Hello David, welcome to the show. How are you feeling?

Very well, very well. Nice to see you.

Ah, nice to see you as well, David. So, uh, before we kick off, David, let us know who you are, how your journey looks like in the tech industry, what you're currently doing, and anything else listeners would be interested to know about you.

My name is David Santoro. I'm the CTO and co-founder of CarWow. It's a car-changing marketplace. We founded CarWow roughly 13 years ago. And I was the first engineer there. And before that, I worked for other web companies through consultancies, typically. I used to work for ThoughtWorks, So I've kind of seen a few companies, how they work, uh, how the engineering works, how the culture is, uh, that actually that was some of the inspiration for me to start my own company.

That's a very, very interesting you saying this. So you basically felt out the businesses and you were like, you know what, I think I could create a business which is just so much better environment-wise.

Well, yes, I think, um, for me, I saw many mistakes, uh, repeated, um, and very probably naively I thought I can avoid all the problems, I can make the perfect environment, the perfect engineering team, uh, well, I have, I guess I have much more respect for these big companies because I know how complicated they can be. I think I got a few things right.

You wouldn't be running a business for 13 years if you wouldn't have made, you know, good decisions, isn't it? So, so let's go into it. I mean, it's very interesting you mentioning this, going like, you know, I had this vision before I actually started the business that I can do so much better. And then once you actually went on the journey, you were like, okay, right. So my views are changing now, you know, it's not that easy. So you've been doing this for 13 years. I mean, you're doing something right, right? Um, so talking about business resilience, David, it's like, that would be my very first question. How did you manage to get the business running for 13 years? It's like, do you talk about, you know, some business modules, you know, about resilience? You know, how do you live through the market dips and ups and all of that?

It's interesting you mentioned resilience. It's something that me and the other founders of Carwow haven't thought about at the beginning. We, we developed resilience purely by the fact that when we start, we didn't have any money at all, and, uh, it took us 2 years to get to the point where we could focus on Karwa full-time and pay the bills with it. So that's where we got our first investment. So we started from— I guess failure was the default in a sense. So when later in the business we encountered our first dips through the market and so forth, I think as founders we were like, this is fine, this is normal, we can't— we can cope with that. Uh, but at the time, that's when we noticed that not everyone was built that way. And, uh, you really, you know, when businesses do well, everyone is happy, everyone is positive. Uh, when you start hitting your first hurdles, uh, when you don't hit revenue growth for the first time, for example, that's when you notice that, uh, people that don't have the resilience, the positivity, either just give up, or worse, they become negative influence for the rest of the organization, the culture. To the point we decided then, that point, to add positivity to our company values. After that, uh, it probably was the only time that I felt I didn't want to go to work was during those times, but not because of the challenge, because of the few people that were really dragging my energy down. That's quite interesting. Um, so I think you have to be resilient. You know, in 10 years there's ought to be a recession or something. Uh, though it's impossible to, to grow on and on without, without challenges. Um, so I think it's— this is an important part of the founders.

Uh, do you think strategically about resilience, David? Or— so the beginning was, as you say, you know, you were young in the business, so effectively the resilience just came from the fact that you were a founder and you were just grinding forward, just taking all the challenges along the way and knocking them down. But then eventually, you know, you become a more mature business. Do you sit down and you go like, let's see how our industry looks like and let's see, you know, what the next couple of years brings and be strategic about how we can build resilience? Or is it, is it more on like case-by-case situations where you are in a situation and, and you just then think then?

I think, um, we were lucky, uh, just before COVID we were thinking about business resilience rather than your personal resilience. Because there has been a few up and downs in the new car market. Our core business started purely on new cars. This was our niche. But then you are subject to, you know, ups and downs, the new car market, then you can't do anything about it. So the way we decided to gain control of it is Well, we ended up acquiring a business that was thriving during this period when the new car market wasn't doing well. So the business they used to call the reverse carwow, where allow us to, um, get people that want to sell a car, like private, to sell, to put it to auction to dealers. So we ended up doing that just before COVID When COVID hit, the new car market got probably decimated due to miscalculations. And then it was almost impossible to, to buy a new car. It's for a business that makes money out of buying a new car. That was— fortunately, we managed to get this business that grew tremendously in that time, which balanced the loss of the other one. So that was probably the first time we systematically thought, okay, how do we compensate for when the market, new cars, doesn't do well.

Okay.

Um, that, thanks to our kind of the time CEO, and now he's the CEO of the company, it was a great move, probably saved the company actually. Yeah.

Was it, was it calculated saving, uh, a strategic saving, or was it more of a situation where it just happened? I mean, the acquisition plans were different And then the COVID came and you came out at the end actually in a good position. But that's situational, isn't it? Or do you think you made good decisions along the way?

I think there were— before COVID the new car market, there were a few other kind of critical events that happened. One was the diesel scandal, another one was WLTP, um, where The CEO coming from a new company thought, wait a second, we have lots of traffic, we are not monetizing really well, we are, we are, um, somewhat reliant on this new car market only, we don't have levers. So, um, it was a strategic decision to add other revenue streams that really combined with, they work well with existing audience. And those really helped with step changes, I think, in growth and reliability.

Okay.

So at that time, we not only that type of part of the business improved, but we also now have a revenue stream based on media from manufacturer partners, things like that. And the three things together really allows for a better LTV, I guess, and more resilience.

Okay. I like that. Just adding more streams, which actually aligns to your core proposition, just diversifying effectively your business and making it more resilient.

Yeah.

So I wanna take back to one note you made in the beginning where you said for about 2 years you were going until you actually reach a point where you can go full-time. Yeah, that, that's a, that's a like a founder personal resilience. And I think a lot of founders and entrepreneurs starting their ventures, they actually underestimate the amount of work and energy and for how long that will continue until they actually be able, you know, make a full-time of this. Can you just give us a little bit of a flavor of like emotional setup to go through those 2 years and not be able to go full-time, how you managed, you know, the income balance between your, your work and, and the time for the carwow. And, and yeah, just how did it feel?

Well, I think I, I had the, I had a good plan in terms of career-wise. Um, early in my career, always optimized for places where I would learn a lot rather than necessarily get more money. I think I mentioned ThoughtWorks. ThoughtWorks was, for me, the place I wanted to work at because it was famous for lots of famous engineering books, writers worked there, great people to work with. It was hard work, wasn't highly paid, but was a great environment where I built good relationships. And so I always optimized for that. At one point, because of that experience, I realized, wait a second, now I could become an independent contractor and probably earn double the money. Yeah. So I did my calculation. Instead of saying, okay, let's earn double the money, it's great, very comfortable, I decided let's try to stick to the same salary. And to do that I just need to work 6 months a year. So I've invested, invested, invested that instead of ripping the, the, the results straight away, effectively I've invested— it's like I was investing half of my salary in a sense into my startup ideas. So I started my own thing first just to see. I would take maybe a contract for 3 months, work in the evening for things, then 3 months of focus. And then I met the other founders of Carwow and I joined them. And we followed that formula, me working in the evening, which is tough, obviously, at the start, and taking time off between contracts. It was quite flexible. Sometimes you go through periods in startups where actually the next bit is just waiting a bit, growing the audience, talking to investors rather than needing to build new features necessarily. So we're kind of flexible around that.

Okay. I do— I mean, personally, I can resonate with that very easily. Like, it's very hard to be full-time on work or in a position and then, you know, say to yourself, I'm going to be working in the beginning before the workday or after it or in the weekends. That just zaps energy very, very quickly. It's just unsustainable. So you need to think about how you're gonna make time or how you can buy time. And, you know, for me personally, I usually buy time, meaning that I take, you know, salaries and I will pay someone else to get my things done and get my visions developed.

Absolutely.

So you did very, very, you you know, correctly. You basically find a way to make time and then put that time into your venture. How did you meet other founders? Because, you know, we have popular things in UK where, you know, we have services and networking events where people can go in and try to seek out the founders. What was your journey of founding your friends?

Well, interesting. I did attend a few hackathons and things like that to speak to people. At the time, though, I find— I found that the majority of the ideas I really didn't like. It was early 2011. There were a lot of, ah, let's do a social network for this, let's do a social network for that. I'm, in a sense, in terms of both technology and type of business, a bit conservative to an extent. So I, uh, I ended up resonating a lot more with the idea of James, which is simply, hey, the, the car market is very old, they're really difficult to buy a car, let's sell cars online. It's very concrete idea, it's just that it's hard to do, but, uh, it's not out there completely, completely innovative in a sense. Um, the way I met them actually though happened through Through contacts, through networks. James, the founder of Carwow, he was emailing just random CTOs in London because he realized, you know, building something like Carwow without a technical co-founder, really hard. They spend a lot of money on agency, it took ages. Really didn't go well. So he was asking for advice, plus, do you know anybody? And one of them at the time was the CTO of Wiggle, bike e-commerce website. He was the first person I worked with when I moved to UK, and obviously developed a good relationship. He must show where I was working, and he mentioned my name. So again, building on good networks really helps. And then we just met for coffee. I love the fact it was a simple idea. I love the fact that Jane was going out and calling people, which is exactly what I needed to complement my skills because I'm not good at selling. But it was bringing something. It wasn't just a founder with an idea. Which is always say you can't just bring an idea. Everyone can have an idea. What is your skill set? And he will bring it. It was good at selling and ended up being able to raise money even if he didn't do it before because of that.

That's a good synergies, isn't it? And I think it's a highly overlooked setup when you think about founders. You want to complement each other and build a full bundle to actually be able to kick off the business where I see often the mistakes being done, you know, where tech founder meets another tech founder, so they vibe from each other, it's all about technology, and then they go ahead and build something. And then, well, how are you going to put this on the market? Like, how are you going to sell this? And that lack of skills suddenly, you know, puts that idea to nothing. Okay, so that's a—

yep, sorry, I said the compatibility is crucial in terms of skills. Obviously, personality, they'll end up working, but There's, I would say, building a product, selling a product, at very least at this minimal scale at the start, are essential.

Build it, market, sell it. That's like your 3 main pillars which you want to have it in your, in your founder setup. So you did mention, um, having, you know, went through those phases where you had very, you know, minimal or lack of energy, or the energy is getting zapped because of, you know, some, some toxic people within the business. I would presume that these weren't the founders, but can you give us a flavor of how that situation looked like and how you guys resolved it?

I guess the, the, the time when the energy, you know, was sucked from me was, uh, Söldenes in itself, because this type of individual then don't last well in period of crisis. So they, I think some of them left just by their own accord. And then we managed to solve the problems, the economy came back, whatever. And it was fine again.

Okay. So it's just—

I think other—

Yeah. Yeah, go ahead.

That's a negative, negativity caused kind of lack of energy. Other lack of energy, I think is normal. You know, we go through cycles and Again, for me, I played the whole startup thing not like you see in the movies, so people just working every day, 24 hours. I know this would be a marathon, you know, that occasional sprints, yeah, uh, but I'm trying to maintain a sustainable pace, something that I felt was right for me, which it can be different with an individual. But I needed to be there for years. So I made sure that, first of all, my role was interesting as well. Sometimes startup CEOs find themselves in a job they don't like anymore. Should I tell them, hey, you're a founder, make— figure out how you provide value to the company and make that your job. Hire somebody else to cover other areas you think you're not as strong at. So I think that was helpful.

Was that a realization you sort of reached yourself, or was that an advice you've been given when it comes to that? You know, uh, if you don't like it, find someone who does that and just make sure you find your own strength for the business and, and do that.

I, um, I think as many cities I reached a point where I was fairly technical. I wanted to be hands-on about like building products, but then got to the point where we maybe 10 engineers, and people, the people management side of things, hiring, was becoming a large part of my time. So fortunately, I was self-aware enough to say, I'm not happy with this, let me research. So I think I've done a Google search and found a few articles around when is the time to hire a VP of Engineering or things like that. That say, huh, okay, this doesn't have to be like that. My strength is in the technology side, projects. Let me focus on that. Let me find someone that really thrives on the people management side of things. At the same time, I knew that was important. I wasn't trying to just ignore that part because probably everyone experienced working in a company with a bad manager. And so forth. So I wanted— my mission to create a great work environment meant that I want to really invest in people, in people. But I found a right hand that was better than me at it and made me a better manager. Something that obviously at some point you still need to, uh, get good at, you know, as a leader. The people side of things become more and more important.

Absolutely. And I love how you did that in a self-reflection, you know, way. Because some founders fail to really see what they're not really good at, and they still try to do everything, which is, again, it just leads to burnout, you know, zaps your energy, you know, you start losing willpower to grind forward, which is, you know, always a grind in the beginning. So that, that's a good example of sitting down and sort of reflecting back and going like, you know, I'm in this situation, how can I improve the situation rather than trying to just battle through the situation? Okay. So you mentioned acquisition as well, David. I know this is disruptive to some extent to businesses because, you know, you're acquiring other business. You know, firstly, it's a, you know, it's a big investment you're making. So you have a lot of things to go through, which is time-sucking exercise. And then you get this new business and, you know, you get the people as well, you know, how do you merge that? You know, how does your organization chart change? You know, how do you bring people together? Is it this office or that office? You know, do we go remote? And, you know, there's so many big questions to really answer when you're doing an acquisition. In your perspective, how did that whole process go? And, and what were, would you say, like the major learnings of that process?

The process, I would say, went relatively well. In terms of business, we were able to take the product from technology point of view, we were able to then fully make it part of our codebase within 12 months. But we were also able to ship value, increase the value of that from week one. We went from a business that was doing $1 million revenue a year, that part of business now closed last year around $16 million. So in 2 and a half years, so it's pretty big. So happy from that point of view. I think the challenge was more on the cultural side. A lot didn't kind of, it was tough to integrate with them. Partly because it was an early stage startup with a bit of a laddish culture, where, you know, probably fine when you're 20 people, know each other, but didn't integrate well when you are now integrated in a company of 150, 200. So there were a few challenges there. I mean, at our first parties together, things like that. So we are now much more aware of this cultural integration. People teams in Kawa really keep an eye on that side of things early on. We are aware of the time sink that it is. So make sure you know that after you acquire a company, your people team, your legal team, and what— it could be very busy.

Okay, so outside of busyness, the main challenge you guys had is actually our cultural differences or our cultural clash. Simply because your organization were a lot more matured compared to the startup you acquired. So for them it was, you know, acquisition is final, and suddenly, you know, you walk from this one room which is your startup, which is, you know, totally different colors, into this different room like the next day, right? And it's just like, whoa, that's different. That, that's a lot of difference. And that change management or that change is, you know, it's often quite difficult you know, for people. And I think everybody who goes through mergers and acquisitions is literally on the same boat. How do you, you know, manage that? Did you have any attrition, you know, in that situation? Like, did a lot of people sort of just, you know, dropped off during the acquisition, or was it all just healthy that, you know, not straight away?

Um, some of the leadership there ended up leaving, but at the same time, some of the people from that company now they are really great part of Carwow and they lead the area. So again, depends a lot on the individual. I think we're lucky because a lot of the culture is still there. We now maintain the, the office there. The people that kind of were more compatible with our culture stayed and thrived. Okay, so I think it sort itself out.

That's quite cool. Um, yeah, so talking about cultures, Yep.

Yeah, no, I'd say you shouldn't be, um, uh, scared of saying, you know what, these people don't match culturally, we cannot have them here, you know. Uh, so if you have well-defined principles, you have the framework to be able to make the decisions, because sometimes it's hard, you know, because you see a salesperson and yeah, they're selling, they're bringing revenue, so I said, I can't fire them, you know. But if they— their behavior should be part of their performance. Yeah. Uh, if you have well-defined principle and how to establish it, how to give feedback, and they don't improve, then you need to send them away if necessary. Again, it will upset everybody else and have a negative impact in the organization.

No, I do agree with you, David, there. Um, if there's a cultural mismatch, and you know, it might maybe sound like a cliché, especially when you're going, you know, through this interview process, it's like 'Oh, you weren't a cultural match,' and, you know, you stop interviewing. But it's a very real thing from a, you know, from a leadership and management perspective, because you have a vision of the environment you're trying to create, and the environment is based on people and, you know, people's behavior. So it's very often that, you know, people are just not for your environment. Um, talking about cultures, can you give us a flavor of how does Carvao culture looks right now?

How come our culture looks so nice? Hmm, I have, I have my values booklet here. I have it always on my desk. Um, I'm, I guess again, I mentioned the start, part of the reason to start a company for me, I wanted to create the right environment for me as well. So I'm very happy with the culture. Um, the key main differentiator for us is we are highly collaborative. Uh, and what I don't just say is we like helping each other. And whenever new people come from other companies, they always mention it. Oh my God, this is, this is true, you know. So many people stop what they're doing and, and work. And this is possible because we make sure that the team's objectives and personal objectives align well, because often companies even by mistake create this alignment in the organization. So people are not incentivized to help another department, for example, because, oh, why should I spend time on that? I'm gonna miss my target. We are trying to organize the organization in a way that, hey, if you are helping the department and we help the whole organization, you thrive. So that really helps. So collaborative. And we're trying to be— I was mentioning the values that are not as common. I think humble is one that not every company has. The people there, we want to learn from our mistakes. We want to not be arrogant with others in general. And I think it's a really important value to be able to constantly learn of the ability to improve. Um, so yeah, a bunch of positive, humble people. Uh, some of the decisions we made early on— I mentioned I had to work some time in the evening, early days, uh, or between contracts. So for us, it was extremely important to make sure not to work on things that didn't matter. So extreme prioritization, breaking down things in small steps that can be achieved, and and celebrated are a big part of our culture and still, still is. And I think it comes from the early days of WeWork.

This sounds great, David. It's like, you know, I want to work there. Do you have openings? Yes, it's a good— definitely a good, you know, um, I mean, first you start with a vision, you know, you need to understand what culture you want to create, and then, you know, you just move towards that. I really like the helping each other. I think it's so highly overlooked, and you very rightfully mentioned that when people get busy, you know, they tend to not help each other. And it's just, it's just what happens by default. Like, you have your main priorities, your main responsibilities within the role, and if you are being capped out at this, like, you're just not gonna have time, you know, to go ahead and help that. And streamlining that process, as you know, you guys doing with alignment, is, uh, such a great, you know, strategic positioning. It does help tremendously to just lift up everybody up, and you can hire as well, you know, more maybe junior people and make, you know, you just, you know that your culture will bring them up, which is, you know, great setup. I do want to touch on innovation. So culturally speaking, you know, people tend, you know, put something on a table which, you know, drives either decision velocity or just allows people, you know, to go and fail and just play with different things, just, just, you know, innovating the industry you're competing in. And, you know, you've been doing this for 13 years, so you're clearly doing something right in that space. Can you talk a little bit how you guys, you know, make sure you're innovating?

I don't know if you're very good at innovating, actually. It's something that we're trying to get better at. Um, again, probably because of the way kind of me and the early founders used to work. We weren't the supervisionary type of founders. We say, oh yeah, we're gonna change the industry, and it is clear long-term vision. We were pretty much, okay, this is our car online, what's the next step? Okay, let's try to sell 10 cars. So baby steps, pretty much. Forget that. Yeah, and next step, okay, great, sold 10 cars, let's sell 100 cars. Um, so the vision expanded as we moved further into our, our path, you know. Now that we, we feel like, okay, now we have a possibility really to have to build that vision a bit more clearly, uh, and bigger. Now we do a bit more of that, but it's really difficult to innovate in startups when you have always maybe 6 months, 7 months to provide that next level of growth. Um, so I didn't feel we were innovating. We were constantly improving, but I don't think we're bringing something completely— well, I think it was easier in a sense in our industry because no one was doing anything in it. It was, you know, uh, it's very little innovation effort. So the very little we're providing was enough, uh, until it's not though. I think the constant improvement is great at the start, you know, because a lot of the growth comes from maybe adding more makes, adding more supply and so on. At some point you reach a point where you can get— you got all the supply you can with that product, and that's when you need to start bringing the big step changes. And I think that's a part where we didn't grow as fast because we didn't invest in the bigger bets. Um, but we got a little bit better at that. But I think you need to think very systematically about— yes, you need a lot of short-term bets, but figure out where you feel comfortable. But you need to have the one longer-term bet always going.

Okay, so this is, um, this is coming with time then for, for Karabao. Like initially Effectively, you just had very short-term visions or short-term goals, and then when you became just more financially stable and just big as an organization, you know, you started looking at the, you know, much, much longer visions and, you know, feel how can you drive this through innovation. Okay, that makes perfect sense, and I'm happy you guys were able to sort of, you know, do this. I feel like—

I think you have to. Yeah, you have to. Absolutely have to, because otherwise the growth stagnates at some point.

Exactly. Yep, you have to compete, otherwise you just fall behind. As simple as that. Um, so when you grow quickly, and I presume you guys, you know, grew very quickly because you mentioned you went from $1 million something in like '16 in like 2 years, you know, it was driven by emerging acquisitions.

One part of it, the business.

Yeah, yeah, it's still, you know, huge jump. So with that speed, you know, usually scalability requirements, forget about quality, and you just go like, okay, well, we just went from, you know, a very simple number to a very big number, and now we need to sustain all of this. And, and quality goes through the door quite often in technology. How did you guys manage the scaling challenges with quality?

Interestingly, for one of our principles, I guess, for engineering is trying not to code, it probably was one of the drivers. Because the more stuff you build, the more mess you need to maintain and so on. So, for us, to be scrappy, instead of writing lots of scrappy code, we were questioning writing code at all most of the time until we really learned about something. Just to give you an example. One of the core bits of Carwow is the fact you configure a car, And then you receive offers for that car automatically from dealers. These offers are calculated based on the discounts the dealers put on and the offers and so on. But for a long time, because we didn't have this scale, those offers were manually entered by one of our salespeople that made a spreadsheet and he was doing that. For a while. And it was fine. It was much better than trying to write the code. We were able to get to that quickly. Allow us to learn, ah, wait a second. Yes, for Mercedes, this count is calculated way, but Voxel is completely different way. And then it's a different way. So we were able to learn fast, completely avoid coding. So we're able to do other stuff. And when the time came, the Hey, there's— you're spending 4 people doing this manually with too many, too many new customers. We can't sustain that. At that point, we automated it with more certainty. So we ended up with better code, fewer rewrites, and just maintain the quality. So for us, it's always challenging the need for writing code, first of all. And when we had to write code, we were uncertain, I think there are a few techniques that don't really— they allow you to write good code still, but quickly. I had this idea of making sure that if you have already messy code, make sure it's all in one place. So architecturally, we try not to spread mess across multiple classes. If you know something is messy, and you're sure, you're better off having one complicated thing that at one point you can delete and rewrite. Rather than a complex architecture or something like that. Keep things simple. I think sometimes you also need to question a bit of discipline of engineers, because we hide behind the fact, ah, we are going fast, doesn't matter. But there are a few simple things that don't cost you any time, really, in developing. It's just a matter of discipline. That make that maintainability, scalability of your code much easier. Like, sorry if I get a bit technical, but for example, breaking down, make sure your code is readable, you know, give proper names to things. It doesn't take that long when you're coding. You're thinking, as you're thinking, you can rewrite. It's more about around discipline. And we were able to do that. And we still have the same codebase, in a sense, that I wrote, that obviously evolved. But we never had to go and do, oh my god, we need to rewrite this, impossible to use. We had the discipline to improve a little bit every time, make sure it's readable, simple. Yes, occasional mess happened, we will rework later, but nothing major.

Okay.

And still, the focus is you go faster, not by writing faster code, is by removing things that are not necessary. We waste our life coding things that don't matter, you know. For example, how many startups build their own infrastructure and stuff they don't need? Just use off-the-shelf service that give you deployment one click. Uh, yeah, stuff like that. Focus on your differentiator rather than, yeah, building stuff that you can buy or download.

That's a, that's such a strong shout, David. And I remember myself, I went in the company and, um, and there was situation where they were constantly spending time and maintaining a very legacy code which was responsible for just creating thumbnails for uploaded images, you know. And I'm like, why we even have this code liability? You know, there's already services which does that professionally with all the distribution capabilities, just Just take the API.

Yeah.

And it's just like, it's such a, you know, simple buy versus build type solution because, you know, you writing thumbnail management code is like, that's not going to help you sell your product, right? That's not your offering at all unless you actually are, you know, the asset software. Yeah. Upload and distribution type of software, right? So that's a, that's a very good, you know, strategic decision is just asking that question. Should we even be writing this in the first place? And then discipline-wise, were you— is it just like a cultural element where you, you know, um, take people through that onboarding process and you explain to them that this is how we do it? Or do you have some type of like a maybe static code analysis enforcement towards, you know, what is an acceptable level of quality of code which goes into production?

Um, early days we had, uh, I think it's more cultural. Reviews. I was lucky that my early team, the first few engineers, were very experienced. I never bought into the idea of having lots of junior developers early on. So I was surrounding myself with experience, but people on board were investing in the company. And that made my life easier, obviously, because everyone was reviewing code, giving feedback, And then the culture spreads, they understand the importance. And we celebrate when we delete code. By the way, we found a new off-the-shelf software now, it was a real thing, that takes care of moving data from our data warehouse to third parties. And we were writing loads of code to do this stuff. Boring, error-prone. We found the software, now we're deleting code and celebrating. Because every developer enjoys that. Because we hire people that are not there just to write code. They have joy when they can have an actual economic impact to the company. So I think that's important. As a startup, you need to find people that enjoy technology as a tool to achieve change and impact with people or the business rather than code for code's sake.

That's a good OKR to have, you know, how many code lines did you delete without negatively impacting the codebase. It's just like, let's just do that.

I did it last year. We, we tracked it. We managed to— I don't think we're going to be able to ship a game, still add loads of functionality, but we ended up overall with a few lines of code last year.

So did you employ AI like Copilot or any sort of coding help which you can get with AI to potentially, you know, look at some legacy corners of your system and go like, can we just improve that somehow?

We started a test of Copilot with a few developers, which they enjoyed it, but I didn't hear a, oh my God, this is life-changing experience. But I suspect it's because of the technology we use. We tend to have a lot, again, because we bring a lot of libraries in, I'm trying to write code that has been written already. In a sense, we don't have some of the challenges that other companies have where the automation with AI helps more. So I'm not sure we are reaping all the benefits of that. We do use for refactoring sometimes. Sometimes it's really good to say, hey, I have this module, it's a bit complicated, how can we make it more readable? Ask the question directly to ChatGPT and it will Pretty good.

Yeah, this— there's some value in it, um, I get it. But at the same time, you cannot really come out and understand you so deeply in the sense like, I have this open source library which maybe you don't even know about, and this one and this one, and I want to, you know, bake a business value solution. It's, it's probably gonna not deliver on that compared to something like, you know, write me a unit test, which, you know, it's a different, different—

that was the biggest benefits. I makes easier think about edge cases kind of stuff they used to think anyway.

Yep.

So it was good for that.

Okay, right. So, so we went a little bit deeper into, you know, your teams. Um, how do you make sure your talent attrition is low?

Interesting. And that's probably one thing I'm proud of, most proud of, uh, is the retention of our engineering team. Um, I think our median now is almost 3 years. And we have lots of people, I mentioned these people from the start, so people have been with us 10 years, 9 years, 7 years. So I think first of all is good people management. So we had very early on dedicated engineer managers that their objective wasn't technology, was focus on people. So make sure that they were heard, feedback addressed, that it would help them learn and grow, have a career path. I think, you know, we constantly score really, really high on our engagement surveys related to that. So that has been key, because then a lot of initiatives related to that, I can get the engineering managers to to run them. The other part is, I think, good quality, establish a good level of craft in your code. You know, no one likes to work in a terrible codebase. I think I was being passionate about that. The engineers in my team see that. And so they understand they are in an environment where we care about craft as well. That's been quite motivating. And the third bit is the fact that they can see, they can have an impact. So we, we are very close to the rest of the business. They enjoy, enjoy the part they can reach, or they change, is they can have an impact from day one. Even a junior developer could work on something that then 10 million people see. I think that's pretty important for motivation.

I agree.

Yeah. So I think these three for us has been crucial part. And I keep my libraries up to date. I think always advise no one ever thinks to keep the frameworks and language up to date. And then all of a sudden, you're like 2, 3 versions behind and people get frustrated and leave.

100%. It's so, so annoying. And you cannot utilize the updates of the, you know, of the package or framework or library using. It's like you fall behind, you know, the library is moving forward, right? They're doing better, they're fixing bugs and they're adding new things. And then you're just behind and you're like, oh, I can't update this because, you know, we made some mistakes and all of that. And I remember one role which is a real situation. It's like, you know, it's a— it was like 9 years business, a startup, as well, which became, you know, a business. And they never went to address their, you know, technical sort of issues. And they ended up with this code base where no one wanted to work with. So they would hire someone and people would just leave 3 months later because they would be like, you guys like 5 years behind the market. Like, I don't want to work with code like that. Like, I don't want to work with tools like that. So it's a very, very important, you know, that, that piece about the craft and caring about what you guys produce at the code level. That's such a strong cultural, you know, vision or element, which works quite well.

What about discipline as well? I think it's that maintaining, it doesn't take that long to do that if you do it regularly. But then it becomes a massive undertaking if you go 3 versions behind. Yeah, we start from Ruby. So sorry, Rails 2, 2. Yeah, 3, 3. And we are on the latest at the moment, you know, always updated whenever there were a major release version. And Ruby the same, we went from 1.8 to 3.2 now. Yeah. So kept that up to date and pays off. People stay.

Definitely. It's a very good strategic setup. You know, whatever processes you guys have, you know, as long as you automate this to You know, an extent, uh, it's— yeah, it's—

it gives one that's such a simple thing, you know, when you think about it, a simple thing, but it can have tremendous negative impact if you don't care about it.

Exactly, exactly. Can grow to big problems. So, um, what's— what's your take on one factor? So just in the spirit of the show, we have this question. It's like, what is one thing in your view most important to any technical venture growth?

One factor, I think, probably need to be making sure, are you working on something that has an impact? Why you do something is crucial. You always need to know why. Yeah, you might not have certainty of it, but they need to be clear why. You know, I saw so many startup founders, they're like, ah, we're redesigning the website. Why are you redesigning website? Just, this is gonna magically fix your business? Uh, things like that. Uh, there's this, you hide behind busyness, uh, busyness, I guess.

Business.

Yeah. Uh, it's really bad, you know, the people work really hard and late for no reason, because you're working on things that don't matter. You know, you're better off working 8 hours, but make sure, yeah, you know why you're doing something. You know, it might not work, fine. At least need to be able to, to know, explain the rest of your company. Also, then leadership comes from that, that you want to bring people with you on the journey, you know, and need to clarify, okay, we're doing work You are working hard, they're asking you to work late.

Why?

Understand there's value in this and this will make a change. I love that. Yeah, it's crucial, I think.

Yeah, just go through 5 Whys exercise. It's a very simple framework, you know, just ask the why 5 times, see where you end up with an answer. If you get stuck in the middle of these 5 whys, you probably don't have this nailed. Like you don't really know why you're doing this. And I call this bad busy. So when I talk with people, I go like, you know, always founders goes like, oh, I'm very busy. Is it a good busy or is it a bad busy, right? So you can be good busy, which means, you know, you're doing things which really matter, you know, you're applying some type of framework, you know, 5 Whys, you know, Pareto, 80/20 principle, but you're really nailing what exactly you need to be doing to advancing your business forward. And, you know, bad busy, you just, as you said, you just hide behind business, like You're just doing everything and you're doing things which you probably should be delegating to someone and concentrating on what you can really, you know, put the value in the business and advance the business. Okay, I love that. So, you know, make sure you know why you're doing things. That's a good one, in fact, David. All right, so, um, while with this— in this topic now about the growth, how you keep speed going? Like when you think about velocity of work and, you know, we can take it maybe a little bit deeper to team velocities, engineering velocity, or a little bit higher, you know, look at the whole business, you know, where you combine the product and the sales and everything. But how do you get that speed to a certain point of how you ship value and maintain that speed?

Interesting. Before speed, again, going back to the why, making sure you're going the right direction is crucial. Because often, yeah, see, we're going really fast, but again, we build something that doesn't work, doesn't matter. So as long as you're confident you're working the right thing, then speed matters. And I guess my personal trick has always been around scope control of any project. Or I guess to mention the 80/20 Pareto principle. You can go as fast as you want as a developer, but most of my speed comes from removing things. You know what, this maybe let's do later. And so you get the sense of getting to value faster and shipping something. Um, so I had an obsession for that, probably also because of short attention span, but always trying to get to the core value shipped and deployed and deferring what can be deferred. And I think the advantage of that is there's also psychological— as soon as you do that, you can really concentrate on the one thing. You have less to think about, you're automatically more focused. And then you get the nice reward for, oh, ship something, oh, you're getting customers to use it. People say, maybe someone in the company say thank you to you. It's quite pleasant experience, it relaxes you, and then it pushes you to work harder next time. So I found that the motivation pattern for me works really well. And I'm trying to get other engineers to work on it. I think that's where I find a good product manager really can help. Because they— it's not just the code sometimes, not just the knowledge a bit, it's the whole go-to-market and why the business also that we can waste a lot of time on stuff that we could defer. Maybe we can launch this product just to a segment. Yeah, let's start with a small segment. And launch it. And then we do the next bit. So by not needing to think about the rest, your brain has more space to move faster. So scope, I think, is the key to speed. To speed. For any role, I think. Then again, for engineers, there is a lot of push to do more with your engineers at the moment. Given that there's less investment going around, you know, probably the time of teams of thousands of engineers are gone for a while. So I think that's still important. And so spend a lot of time around organization structure, you know, is often again, the time is not the coding bit is slow, is the decision making or reworking an idea, something wasn't clear. So how do we make sure we put the right people together that they can do the most decisions quickly without bureaucracy, without needing to wait for others? Yeah, whenever we look at the team that slows down, most often is the lack of clarity of what to build. That's what causes the most slowness. And then another thing is really important to keep an eye on is the whole reliability of the system, bugs and so on. Anytime you get a bug, a question, because your system is complicated, so the person within the business has a— doesn't know how it works, slows down. So I have a metric now for— you were trying to track is how often we get interrupted by questions or bugs. And we have process around to make sure that not everybody need to be aware of it. So every squad in, in, um, my company have one— the distractible person we have on a rota. We know one person will get the burden of distraction, it's fine, but then the others can really stay focused and work. Um, so yeah, attention to that is, is important. Where to put meetings, deleting meetings that are not necessary, create a nice long space of time where people can work. And then going back to the people's time, a lot of external factors can really mess up with the developer productivity. You know, every time someone had to move something at home, we noticed that really, really slowed them down. So as a company, we invest in therapy support. We have kind of services that you can— not therapy, but they call it counseling, I guess. Good holidays, make sure to avoid burning out. So yeah, a lot of factors are not technology in a sense. Then technology is great. One thing we're doing recently is trying to simplify technology, use one programming language, for example, trying to avoid complicated front end, separate front end, if not necessary. Those things really help as well.

Yeah, these are great. And yes, it is, it is much higher than, than going deeper to processes and tech when it comes to enabling speed. And all they mentioned is, is just, just on point. Um, I wanna take us back to the very first one, which is the scope. And I, I do like that flip notion of like what to think, not about what you should be doing, but to actually think much stronger of what you should not be doing. As a result, you know, keeping it lean. How does the customer feedback play into that decision? It's like, do you guys talk with the market? Do you, you know, do you have your main clients from which you source the ideas on, you know, what you should be concentrating, or is it more from like internal views?

I think depends on what area of the product we're changing. Uh, there are parts of CarWow that are very much customer retail-focused. Others, they are for our supply side of the market, or dealership brokers. So the feedback loop can be different. Um, we obviously, we have a continuous research. So research team now, 2 people, not massive, but they're really good and they really can summarize the key pain points. And they help us building more of a vision rather than give you the solution, I think. So, hey, there is a problem there, this is a top problem, and we use that to, to focus our attention. The solution comes typically from the teams themselves, sometimes even execs. Execs in particular area might have a good idea more than a feature, a strategy, I would say, you know, a strategy approach. This is how we're going to solve this. Um, so the type of work can come from feedback for customer execs themselves for more strategic decisions, and the teams themselves, obviously. Um, the problems either obvious will come from customer support, actually a great source of You know, uh, we— part of it, the work of the researcher, is analyze the problems mentioned by customer support. Um, and our dealers are, um, also our account manager salespeople, they, they run interviews regularly with their clients. I'm gonna say, hey, tell me about how you're finding it, and they write summaries on this and share, and they're great source of inspiration. But you use this information, you don't ask people how to solve it for them. Then that, that you develop your intuition as a product leader, for example, and come up with ideas to test. And then we test.

Yep, that's a, it's a very organic approach.

Um, yeah.

How, how do you capture data? So, um, in general, do you Would you say that you are data-driven decision-making, or is it more like organic decision-making? So meaning that, you know, data-driven would be you talked with customer success, but you know, you put it in, maybe you crunch the numbers, look at sentiments, you know, around some topics. Research-wise, you know, maybe look at the global market, maybe you buy into like global reports, which you then try to digest and you are, you know, data-driven, or is more of like organic way of just talking with customers.

I'll mention something. For me, data has always been important. Again, one of my principles was I didn't want to work in a company where the person with the loudest voice would make decisions. But we phrase it slightly differently because sometimes the lack of data causes paralysis for some people. So I'm going to read you something from the booklet of our values. One of our values is effective. And part of it is an area about data. It says that we use data to inform decisions, but we feel able to make them without— with imperfect data. I think I don't like data-driven because it almost makes you unable to make decisions without data. And data comes in different forms. I think, yes, quantifiable data, great when you have it, But, you know, people having conversation with their clients and developing empathy for their problems, it's valuable data and you need to be able to listen to that. And if you have numbers detailing exactly the problem, great, use that. If you don't, let's speak to an expert, you know, a salesperson, have a conversation. Otherwise, make an informed decision. You know, you should be working in automotive for a while, we can have a good attempt at it. As long as you know why you're doing that thing, you have a clear problem in mind, then sometimes you don't need that much data to make a decision.

Okay, so there's an unofficial decision velocity which you guys care about. It says just don't dwell too long, just make a call, commit, and just make sure you know why you're doing this, but just make a call, commit, and get that.

You can still learn from it. We can still learn afterwards as long as you can measure whether the decision is good or not. I think that's crucial for us. Are you gonna know if this was good or not? Because then it's problematic if you can't.

So do you tend to define success metrics before you go after, you know, big initiatives?

Yes, absolutely. Okay. Uh, without— even if it's a statement, sometimes it's difficult, you know. It's again that feeling. It's rare we do this stuff, but occasionally we could be working on something that harder to measure apart from interviewing lots of dealerships and how you feel about that, you know. And because a lot of this stuff add up and improve, for example, your retention or your supply side, but it's not one thing. So you need to really develop the empathy and conversation and have confidence around that. Those are the toughest ones. User-facing one for us are the easiest because you have 10 million users, we can really be test we know for sure if things are good or not. We might not know why, then we still need to talk to them, uh, but at least we know the impact of any product change on that side.

Okay. Um, I want to touch on regulations because I feel like you guys are so big and you are in this— in, in the industry which I feel should have some type regulations. Like, do they have any impact on your business? Maybe this is just me not knowing, you know, the industry well enough, but do you have regulations which you need to follow which affects your product development?

Um, so we, uh, are FCA appointed, so we need to be very careful of things around, especially things around pricing, financing, and so on. So we have lightweight process on that. One thing is slows down too much. Um, the other one is obviously something affects most, most businesses now is GDPR regulations. Especially when it came, uh, I think we went over, uh, overly following, trying to follow all the rules exactly, and, and it cost us business-wise. And then we have reverted all the stuff because we were full-on perfectly aligned to the regulation and everybody else in competitors wasn't as far on that. Wait a second. So I think there is a risk that a legal team in a company say, oh, this is the law, we need to follow the law. But unless we are talking about criminal stuff, you need to be careful because some stuff a recommendation. Like, there is a risk, yeah. How comfortable we are with the risk. And we're trying to make sure we challenge back and look for a better solution rather than quietly say, oh, legal say that, we need to do it. No, let's challenge it. Let's figure out what the competition is doing. Let's get other advice. I think, yeah, it can be extremely impactful negatively, I guess, a legal team that is just forceful in the organization. And if you don't have a culture of challenging, understanding what we're getting, why we're doing stuff, um, we managed to avoid the biggest, biggest, biggest problem so far because we're not taking payments, which is something I'm trying to defer as much as possible.

So I, I love the I love the challenge piece because at the end of the day, the legal team is, is, is that, that's their job, right? They want to be perfectly aligned to all the legal frameworks which surround the business. But as you rightfully mentioned, this, you know, there's a, there's a, there's a leeway or, or a range in which you can operate and still be legally, you know, compliant with whatever regulations you have. And it comes down to just a risk assessment, you know. Do we have a risk here? Are we exposed? Can we manage it and just wait and, you know, make a trade-off between— are we actually need to do things, or can we just sort of, you know, have a conversation about this? And would you say with the Carwow, like, was this like a gradual process where you got exposed to it eventually, and then you needed to sort of deal with this? Or were you starting to think about, you know, regulations and things before you actually embark in a project?

Now, to start with, we weren't worried about regulations at all. Um, again, the risk of the input of fines and so on, um, so minimal comparing to just failing as a startup. As you become more established, then it becomes important. Your future investors Do look at this stuff. Do look at these risks. I want to make sure you're doing things properly. Uh, I guess security is a similar thing, you know, most of that doesn't matter, but then, okay, we got 5 million customers regularly. Let's make sure we are having regular pen tests, make sure we are doing the right things.

Okay, can you approach one thing—

I'm sorry, one more thing about regulation that we need to be careful though. There's, I think, both for security and regulation. There is just making sure you're not getting fined, but the other one is actually doing the right thing for your customers. Uh, so we always— I challenge decision where I, for example, see, look, this is— I can see this is, as a customer, someone buying a car, I find that seeing the price like that is very clear. Why do we need to follow that exact thing the FCA is saying about this. Let's challenge it because we are not misleading. It's quite clear. You know, it's a click away. We don't need to take it on the page straight away. It's obvious. So stuff like that, when I act as a customer myself, I think I wouldn't be upset by this. This is fine. That's why I challenge.

Put yourself in the customer's shoes. See how that goes. Okay. I love that. Last question, David. Um, if you would give, um, an advice, or if you would share what you think is a good growth strategy, uh, implemented and you've seen that happening— maybe it is Karwa, maybe it is, you know, some other people you know— uh, effectively an effective and successful growth strategy for a tech company.

Uh, I guess depends a lot on type of company. You can talk about like Karwa Marketplace, or—

yeah, yeah, you can take Karwa as an example if you guys you know, did something at some point which effectively just propelled you up? You know, like if you think about growth curve, you just went from being very slowly organically growing to just exponentially shooting to the moon. Or, you know, you have maybe other stories where, you know, some decisions were made like that, just a use case effectively.

I think for us is finding— was finding ways to segment the market and prove growth on a particular vertical, whatever it is. You know, I remember for things like Deliveroo, it was a pick a city at a time, yeah, and make sure you can demonstrate that the business works really well in a small environment. For us, for example, was, hey, we're just gonna sell Volkswagen, start with, because we got 3 dealers. And some people can find it really weird, so how can you build a website where you can select only one make. So you can just buy PPC traffic for Volkswagen terms and just put the landing page and just sell that, get your 3 dealerships. You don't need everything. Uh, some people I find really weird. How do you feel comfortable with that? It's fine. Um, so extreme focus on how to develop the supply and demonstrate. That's how we got investment, you know. We got 3 good dealers. We knew how much it cost the traffic to get in, positive returns. And then we could go to an investor with, hey, this can work. We need money to expand, to get more dealers, other brands, other locations. So they can do the math quite easily, you know. They can say, okay, they did for that, yeah, sure, they could be able to do for the other 40 makes and 20 cities or whatever. Um, so yeah, find a way not to need to grow this massive supply or whatever to demonstrate there is value in your business.

Okay, I really love that. So, you know, here's a strategy, you know, to finish the show with, is just extreme focus, right? You don't need to go big. Just find one thing you think you're solving a problem, make the easiest test you can when there's a value forecast, you know, raise the money or go organic, but you don't need to go big to actually make it a successful tech venture. Yeah, exactly. Thank you, David, for attending our show. I hope that was lovely. Everything you shared, it's, it's tremendous value to the listeners. So thank you for coming.

Thank you, Mike.