Scaling Smart: Growing Your Development Team with John Radford

Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability with some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain podcast and my goal is to help you create DevOps toolchain awesomeness. Hey, do you want to learn how to scale your team in a smart way without losing your edge and more? And are you afraid of AI? Well, I have the perfect guest for you. We have John joining us who's a seasoned tech Entrepreneur with over 15 years of experience in software development, product consultant and recently AI integration which we talked a little bit about in the pre show. Really excited to dive into. He has built and sold an agency built products, have raised over a hundred million in funding and leads teams that have delivered, transformed and really gone through a lot of transformation creating digital products for both startups and global brands. John really specializes in turning ambitious ideas into scalable products. I think a lot of developers listening in are really going to be excited to hear more about and has a deep understanding of the tech ecosystem that you all have to deal with. And he's here to share his insights on building MVPs, raising capital, scaling high performance teams, AI and a whole bunch more. You don't want to miss this episode. Check it out. Are you ready to level up your DevOps game and crush those quality challenges? Whether you're dealing with flaky tasks, scaling automation, or trying to integrate security into your pipelines, we got something just for you. Introducing the DevOps Quality Testing Playbook from Test Guild. It isn't just another PDF, it's your go to guide, packed with actual insights, best practices and strategies to help you create a bulletproof DevOps toolchain. It's built specifically for engineers, testers and DevOps teams who want to optimize their workflow and and drive continuous quality throughout their pipelines. The best part, it's free and ready to download. So don't miss it. Hand it over to test guild me forward slash DevOps book and grab your copy today. Stay ahead of the game, optimize your pipelines and let's crush those quality challenges together. Hey John. Welcome to the Guild.

Hey Joe, thanks for having me.

Awesome to have you. I guess. Before we get into it, how did you get into this gig into MVPs and software development? The whole thing.

Wow, cool. How far back do you want to go?

I'll tell you.

Let's do it. Let's do the backstory. So prior to doing this, I Wanted to be a composer, so a music composer. And so I was living in London at the time and I was kind of forging my path as a composer. And it's tough, like, I don't know if you've spoken to any musicians or know of any musicians, but earning a living writing music. So what I did was like write background music for stuff like jingles, I guess you would call them, library music, whatever, did a few of those. But like earning a living writing music is hard, particularly living in like a expensive city like London. So I ended up having to get a quote unquote proper job. And that proper job actually was cutting up ringtones. So this is showing my age A and B, like how, how far back the journey goes. And that that was for a company called Pocket Group. And what they did was kind of, they shipped ringtones. So you know, I don't know if you guys had like the crazy frog over there, ring, ding, ding, ding. All of these kind of things. So I was making those for this company that would kind of ship ringtones and other kind of mobile content into operators and that that kind of grew. And I ended up then going into kind of more account management things because they were like, you're a little bit more skilled than just kind of cutting up ringtones. I then kind of went to work for Vodafone to work on their content portals. So that was kind of downloadable content and all that sort of stuff. And T mobile as well, actually, which I guess in the States you guys would obviously know. The iPhone then came along and kind of completely changed that business overnight. So we were kind of selling Java games, like really basic Java games for like five bucks. And then the iPhone came along and you could get them for like 69. That kind of completely changed that business. So in the end I thought here's an opportunity here to kind of do something with these mobile apps and that sort of stuff. So I started doing some independent consulting, building out mobile apps for people using my network and using kind of third party devs that then grew into me kind of starting Rare Breed Digital, which was kind of our agency, which I then kind of sold to my partner and others when I had my first child. Took a bit of time out and then carried on in digital. And it's kind of grown since then. So when I say digital, I talk about building digital products for clients essentially. And those correctly mentioned have gone on to raise kind of significant money. So, you know, my thing is, is very much kind of building products that scale and kind of achieve Success, you know, it's not kind of churning burn. It's products that I know or that we know are going to still be around in three years time essentially. And that's kind of what I'm proud of, really love it.

So yeah, I actually have a career in music. I started off going to Berkeley College of Music thinking I was going to be a musician. All of a sudden I fell into software development and testing. So that's hilarious though. Same thing. Yeah.

Wow. There we go. Maybe there's a thing there.

Sure. So here's a weird question that made me think of this. You start off as a composer music. In the pre show we talked about how maybe some SMEs or developers may be afraid of getting started with AI. There's some tools now for musicians, like I think it's Sonu or Sona AI that writes songs for you on the end. They're incredible. And so if I was a composer, I may be nervous about AI. So how do you think this relates to developers? Do you think developers skills can be replaced by AI? Is this something they should be afraid of?

Yeah. So a quote that I often use with around AI is that I think people, developers, business owners, anybody shouldn't be afraid of AI. AI is here to allow humans to be more human. And so should a composer. Should a developer be afraid of AI? No, they should be afraid of AI. If they adopting it or embracing it, then they should be afraid of it. So if you're heading the sand, ignoring AI, then yeah, be afraid, you know, be very afraid. But if you are embracing AI and helping using AI to be the best version of yourself, or using AI to be more productive, using AI to be better at what you do, then no, it's a, it's a brilliant tool.

Nice. So I guess this leads into as we're developing software, maybe if we're trying to scale a team, a lot of companies will say well I don't need a team now, I just scale out to an AI agent. Is that something that is an option or are there other ways you may want to scale your team with real meat people, people in the flesh rather than AI bot.

I think one of the problems that teams have, like let's say they raise some funds and they get all excited and everything is, is actually scaling too fast. And that is a, that's a common theme that I would see or you know, in the, in the startup industry or development consulting world that we see is yeah, hiring too quickly. Like yeah, I've got some money, you know, I'VE got some venture capital, let's go crazy. Let's. Let's have some fun. Hire, hire, hire, hire, hire. And so, yeah, can I help you be a little bit more efficient with that? Yes. Will it replace developers entirely? No. But does it mean that you could potentially hire three developers instead of six or five? Yeah, quite possibly.

And how's that? Like, what kind of task have you seen that AI is good for that can augment a team rather than replace them?

Sure. I think stuff like automation essentially, like automating, testing, automate, you know, doing kind of manual tasks better or in terms of efficiency is really where we see AI in the tech sense in the developer world, really improving the workflow, you know, and it can be, I'm not necessarily like writing code, but quick check of code or maybe assisting with writing code. Caveat. I'm not a developer, so this is not a huge area of expertise for me. But in terms of kind of helping with efficiency, that's definitely somewhere that, you know, you can implement it into your workflows.

Nice. Now, I know you are an expert in MVPs. I guess before we dive into that, what is an mvp?

Do you want the actual minimum viable product or do you want what my take on an MVP is?

What your take is what you consider an mvp. A lot of people have, I think, misunderstandings of what it is they do.

You know what is funny? Because there are misunderstandings is one word, but different interpretations is another. And so I think an MVP is the quickest route to solving a core problem for a set of customers. So doing one thing and doing it well for small set of customers. So that's what I would class as MVP.

All right, so once again, weird question with AI. Have you seen AI helping people create better MVPs? Is that, is it assistant now? MVPs, making it easier to create an MVP to roll out and not worry that, hey, it doesn't fly. Let's reiterate and pivot.

I wouldn't say AI does, but I think like no code tools do. But before you even get to the no code building, for instance, so we don't do a huge amount of no code, but we have partners that do that. And I've done kind of run no code projects on the side myself. No code is great for kind of rolling out MVPs quickly and everything. Not great for scalability. But before you even get to the no code thing, I can kind of help you with that in terms of validating potentially that initial core concept that you might want to Roll out quickly. So my MVP is being rolled out on no code. And it's super simple. And maybe it's a. It's a small little thing that we're building for a small amount of users to test and validate. But prior to even getting to that, maybe note, AI can kind of help us validate a concept before we even build it.

How would you normally validate a product? If I'm in the band and have a demo, I may create a demo. Simple demo, four tracks, get people to listen to and if it gets, you know, some buzz, maybe build it up then in a real recording studio. Is that MVP the same way? Like, how do you get that feedback from an audience?

Yeah, something like that. So for instance, we're building a tool at the moment that kind of connects tennis coaches with tennis players. You know, simple tool, but it's not just that. What it is is it's an online tool where you are kind of uploading videos of yourself. It's a kind of a remote thing. So, you know, having a coach, like in the uk, for instance, where we are, the winters are. Can be not so great. And so playing tennis in the winter isn't. Isn't brilliant. So that means that coaches in the uk, for instance, will have a lot of downtime because they can't get on course. So this allows them this online tool that review people online and review their kind of videos and everything, and then they can give them feedback virtually without actually needing to meet in person. But prior to building that, just go and speak to a bunch of coaches and figure out is this actually going to be a tool that you guys would use? But then beyond that, don't give them yes or no answers. So ask them problems that they have in their current workflow to figure out what the solution is. I know I'm using a super specific example here, but you use the band example. So I'm going with the tennis coaching thing. And so you would ask them, so like, you know, what do you guys do in the winter? Like, how do you manage xyz? How do you kind of manage your time management? How are you giving feedback to the people that you're coaching? And then you can kind of start to figure out a picture of the problems that coaches have and then you can kind of propose them. All right, we're working on this tool. Can you give us your feedback? And you start to get an appetite of whether this is something that's worth building.

So I always have this quote in my head with Steve Jobs saying people don't really know what they want. You need to tell them what they are, create a product. So how do you know when you're listening to someone that that's what they really want? Like, how do you know that they would really pony up maybe money for the service and not just say, oh, yeah, this is great, I definitely would do it.

You know what, to use a quote of my own in answer to that is you don't really know until they part with that money. So true validation comes in the form of people entering those credit card details. So we can have a really good idea of what people want because they've given us those signals and they've told us what their problems are. But until you actually put the product in front of them, which is why the MVP is such a thing. Right? And getting that MVP out there quickly is so important. I believe you don't truly know until someone enters their credit card, because specifically in the uk, we have a slight not. Not a yes culture. But, you know, we're quite, you know, polite, I suppose. You know, you don't want to offend people. Our American, you know, you guys tend to be a little bit more down the line, which I love, by the way. It's so much more straightforward. But, you know, we're like, yeah, yeah, great idea. Sounds really cool, man. You know, whereas. And then it's like, oh, yeah, by the way, John, here's my product. I'm really looking forward to having you on board. Crickets. Nothing, you know, because I was just being polite. I didn't really think that your product was that cool. So I don't know, like, I'm a true believer that, yeah, true validation comes in the form of entering those credit card details. So the quicker you get there, the better. Yes, people. And obviously, I'm not going to disagree with Steve Jobs. It's a great quote. But I think you kind of have to work out based on the problems that they're telling you, what it is that you're building, but then get to that, that kind of problem solution fit as quickly as possible.

So when you give them this feedback, how do you not fall in love with your initial idea? Because I would assume that you have a great idea, you love it, and then you get feedback. You're like, I didn't think of that. I'm getting a lot of the same. I don't like that. But it seems like that's where the direction's going. Like, how do you. Do you ever see that? Is that like a real concern or a real Fight that someone has.

What? How do they fall in love with the idea?

Yeah. How they'd be more receptive.

Yeah, they do.

That's the problem. Yeah, yeah.

I mean, most of the time people do fall in love with their ideas. You have to really. I mean, one of the key bits of advice is talk to your users, talk to your customers, and it's okay to fall in love with your idea, but not to the point whereby you're just building feature on top, feature on top of feature on top of feature. Like, when we're talking about the MVP stage or these early stages, one of the biggest things that we see is kind of that feature creep and, like, people just bolting on feature after feature before they even launch, and they get what we call, like launch anxiety, where it's like just one more feature and then we're good to go, you know, because, yeah, we think that these users are going to need XYZ feature. So I guess you have to fall in love with the problem and the vision of the company, but not necessarily how you get there, like in terms of the specific feature sets when we're talking about in a DevOps environment. So you can be kind of customer led. And that's why it's kind of super important to kind of iterate regularly and all that kind of stuff.

I guess the opposite is how does a founder stick with their vision? You know, when I first heard about Airbnb, I said, this is awful. No one's going to want to stay at someone's house. That's disgusting.

Yeah.

And obviously I was wrong. So how do you know that? Like.

Yeah, I mean, I think you have to trust your gut a lot of the time. Right. And so a lot of the good founders that I've worked with or that you hear of success stories of are kind of coming at a problem from a personal experience that they've encountered themselves. So they have that kind of founder market fit whereby they are kind of uniquely qualified to solve that problem. So finance guy worked at Goldman Sachs for 20 years and figured some problems within the trading systems or whatever and then goes and builds a trading platform, then that person is going to be kind of uniquely qualified to solve the problem that they're solving. Right. So you have to kind of trust your gut a lot of the time and believe in your mission. But don't be afraid to pivot, because, like you say bnb, it didn't pivot majorly, but even so, the first platform that you see, if you kind of do a quick Google on like, show me a picture of Airbnb when it launched versus what Airbnb looks like now. They're two totally different things. So you still gotta be. Don't be afraid to pivot. I mean, I saw a thing today that I didn't know this actually. Sony launched their first product was a rice making machine and it flopped. And so they, they pivoted into tape recorders, which then, you know, moved into electronics and the TVs and certainly as we know them today. So, yeah, don't be afraid to pivot. You know, trust your gut, trust your vision.

Absolutely. So if you have an MVP you believe in and you're getting good feedback from, you're going to go to the next stage. And also say you have to pivot. Like, how do you get a team in place at that point? Because I assume you're just working on bare bones, just fleshing things out, and all of a sudden you're like, oh, I know, I need to scale this. Do I just burn cash, get investment and just build up the team, or do I get some outside resources to help?

Yeah.

I'm going to give a really annoying answer to this one. It's a politician. You took the words out of my mouth. It depends. This is like a politician's answer. But it does depend because it depends on what you use to get to where you are in that first place. So let's say if I'm bootstrapped and I'm kind of self funded to that point, is the revenue that's generating from these early adopters that you're talking about, is that be enough to kind of facilitate my growth? If so, carry on. But also there's the other it depends part is where do I want to be, where do I want this company to go? Because there's two different ways to build a company, right? There's different ways to skin a cat. It's not VC funding you mentioned, like go and raise some capital and everything. And that's fine. It's not that easy for the record, but certainly in kind of the current climate, raising funds has got harder. But yeah, do I want to raise some funds, VC funds, for instance, that changes the game significantly once you take on that VC capital. Because you've got to be prepared to kind of 10x fast. Because that's what VC is all about, right? It's about kind of propelling that growth super fast. So you as a founder, do you actually want that? Is that what you want as a business owner? Is that what you set out to do? Or did you just set out to build a nice lifestyle business to a nice living, and I built a cool piece of tech. And hey, off we go. If the answer is the latter, then grow slowly, perhaps with some outsourced resources so that you're not kind of burning cash on salaries super fast. But if it is, do we want to grow this thing exponentially? Then, yeah, take some VC capital, but still spend it wisely. But yeah, there's kind of two different routes that you can take that it is. It depends, I'm afraid.

No, it's a great point because there are two different routes. Everyone just, I think, seems that you have to get outside investors and really scale it up. I was reading a book, I can't remember the name of the book or what the company was, but it was like a founder and he started an SEO company and he took investments from outside investors and he said he would have been better off just being like a solo founder and not getting investment from these companies in the long run. And this was after like 20 years, right?

Calendly they bootstrapped to like 35mil annual revenue. So it can be done. Right. And so they didn't take on any cash until they were turning over 35 million, you know, so that's, that's pretty, pretty decent. So, you know, it can be done.

Love it. So are there any other big mistakes that founders make when they're building an MVP or trying to scale their teams?

You know, the feature one is quite a big one when it comes to scaling. And actually this goes to features as well, slightly is technical debt. We call it like the silent assassin. And it's ignore technical your peril, we always say, because the. And yeah, I guess this is a mistake is ignoring it. So let's say we've built the MVP quickly and dirtily, which in most cases is a good thing because you've done the right thing there. You, you've pulled something together, you've done it quickly, you've cut some corners. That's fine. You know, don't take a year to build an mvp. But with that, there are going to be some, you know, technical challenges that you, as you scale, will encounter. So you have to address those. So I guess the mistake is listening to user feedback and actioning that and bolting on feature after feature and improving your product from a feature perspective, but not improving your foundations from a kind of a tech and scalability perspective, which means that you've got a real, you know, a ship that you just kind of plugging holes in and you Know the water is going to keep coming in quickly and eventually it's going to sink. So yeah, tech debt, ignoring it, bolting in tons of features, that's a common mistake.

Yes. I want to say like I see feature creep. I know maybe you get one big client and you're building features just for them, but not thinking about the core. Why you create in the beginning, I assume. Is that a common thing that you see?

Yeah, absolutely. I mean, hang your hat, I mean we're talking specifically about a SaaS business here for instance, right? Yep. Yeah. So I mean, yeah, hanging your hat on one client, it can be tempting. But you know, that client can leave you just as quickly as they, you know, joined you. And so yeah, if they suck up all of your resource and completely change the product then yeah, absolutely, that can be quite dangerous.

So do you have any recommendations, you know, when they're scaling, when they are hiring developers or hiring outside help, how not to change, you know, the quality of the product? Just have headcount for headcount or even the company culture sometimes I guess would change if you have some sort of vibe to start with that people really were drawn to. And then as you grow, I assume that culture changes significantly if you don't kind of keep your values up front.

Yeah, it does. I mean it kind of comes top down, doesn't it? So the leadership team have a big part to play in this, you know, be it the founders or you know, CTOs or whatever, depending on whether we've got kind of a technical founder in place. But yeah, that if you are kind of using outsource help then you need kind of a decent in house CTO or head of engineering or something like that to kind of manage those teams. So obviously we provide that service to people where, whereby you know, you're scaling a team and you just need to kind of rent some devs from people and you don't necessarily want to do that hiring yourself, then we provide that for you. But we always like an in house product person or in house kind of head of engineering or something like that to kind of set the tone. So those are kind of the key hires that if I'm say a non technical founder, especially then getting that kind of head of engineering maybe ahead of product but they need to be like fairly technical to kind of buy into that vision is essential. And actually that's why I often say more on the product and kind of the founder side more on the technical side. The one of the most important skills as a founder is actually being a Salesperson. And what I mean by that is not just selling to customers, but selling to your initial team. Right. Of why us? Why join us as the team? Why are you buying into me? I've raised some money and I want to hire a technical head of engineering or a cto if I do have one in the first place. Why are they going to join me over, you know, a larger, larger company that potentially offers them a little bit more security? Why they're coming to us. So you've got to really sell them on your vision. And that's super important to get those kind of initial hires. Right. Because then it kind of feeds through the organization.

Yeah, I think it's actually a great skill to have with even developers having sales skills. Not necessarily like set the Song, but selling your ideas, getting your features in or your architecture in. Right?

Absolutely. I mean a really great CTO probably doesn't really do that much coding. Right. They're more of a kind of a people person and you know, organizational person as opposed to like a head down coder. They probably did that in a previous role or previous life. But in this specific role as a cto, that's not really what the remit is. It's about kind of leading the organization from a product and a culture perspective as much as it is making sure that we've got a decent platform here.

How does someone learn that? Do you have any tips on learning how to be persuasive or sales techniques? Sales techniques.

You know what, One of the main sales techniques that I've had over my career is just kind of trying to be yourself. Right. People appreciate authenticity and I think if you're being true to yourself and the best version of yourself that resonates with people also make people laugh. You can get a smile out of someone, they tend to trust you a little bit more. That's certainly in sales, I found anyway.

Absolutely. So we touched a lot on AI. When it comes to scaling teams, I assume you're going to have a lot of remote teams, but some companies like, no, everything's going to be in house. We have an office in San Francisco and everyone's going to move here. Once again, I guess it depends. But any thoughts around remote teams versus in house teams? Once again? Does it, does it all depend.

Yeah, I mean, it depends on some things. It depends on, yeah, obviously the funding available. I mean, you're going to have to have some pretty deep pockets if you want fully in house team in San Francisco, put it that way. But. Well, last time I checked, the going rates of a developer in San Francisco, they were reasonably high. So yeah, it's going to depend on that. But what is the advantage of having developers in house, be it San Francisco, nyc, London, whatever, specifically in London being, you know, close to Europe? Most of the, well, not most, but a lot of the developers that are actually in London, they've moved to London from Europe anyway. Right. And that's kind of the talent comes across from Eastern Europe. So is it a cultural thing? It depends how the organization was set up. So now you see startups kind of starting as fully remote from day one and so that culture then embeds throughout and we have a kind of work anywhere policy and whatnot. And does it make a difference? Not really, no. As long as you're all kind of being managed properly and kind of working together as a team is fine. I think, you know, I think the days of having everybody in one room and, you know, hacking together code and all that sort of stuff is behind us.

Personally, 100% agree. I've been working remotely forever and I can't imagine going into office. But like you said, it all depends.

I guess it depends, but I think, you know, our sentiment is shared by quite a lot of people, especially in the developer community. Right. And this sounds so cliche, but a lot of developers enjoy isolation, right? They don't necessarily want to go into a fancy office. They have massive screens, they've got a really nice setup at home, they're very comfortable and they can work when they want. You know, some developers operate best at between 2 and 4am or you know, whatever it might be. Let the devs be the best version of themselves. Don't force them to do something if they're not sociable people, don't force them to be sociable just for the sake of having them in an office.

And like you mentioned as well, we have so many developers we could choose from all over the world. When you do remote, the best of the best. So it seems like you can really open up your talent pool if you do more remote.

Sure you can, and actually probably reduce your overheads as well. As a result, you know, developer in the Ukraine or Hungary is going to cost less than a developer in an office in San Francisco. It's simple economics, 100%.

Okay, John, before we go, is there one piece of actual advice you can give to someone to help them with their MVP scaling efforts? And what's the best way to find or contact you?

Actionable advice is launch it, but then more importantly, relentlessly talk to your customers so it's that would probably be the biggest one. Let your customers drive your development and talk to them, talk to them, figure out, you know, if they're using your product. Hey, how are you getting on Joe? Enjoying the product? Anything we can do to help, you know, forms, feedback, surveys, all that kind of stuff. You know, try and get as much feedback from your customers as possible. And how can you contact me? Probably the best place is on LinkedIn and if you add me on LinkedIn, apologies in advance for some of my ramblings, but you know, I tried to talk product on there every day and kind of add some meaningful content. So yeah, John Radford on LinkedIn, add.

Me and for links of everything of value we covered in this DevOps Toolchain show, head on over to test guild.com p.

So that's it for this episode of the DevOps Toolchain Show. I'm Joe. My mission is to help you succeed creating end to end full stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers. Hey, thank you for tuning in. It's incredible to connect with close to 400,000 followers across all our platforms and over 40,000 email subscribers who are at the forefront of automation, testing and DevOps. If you haven't yet, join our vibrant community@testguild.com where you become part of our elite circle driving innovation in software testing and automation. And if you're a tool provider or have a service looking to empower our guild with solutions that elevate skills and tackle real world challenges, we're excited to collaborate. Visit testguild.info to explore how we can create transformative experiences. Together, let's push the boundaries of what we can achieve.

With lutes and lyres, the bards began their song A tune of knowledge, a melody of code through the air it spread like wildfire through the land Guiding tester showing the secrets to behold.