Matt Widdoes
Welcome to Growth at Scale. I'm your host, Matt Widdoes. This is a podcast for leaders who want to bring sustainable, predictable, scalable growth to their businesses. Every episode I sit down with world -class growth experts across product, marketing, finance, operations, you name it. The hope is that these conversations will give you real, actionable advice for building and sustaining company growth. Thanks for tuning into the Growth at Scale podcast. Today, we're joined by Todd Larson, founder and CTO at Tech Leaders. Todd was also the first technical employee at Digit, an early fintech neobank that was recently acquired by Arbitrune. Welcome to the podcast, Todd.

Todd Larsen
Thanks for having me, Matt. I'm excited to be here.

Matt Widdoes
Yeah, same here. So for the people who don't know you, tell us who are you, where have you been, and what do you do?

Todd Larsen
So as you said earlier, coming off my time at Digit, I was there for about eight years helped grow the company from me and the founders to over 100 employees by the time I left. And after that, I was ready for just for something new. After eight years working on the same thing, I wanted some variety. And so I took a short sabbatical and then started consulting with other startups around the world just to kind of cleanse my palette and see where I could add the most value depending on what stage of company and what industry. And so I've been doing fractional CTO work for the last three or so years. And in that, I saw some patterns across companies I was working with and helping them kind of get off the ground and going from zero to one phase.

Matt Widdoes
Got it. And curious, speaking of that, zero to one, what is that? You know, there are major differences from starting from scratch or jumping into an organization with thousands of employees and a bunch of infrastructure and existing technical work. What are some of those differences? What's that like starting from scratch?

Todd Larsen
Well, I think the biggest thing to remember when starting from scratch is to really boil down the essence of what is going to be the secret sauce or the intellectual property, the core value that the company is going to build. Because I think it can be really easy to jump into building and say, well, we could build this. We're going to need to build that and actually get ahead of it a little bit and build things that aren't yet ready to be built because the problem hasn't shown itself yet. So I think that's one of the biggest things that people need to keep in mind is what is the essence of the problem that we're solving and not what could we or should we build in the future?

Matt Widdoes
Yeah, I was talking to somebody the other day about infrastructure for sales, for outbound sales and asking them about tools that people might want to use or if he had any recommendations etc. His knee jerk reaction, he didn't say it this politely but was like, forget about tools. He's like, tools are, you should be using tools to solve a... like very clear existing problem, not something that just cropped up one time. So as an example, using a tool that will record and transcribe a sales call. It's like, are you wishing you could go back and listen to calls? Are you not able to now? Is Google recording not good enough to allow you to playback two speeds? Do you actually need transcription? What are you going to use it for? And it's like, oh, I guess, I don't know. It just seems like a cool tool to have. And I think there's plenty of that in the tech space on particularly within the product or things to support infrastructure and scale.

Todd Larsen
Absolutely.

Matt Widdoes
On that build versus buy, any examples from your past on areas where that came up?

Todd Larsen
Yeah. So I think when we were getting digit off the ground, we actually had to build a lot of things that now I would actually suggest buying. And that's usually what I do with clients I'm working with. And one example would be this was long before launch darkly ever existed. We needed to be able to roll out features and use feature flags to be able to incrementally roll out new functionality to users, be able to test the impact of that. And so at the time, you know, launch darkly, nothing like that existed. Lots of companies were building these things in -house or they weren't doing it at all. So we had to build an A B testing framework that allowed us to add the feature flags in a methodical way and then manage those in an ongoing basis. So today, fortunately, something like launch darkly exists. And that's exactly what I recommend people use for a situation like this.

Matt Widdoes
Yeah, we saw this too recently with a client where they were considering segmentation tool that is fairly expensive and they're super early. And it's like the one or two things that we actually need this tool to do. We think we could build in a few days. And yes, it doesn't give us the actual tool, but it gives us the main feature that we're trying to get out of the tool. And so, you know, there's no like hard fast rule for it. And the temptation is to, I think especially early when money is tighter, it's very tempting to try and build things. And I don't know if you have an opinion on, you know, this kind of build then buy mentality of like, you know, piecemealing something together first. And then when that breaks, then we go by or, you know, the inverse of that too is you can buy so early and become so dependent on. a tool that as you're scaling, the cost of that tool drastically increases because you're paying based on events or you're paying based on something that looks way different at scale. Any additional thoughts there?

Todd Larsen
Yeah. So a good example of this is at digit, we used bank data aggregators. And so at the time it was Yodely, then came along Plaid. And this is something that essentially what it did is collect all the banking information so we could actually automate the financial health for people. And on the surface, it seems like that's related to the core problem, getting bank data. And frequently over the years, I'd say every couple of years, sometimes more frequently than that, depending on what was going on, we had the temptation to want to build our own version of that. And we were really disciplined to not do that because we thought about if there are these larger companies than us focused on just that one problem, we're probably underestimating the complexity of solving that problem. And so while those solutions weren't necessarily perfect, We're able to push them as far as we could and not get distracted by trying to build what they're doing. And that would have taken us away from our unique value proposition of automating that financial health. And so it was a recurring temptation for us that we had to be disciplined on.

Matt Widdoes
Well, and you see that a lot as you're problem solving within companies where you stumble upon things that maybe aren't solved by the current market and that actually ends up being the potential for a totally new business to solve that one thing that you're just trying to get out of your way so you can do what you're on. And then the other piece of that, which you mentioned is a good example of this is in -house attribution. You're going up against teams of 200, 300 engineers. And if you're trying to solve a similar problem with three people internally, it's probably not going to work to your point. These are all businesses in and of themselves. They all have incentives to be lean. They all have incentives to get things out quickly. And if they're still taking 300 people to do it, it's probably a sign that it's more complex. Now, granted, your needs to that segmentation tool discussion earlier might be smaller and you only need one thing. But I think that's a big question probably for founders or leadership to ask is, what do you actually need out of this tool? You're probably not going to be using all of it. And if you could only take 70% of what this does, what would that 70% be? And you see this as companies are growing and then it starts to shift where they have all of this. They're flush with cash. It's very easy to stand up these outside service providers and it makes way more sense Well, I guess in some cases, it can make more sense to build because you're like, well, we have all the money and we're here to stay. So you look at companies like Amazon or Netflix that are likely building a lot of tools internally because they want to maintain the data. They don't want all that being shared out with a third party. How do you think about that shift over time as companies grow? And there's no exact answer here, but there's some middle mullet layer where it's awkward because you have the money to do it. But then the question is, should we do it? Any framework for making those types of decisions or any thoughts there?

Todd Larsen
Yeah, it's a great, great point. I think it's all the more tempting when you have the resources. But I think if you lean back on pain driven development as the rule of thumb is like what's the pain that we're actually feeling right now in the organization? What are maybe a couple of steps ahead pain that we are anticipating are going to happen once we solve this immediate problem? If we focus on kind of the current pains, that keeps us away from over -engineering something too soon and getting too far ahead. And so I think that same philosophy works in the earliest stages, also works in kind of the awkward middle phases. And then at a certain point, you just need to be able to measure the impact or the projected expected impact of building these things. And so if you can build enough conviction at a certain scale that it makes sense, the cost makes sense, that is the pain. You know, sometimes it's like scaling costs, that's the pain now. And there wasn't a pain when we started, but it is now. And so we need to do something to reduce costs and maybe that's building something in -house.

Matt Widdoes
So, you know, as you look at some of these later stage companies, there's often scar tissue inside of it in various areas of growth, whether that's in infrastructure or process or personnel. And I'm curious, you know, are there things that. you see in later stage companies that you wish they would have done differently when they were small or just starting out.

Todd Larsen
I would say stronger abstraction of naming is a big one they say naming is one of the three hardest things in tech and I think this can really show problems later down the road around the data model and data analytics where things are named all kinds of stuff and not having that standardized naming convention can make it really hard to map different pieces of information over time especially as like the context around it changes. So I think having a good abstraction allows the underlying stuff to change but the abstracted name makes sense even as the business evolved over time.

Matt Widdoes
That's a huge one for us in in acquisition and in data generally because you have something that's like Christmas camp or some Christmas campaign and then you have Xmas CMP that's also a Christmas campaign and then you have. You know these are like wildly changing maybe even within the same year in the same month and not having that consistency not only on the campaign side but having that consistency in the naming conventions with the creative so that we can better understand what creative is working at a metal layer and then not to mention the stuff that you that maybe you're talking about in product which is on the data layer within the tech and engineering but you might actually just be for product reporting. And then of course within the code itself having a framework where it's like we have clarity there which is challenging because I never heard that naming is one of the hardest things but it makes total sense it's one of these things that I think people know but it's like somebody has to be waving a flag and slowing everybody down saying hey hold on like let's think about how this is all gonna map in the future and I think it's very easy for people to say like especially early stage companies it's like there may not be any future. Stop worrying about that and it's usually the companies that are growing the fastest that have the most kind of debt in this area because things are going well and they're like oh my gosh revenues coming in so get this and get more widgets and we're doing this and we're trying to think about procurement or any number of other things and hiring and staffing and then meanwhile somebody's like waving a flag in the corner saying, hey, we need to really think about our naming conventions. And it's the easiest thing to forego. And then it all catches up with you at some point in the future. And it's almost like in some ways, an analogy I might put to it, it's like when you're cooking some big meal, you can clean up as you go, or you can just clean up at the end. And there are people that wait until the end, and it's a huge mess, and there's flour all over the place, and there's whatever. And then there's people that clean up as they go, and it's miraculously clean at the end. And they even though they know they have this big headache coming, they still just leave it, like in the moment, I got to get this stirred, I got to get this over here and this moving here. So that's a good one on the naming side. What other things do you think of in that as far as what companies might be able to pay more attention to early to save themselves future headaches?

Todd Larsen
Yeah, I would say I would lump what I just described kind of under like conceptual debt. I think a lot of people are very familiar with technical debt, but this is like the conceptual debt. What do things mean? in the code base, in the company culture, the importance of that is really valuable. And I would say another big problem that later stage companies get into is that they've lost a lot of their early stage context. They lose some of their early employees that understood some of those decisions, the importance of why they were made a certain way and they don't always leave the best documentation. And so when those people leave, you lose a lot of that really valuable early context. And so I would say what companies can do to make that not as much of a problem is provide that support for those early people to grow as the company is growing. And so I was fortunate enough to have that support when I was at Digit. I had to get a lot on my own on the side too, but Digit was great about supporting the people that were early to be able to grow at the same pace that the needs of the company were growing. So I think that's an important thing as far as preventing or minimizing conceptual debt.

Matt Widdoes
Well, and this is, you know, that premise that you just brought up as far as the personnel goes and investing in the people and making sure that you've got people that are growing with the org as the org is growing so that you because, you know, sometimes, I mean, it's tale is old this time, the team typically that got you to one place isn't going to be the team that takes you to the next place. But a lot of that, if I'm not mistaken, is what led you to start Tech Leaders. Could you tell us a little bit about what Tech Leaders does and kind of what your vision is there?

Todd Larsen
Yeah, so it came from so many people coming to me to be either a fractional CTO or a co -founder. And, you know, I wanted to be able to help those people and not say no, but at the same time, it's very hard to want to do first technical hire again, because of the things you go through. It's almost like a once in a lifetime gauntlet. You go through that, and now you're going to do something else. You're going to maybe found your own company or, you know, some other role kind of at the next level. And so in addition to that, I had more people coming to me and saying, how did you get to this point in your career? How'd you break out of the corporate world? Or how did you select a company that you wanted to join as the first employee? How'd you build that conviction? And so I wanted to be able to help both sides of these markets, where it was a shortage of leaders, a shorter, whether it's in a corporation or looking for a technical founder. And then I also wanted to help more people just find their role, whether it was independent as an entrepreneur or in a corporate environment as an organizational leader. And so it really just came from me wanting to help more people, more impact with my individual work. And then also it's kind of my personal story where I felt like I had to really chase down a lot of this support for myself. And it took a lot of time and learned a lot of things the hard way. And so I just wanted to make that easier for people.

Matt Widdoes
And how does tech leaders work with kind of early to mid career tech experts?

Todd Larsen
So the first thing is to understand like where a person wants to go. Because I think a lot of people just let their careers be driven by their companies, wherever they're at that time. And it's almost like burnout driven career growth. They like go here, they get burned out, they move to the next role. And so it all starts with us getting really clear and objective about what you want in your career. There's an advantage to having an outside support outside of the company you're at, because we can talk about what this person wants specifically, not necessarily just what the company needs. And so we help people orient themselves if they want to be on an executive track or an entrepreneurial track. And then we figure out what are the skill gaps and the knowledge gaps that need to be filled to get there faster. And so. That's the curriculum piece. And then we also have a coaching piece. And that's where we get together with coaches as well as with peers. And that's where some of the most powerful learning comes because it really flattens the learning curve. You get to hear questions from other people that you didn't even think to ask yet. And then you hear the answers to it. And that's something you can just put in your back pocket and you have for when you need it later on in your career. And then the third piece would just be the community and the network from connecting with other people that are on that same career path, whether they're a technical founder in another part of the world or in the US or their CTO at a mid -stage company or early stage company, whatever it is, you get to be around other people that are on that same career path. And the knowledge that can be shared between those different networks is additional value. It's kind of like what people want from conferences, but typically don't get. When you attend those conferences, it tends to be very surface level. So we go deeper on that.

Matt Widdoes
And this is all at technical-leaders .com. Is that right?

Todd Larsen
Correct. Yeah, technical -leaders .com. We've got more information about that.

Matt Widdoes
Okay, awesome. And I'm curious, going back to kind of the general stuff, how do you think about your either you specifically or technical leaders for lack of a better term, their contributions to growth as an engineer as an example in general? And how do you work or how should senior tech leaders be working with other functional leaders across the company to drive growth?

Todd Larsen
I think remembering that our job is to enable capacity for growth. It's not to just build. And I think a lot of people get caught up on like, our job is to build, but it's actually to understand what is the growth roadmap and the trajectory that they're going to need, and then how can we strategically build things to make that possible. And so I think that comes down to the sequencing of solutions I touched on earlier of like, what is on the roadmap? What is the different capacity we're going to need? What will we need to build? What could we buy to get there? And then go through the execution of that. And so I think the biggest thing is to remember that our job as technicians and technical leaders is to use technology to achieve business goals. And that's it.

Matt Widdoes
Well, one thing at Mavan is we've seen and a big thesis of ours is that the supply of world -class growth talent in pretty much every seed across growth is dwarfed by the demand. So everybody's looking to hire a world -class XYZ in marketing and product and tech, etc. When you look at how companies are hiring CTOs as an example or senior tech hires, what do you think most companies get wrong when making that hire? And what do you wish most companies would know about those positions?

Todd Larsen
I think the thing they get wrong most often is just like looking around the room and saying there's the best engineer. Let's promote them and I think that's kind of on the surface level like an obvious thing to do like let's just take the best of them And then make them in charge of everybody else but the problem is that the job of being a leader is totally different from the job of being a builder and So there's a whole process of like updating their definition of work. What is that level of work look like? What are the things they need to let go and delegate to the team so they they can stay on the higher level of Strategic leadership and so I think that's the biggest thing is not understanding the total difference of the nature of the work between Writing code and then leading the people who are writing the code

Matt Widdoes
We've seen that too in other functions. I mean in the sales or you almost never want to promote your best seller to your sales Manager because they're super driven. They're able to close deals. They like that hunt They like all of the chase of all that and then you almost take them out of commission and put them in sale Okay, now manage other people and make them really good sellers and it's like it's a different skill set And so it's not to say that sales managers aren't great sellers. They have to be great sellers But they need to be great leaders and it's a different function. You know some are you know typically stereotypically maybe like your best salesperson is just a lone wolf they're rogue They do it whatever they want and they close deals and they're just completely, you know within their own bubble not necessarily a team player Not necessarily somebody who's gonna inspire anybody or have the patience to level other people up or even have the ability to Kind of coach and do all these other things. They're like that's boring. That's a waste of time. That's annoying I just want to go sell and there's probably some parallels with really good engineers I think particularly on the lone wolf side is like I just want to be you know in the cave Cranking out code and like testing things and doing all these other things and working on these little side things versus now I've got everybody coming to me and saying will you review this and what should I do here and is this you know What any number of things and you could end up in a situation where you actually end up losing that person? Because you force them into a role that they maybe didn't even want and I think that that's one thing that some of the larger tech companies Like Facebook have gotten right is that they're not forcing people? I think people go management routes because they just want more money and they're like that's the path to more money And it doesn't benefit them. It doesn't benefit the people that are gonna report into them It doesn't benefit the company And one thing that I think some of these larger tech companies have gotten right is you can have somebody who's in a support function making more than somebody who's in a senior seller function because they've been there 10 years and they keep crushing that one role and that they don't discount the role as just some quote, junior role that anybody can do. And they don't force people to go into management to get a pay raise, which everybody's ultimately looking at themselves as they should be. And so that makes a ton of sense. Are there other things when hiring, you know, we see a lot where it's kind of difficult to hire somebody. We use the kind of French translator example. It's like, if you don't speak French and you didn't have the internet to help you, it's really hard to go find a French interpreter and you might hire somebody based on how they interview and you're like, well, they sound like they speak French. And in English, they explained all the ways like, yeah, they grew up in France. And yeah, this person is going to be great. Their English is great. And then you put them in front of another French speaker who speaks English. And they're like, that person doesn't speak French. And it's like, they just tricked you. It's like, because you don't speak French. So there's a lot of that, at least in my experience on the tech side, where it's very easy for non technical people to just be like, I don't know what you're saying. I asked you a few questions, how might you handle this? But I'm largely interviewing on personality. And hopefully I have a few people on my side on the tech side that weigh in with some sort of an opinion. But are there other things not necessarily in that camp, but like when making a hire, because if you get it wrong, like any role, it takes some time to figure that out. And obviously, the knock on effects of that are pretty negative. Any other things that you, you know, would float to somebody looking to hire somebody in a highly senior technical seat?

Todd Larsen
Yeah, I think you want to look at like, what is the nature of their role? And what I mean by that is it could be, is it need to be more innovative? Or is it more managerial? And I think you touched on this a little bit, which is a problem is that the career ladder is thought of as a ladder and that you have to go through all these rungs in sequence. And the nature of the work of each of those rungs is quite different. And so I think it's a lot better to think in terms of like swim lanes. And so there's these different swim lanes, and there's different roles and responsibilities within each of those lanes, but the work itself is totally different between those. And so I think when somebody's trying to find their technical leader, they need to understand like, is this, do I need them to manage a process that's already been innovated and it's up and running? Or do I need somebody who's going to innovate and create something totally new, new technology? And so stage of company is going to dictate a lot of that, but not everybody is a natural manager. And so understanding the difference between, are they leading? Are they managing? Do they need to be leading innovation or just managing a process and getting really clear on that, I think is one of the biggest, most important things because you're going to find somebody that's going to naturally gravitate towards that versus trying to kind of force fit them like you described.

Matt Widdoes
Makes sense. And I'm curious, you know, switching gears a little bit with all of the attention recently on generative AI and other things. What are your thoughts on the coming AI apocalypse and other other things? Do you think it is? Yeah, just maybe I'll leave it broad as a starting point.

Todd Larsen
Yeah i think you know to some degree we need to kind of see the dust settle and it's starting to i think the hype is kind of dying down you can't just build a thin wrapper around open AI and expect that to be something that's really durable and so. I think we're starting to see what's gonna happen but in general i would say AI is devaluing and commoditizing just pure technical skill because it's getting better and better at generating just kind of boilerplate tech and we've had this for years when you think this is gonna get really nerdy for a second but in ruby on rails they have what are called generators generators. Generate code save time for engineers and it's just like boilerplate stuff that every project needs so i is kind of like an iteration on generators is able to create more and more boilerplate code and so what that means is. To be more valuable as technical people there's more of an emphasis on non technical skills business sense and so that's a great thing because it means we're gonna be able to spend less time on things that are like already solved problems and we can work on higher level problems that are novel and more exciting to solve but it also means that we need to invest in these non technical skills and business sense. Because just knowing how to bang out some code that does something is less and less valuable as i become more and more advanced so i think you're always gonna need people working on really deep tech hard tech problems yeah always gonna need implementers but some of that middle area of code generation is just going away because of AI or will more as time goes on.

Matt Widdoes
Yeah i feel like typically innovation just raises the bar for what is like the minimum thing that gets me excited about what somebody produced right so if you take the we've talked about before but if you take like the digital camera. Okay you don't need to spend all this time in dark rooms anymore and you can do a lot of stuff in photoshop great though that doesn't impress me that you spent fifteen hours in dark room so i can do that in two minutes now so you have to shift your focus on the something else or we talked about the kind of like digital drums. And like able to and very things where it's like okay well look you don't even need a kit so just show me i'm actually way more interested in some other form of that production and the creativity that comes from that as a function of this new tool that allows you to do things that aren't even necessarily humanly possible on a drum kit. Right? So I think this is very similar in that respect. Well, I think there's much more to come there. It's still early. It's funny for me to see people kind of dismissing that or being like, yeah, it's not very good, but it's like this is the most infant version of it. And I think in five years, you think again about the rise of the digital camera and megapixels and all these other things, it's likely to get

Todd Larsen
It swells quickly.

Matt Widdoes
Yeah. And this in particular can make itself better. Well, Todd, thank you so much for joining us today. You know, for anyone who's listening that's interested in a technical or who's in a technical role that's interested in up -leveling their skills, please check out what Todd's team has built at technical -leaders .com. I look forward to diving in deeper. We could probably do a whole other podcast just on your thoughts on AI. So maybe we'll slate that for later in the year. But thanks again for the time today and always great to chat.

Todd Larsen
Thanks for having me, Matt. This was fun.

Matt Widdoes
Totally. All right, chat soon.