Building High-Performing Teams: Strategies for CTOs in Tech Startups

Thanks for doing this, Bobby.

You're welcome.

Uh, did you want to, do you want to give us a background? Like, who is Bobby?

Sure. So my professional background, I've been in IT now since, uh, 1997. I, uh, I did an electronic engineering degree with computing and business, and I pretty much dropped all of the electronics options in my final year and just focused on computing because actually that's where my passion lay. So yeah, I've been in and around IT for all of my career, and I've been working for largely online-based businesses. One exception had physical premises. But I've worked in that time, I've worked across both software development, I've worked across infrastructure, I've had exposure to many, many different sectors. I've worked in gambling and gaming, banking, finance, manufacturing, HR, travel. And when I was consulting, I'd get parachuted into the tail end of projects that had gone wrong across a variety of different sectors. So, you know, it was fantastic experience, although stressful at the time. So I'd like to think of myself as a well-rounded IT professional.

Okay, that sounds like it. I mean, there's the whole life of different challenges, and that's what builds the skill and experience, isn't it? So is it startups, or is it scale-ups, or is it enterprises? Like, sizes of companies, you know, you're majority of experience sits with?

So I've spent quite a lot of time in large-scale organizations, um, so organizations like Dell, uh, Rankle, um, I've worked for Tesco Bank as well. I've spent a lot of time in scale-ups, so I joined Betfair when it was actually a scale-up as opposed to startup, and so when I joined it was probably about 100 people 30 people in tech. I think I was employee number 303 at that point. And when I left, it was probably close to 2,000 people with about 800 people in tech across continents and countries. So I've been part of that growth journey with Betfair. And then the later part of my career, I've gone more towards the scale-up side. And working with businesses that want to grow, grow fast, and have outgrown that startup phase and really have to focus on how to develop further in order to continue to grow the business.

So how do you define, Bobby, startup and scale-up? Like, what's, what's some distinguishing metric, I want to say, or just like, um, like in definition terms, like what is a startup for you What is the scale-up for you? Is it like a headcount? You know, is it a yearly revenue? Is like, where does the startup become scale-ups?

That's a good question and not an easy one to answer because it varies depending on a number of different variables. So for me, a startup typically is a bootstrap business or angel investment. They're trying to launch a product, trying to make a dent in the marketplace. They're on the acquisition trail of customers at the same time as product development. So they've seen, they've seen a need and they want to try to exploit that need and obviously monetize. So a lot of time is spent on business development. Um, anything that's done from a product development standpoint has to be very, very carefully considered because there's not an inexhaustible amount of money. So it has to be Um, time to market is key. Um, failing fast, also key. And building something that resonates with your clients. And if you have to change it, you change it. For me, the scale-up aspect comes into the fact where you've already got market presence, you're starting to acquire more customers, and you need to expand your product set. But crucially, you've gone to the point where you've proven that you've got a revenue stream, and either that's self-sustaining and can pay for your next set of development, or you've gone to market and you've got additional funding, whether that's VC or private equity. But crucially, there's then some funds there to allow for the business to grow. And that's not just tech. I mean, you put in some of the other processes as well around some of the business development and the marketing pipeline, as well as starting to think about how you're going to continue to develop your platform and, and what are the other options you're going to bundle in, what the product enhancements you're going to do. It's not uncommon in a startup for people to wear multiple hats. In a scale-up, you'll tend to find that because things are moving so quickly, in a— you'll typically get to the point where it's not feasible for somebody to wear many hats. So in a startup you'll have a CEO will be very, very heavily involved in the product discussions because they'll have very definite ideas about what needs to happen. As you start to transition away, you'll find the need for more product-focused people that are only concerned about the product will become a requirement, and that allows the CEO to spend more time on other aspects of the business. And typically, um, you'll find that the needs of developing your software will move beyond having a group of individuals or even an individual writing the whole thing themselves to expanding out more. And then you've got other considerations like reliability, scalability, and, and, you know, uptime. Whereas a startup, you know, obviously you still care about those things, but the primary focus will be getting something out first and foremost and making some money and actual cash flow.

Yeah, I get it. So, so there's, um, there's an element of maturity, isn't it, and size, which, which is across, you know, all department or all discipline. In a startup, you'll have everything just bundled into this one body which is trying to push something out trying to find that market fit, trying to get these clients, trying to get stable cash flow. And then when the money comes in, organically speaking, you know, that maturity kicks in and you start thinking more strategically. Who do I need to hire? You know, maybe you build your management layer first and then, you know, you add people. So it's a very gradual size transition, right? Okay, that's, um, that's a good one. Um, what about, um, just, uh, popped in my head, to be honest, uh, accelerators and incubators. So if I'm a startup, what's your take on it? Like Do I need it? Does it help me? Or you think it's just if you actually have something which market actually needs, you don't really need them. Like you will experience success by just sort of getting things out, or do you feel there's a, you know, good element of going into incubator or accelerator and getting, you know, that knowledge which these programs provide to make a success better?

So there is no one set path for being a successful startup. I mean, if there was, everybody would be, would be following the cookie-cutter approach, and, and, you know, everybody would, would have a unicorn on their hands. It doesn't work that way, unfortunately. Um, I think incubators are, are a fantastic opportunity, especially when they're backed by, um, organizations that bring in people with experience to help you avoid some of the pitfalls. And that's the key, right? How can you minimize the mistakes and, and, and by definition avoid tying up valuable resource? And by that I don't just mean money, I mean time, effort, opportunity cost. Yeah, going down a path that actually won't get you to where you need to be. Be. And, and that's where I think incubators come into their own, because if you've got the right set of mentors, they will actually guide you to avoid some of those things that you may not have the experience to have avoided in the first place. That being said, there's quite a few startups that don't go down that route, and they manage to get themselves a good set of, um, either angel investors or, um, people associated that can help fulfill that function as well. So I think that the the oversight that gets provided is invaluable. Whether you do that through an incubator or whether you do that through your own network doesn't really matter. It's not about the vehicle you drive in to get from A to B. It's, it's the journey and, and how you do it and making sure you actually get to the other end.

I love that. That, that's, that's where I was leaning with this, is, is as long as you have someone helping you It could be your management team, maybe one of your founders, maybe investors, maybe you want to build a board. I mean, probably you don't need that in the beginning, but as long as you have people around who did it and they can point a finger and go like, be careful, common mistakes that here happens and you can avoid that, that's a more smooth path towards success. So that's a good shout. Let's talk a little bit about funding. That's one of the likely main, main questions when people think about startups. So how do I go and launch a startup? You know, a lot of entrepreneur ideas or, or vision, they always get that wall. It's like, how do I even fund those operations? Is what's your expertise, Bobby? It's like, do you bootstrap yourself? You know, do you take a loan? Uh, do you try to, you know, go to the market, find some angel investors? It's like, what's your, what's your take on it?

Again, this is one where there is no simple answer, unfortunately. Yep, it depends on what you're doing, what sector you're doing it in, and what the problem space is. The good news is that, especially here in the UK, there are a number of different grants that are available. So the first thing I would recommend to any startup is go and find out what grants you could be eligible for, and do you fulfill the criteria, and, and and that would be a great way to get access to some funding. Um, people have got an idea, have come out of an industry where they've seen that there's a gap in the market. Um, presumably if you're self-aware enough to realize that there's a gap in the market, you will also have built a reasonable network in that space to then speak to, one, to validate the idea, and two, to potentially speak to about either becoming an angel investor or actually becoming a mentor to help avoid some of the pitfalls we just talked about. There are some institutions that will back startups, not that many, because most of them tend to want to have some form of a track record before investing some money, but they are out there, so it's worthwhile exploring that. Wherever possible, I would always advocate trying to bootstrap as much as possible, just because you minimize the amount of the company you're giving away. Because in the early days, in order to, to, to get funding, you're, you're talking about quite a big slice of the proposition. And obviously that diminishes the more that— the more money you make and more revenue you've got. But then by that same token, if you're profitable, you don't need to go to market for funding as much unless you really want to turbocharge your growth plans.

Okay, define bootstrap.

Bootstrap, self-funding. Now, whether that's through savings, loans, credit cards, I'm not going to advocate that you take yourself into debt. Yep. Trust me. Yeah, but you know, you do what's affordable for you. And in some instances, people go down the angel route. So they speak to people they know in their network that have got some money that will will be prepared to invest small sums to get a proposition up and running.

I do like that. I mean, yeah, we shouldn't advocate for, you know, taking big loans. You probably don't want to over-leverage yourself. So if you're taking a loan to bootstrap your business, you want to weigh that against your actual capabilities to pay off that loan.

Exactly.

Because it's going to be your loan, right? It's not going to be a business loan. So you're not— even if the business closes, like, you're not going to be able to walk away from that. And I think there's a Says Startups UK or something like that, like service which offers loans. And they have a, right now with interest rates changing, you know, they probably have a higher interest rate, but they were giving loans up to 25K for startups, but the interest rates were actually poorer than the banks. So just taking like a bank personal loan was, you know, financially speaking, it was a better positioning. And that's something I did with some of the startups. Angel is definitely good. I mean, but then you do walk into that situation where you will be giving some equity, which is, you know, it's—

Yeah.

I have this saying, you know, 100% of nothing is still nothing, you know, and 60% of something, you know, that's something. So it's always this question of how aggressively are you protecting the equity and does it make sense, you know, to protect like that. If someone comes in at the stage of you know, you have an idea, you know, maybe a little bit of something done, and gives you a good amount of money so you can actually put something out to the market as a done product, you know, do you want to take it and see your product happening, or do you want to say, I don't want to give out equity, you know, I'll try to do that myself, which then becomes like one-person endeavor because you probably have no money to hire people, right? So one interesting question—

Yep. Just, just on that, that's a very, very valid point. I've spoken to a number of startups and, you know, that they're on that spectrum, right? Some will happily go take angel investment, and they've been really good about how they approach that because they're not just taking money, but they're taking money from people that then could have an impact on growing the business, or they can leverage their network in order to benefit the business. So I would always advocate for that.

Exactly.

Just, and then on the other side of the coin, I've seen, um, other individuals that are adamant that they do not want to dilute the equity pool because they're sitting on a unicorn. Now, the reality is they're never going to realize the value because they can't get the ground. And, you know, if you compare it to something of the likes of Amazon, Apple, whatever, because everybody's convinced they've got this idea that's going to change the world, um, the reality is that even the Jeff Bezos The founder of Apple doesn't have the largest share of equity in Amazon. Sorry, in Amazon. Bezos and Amazon, he doesn't have the largest share of equity. He never has throughout his journey. He's gotten funding, and yes, he's got a substantial stake, but the funding partners have got a—

oh yeah, absolutely. Um, I have some founders which I know, you know, who raised Series A and B and raising C, and they right now around 10% and some, some are less. So you give out along the way, but by you raising, you know, big amounts of money and you're actually building, you know, big businesses— if you organically speaking, for you to do a unicorn and be able to generate so much cash flow so you can grow at rapid pace, which is effectively expected when you raise money, um, it's just statistically speaking, it's just so, so unlikely, right? It's just how the market works. It's like if you have something, it's going to be known quite soon that there's a market for it. And if there is a market for it, you're going to have very good numbers to raise money for. And then you raise the money and you just basically go from that startup to that scale-up. Which leads to a question. What are maybe typical or expected growth rates for startup and scale-up? So let's say I'm a founder. And I didn't took money, how quickly do I want to see my business actually growing so I know that I want something here? Or if I took the money, you know, how quickly should I be growing to make people happy who gave me the money?

Hmm, good question. We'll start with the self-funded group. I think the biggest limitation there will be the amount of the funding that's available to develop the proposition and, and to crucially to do the, the business development. Now, um, typically what will end up happening is the appetite for growth will outpace the financial capability for growth, so it needs to be tempered. And, and so people need to be realistic about um, how quickly they can grow. And that's why quite a lot of startups tend to go down the angel route, but then you're answerable to the angel investors that are on the board, um, you know, and they'll, they'll want to have results. So again though, it comes back down to how much has been invested and, and what do you get for the money. Software development isn't cheap. Um, the reality, it just isn't. It takes highly skilled people, and you can offset the cost by getting people in, uh, low-cost places to produce your MVP, but ultimately you're still accountable for it, and you still got to grow, and you still got to, um, deliver on something that will fulfill the needs of the market. But cheaper isn't cheap. So one of the things I say to people that are doing startups is make sure we factor in the cost of development and have a realistic cost of development. But also on the flip side, um, I was advising one particular startup who wanted to spend £5,000-6,000 building a website that had no product to launch. Um, it was brochureware to try and understand what the interest was in a particular territory, but as part of the brochure, it then outlined what the proposition was. And it's very, very unusual for a technical person to advocate not doing a technical piece of work. And to me, that £5,000 was a waste of money. It would have given other people in that space an opportunity to understand what what the proposition was and to come up with their own answer. Um, didn't need to spend the money at that point in time. Um, in parallel, there were discussions with, um, partners that would actually be using the service. So the key thing for me would have been to get those nailed and then figure out what you need to go to market with, uh, and, and a brochure website I think is a vanity project in this instance. Um, spending the money on building the proposition, a lot better and a lot more valuable. And, um, ultimately I think it's, it's the same irrespective of whether you're a startup, a scale-up, or an enterprise organization. You need to have a firm grasp on what is the value of what it is that you're doing, otherwise you'll end up wasting your resources, time, money, opportunity on something that isn't what you need.

Do you have a framework, Bobby, which would, you know, you would consult founders to follow in that crucial beginning? Because, you know, you gave this example where you was like, I wouldn't do that. So it sounds like, you know, you have a way— maybe it's not, you know, a cookie-cutter way, but some type of framework which, you know, potentially is followable?

Um, not a framework per se, but I would, I would advocate for everybody to think about what's the return on investment. If I spend this, what am I going to get back? Now, it doesn't matter whether it's marketing spend, because let's face it, as a, as a startup scale-up, you should put some money to one side for, for marketing and building out your sales pipeline, and you should do that far enough in advance of your, of your targets that actually you've got realistic chance of hitting those targets. So one place I worked at, they had the marketing budget and pipeline development offset from the sales by 3 to 6 months, which is a great idea because then all of a sudden you're not hounding the salespeople for, um, for for sales figures when they don't have a pipeline to work on. And I think that's a great approach. And similarly, when you're looking at, um, product enhancement and product features, realistically, how much of an impact will they have? Just because the customer wanted a widget blue, fine. What impact does that have on the rest of the code base? What impact does that have on the rest of proposition you're taking to market? And if you're going to bespoke somebody for a customer what else will they start asking for? And do you end up with a divergent code base? And if so, does that factor into the development of your platform? Or do you want to keep things as cookie cutter as possible so that you can sell the same system to as many people as possible?

So that's where prioritization versus value comes in play, isn't it? It's how do you— how do you think about things you, you need to do? And as, you know, as a founder with let's say, couple of people, you're gonna have such a huge queue of work you need to do that, you know, it's just going to be overwhelming and you'll need to choose the things which has to be done, you know. And thinking from that, what you mentioned, the return of investment perspective, do you have a way of thinking around this, or is it just always return on investing? Like, you know, let's say I'm a startup, you know, maybe I have a product I'm selling, which works fine currently. You know, I'm doing everything because I'm a founder and I have a couple of development probably somewhere offshore. So I effectively, I just have like coding and products being done and everything else is just me. How do I prioritize everything I need to do? Marketing, sales, you know, going to market, you know, getting customer feedback is, is like Is there a theme which comes out quite often which you would put at the top? It's just like, what's your thinking on the whole situation, Bobby?

As a startup, I would advocate that you probably focus more on business development at the outset. Um, it's no point, no point building the best thing in the world if nobody knows about it. Um, you need to get that market awareness, you need to get people excited and interested, and, um, then obviously you need to have something that meets that need. Uh, I— one of the things that I think is very, very useful for startups, and indeed scale-ups to a certain extent, is don't think that you have to solve everything by yourself. Use your network, use the people around you to get advice, but also don't be afraid to go to market and look for fractional expertise. So there are a whole host of fractional CTOs, there's a whole host of fractional finance people, and you can get fractional marketing and fractional sales as well if need be. So don't be afraid to go to market if there's something that doesn't fit into your skills gap and try to, try to get the best that you can for your budget. Um, you're better off having a fractional marketing person for a day a week just providing you oversight on business development than trying to do it in-house when you don't really understand that space. Similarly, if you're a non-tech founder, having somebody with the technical expertise to come in and help with the size, shape, and delivery of what it is you're trying to achieve will pay dividends of their own down the line.

It's a self-awareness exercise, isn't it? Because I think not every single founder will go like, I don't really understand what I'm doing over here. Because you don't know what you don't know. And it has to be this element of like, I don't know that sector, let me just hire someone. And I think as well there's a mindset shift, you know, from going like, I want to learn and do this, to actually hire people to get this done for you. So it's like, it's not how, but it's who. And that, you know, that element is, at least in my experience, is quite hard for some. Some founders, they always think how, how, how. But if you just sort of stop asking how and you start asking who, then you're absolutely right. The fractional positions is actually quite, I want to say new, but it's definitely growing in my viewpoint. It's like CTOs, CFOs, sales, and it's just, I feel like it was a lot less fractional people like a couple of years ago. Everyone's, you know, I'm doing this consultancy/fractional work, at least in tech sector. So, um, how does the, how does the focus on, on product shifts when you go from startup to a scale-up? So we sort of discussed that startup is just all about product, right? It's just all about getting the feedback, talking with the market, talking with people around, trying trying to get it out there in a shape where you can actually start selling. How does this focus shift when you, when you become a scale-up?

So when you're a scale-up, you've got established customers, you've got revenues that are coming in, um, you're obviously still on the, on the business development trail and, and we're going to land new customers. So you've got to do two things there, one of which is to constantly keep an eye on the marketplace to see what's up and coming and to try and stay ahead of it as much as possible. Um, or if you can't, then become a close second to whoever the market leader is, because let's face it, sometimes people don't go with the market leader all the time, right? Um, and then the other piece is, um, with your existing customers, understand their needs and use them to help drive the platform forward. Now, not every idea from a customer will be will be brilliant, right? Um, but that's then the job of the organization to go, hold on, we think this could add real benefit to the platform and it could meet the needs of a whole load of other customers, so that makes sense. So we'll start to take a look at doing that and then building out and developing a longer-term roadmap that's, that's, that goes beyond the, the end of your nose, which in a startup, that's, that's typically the way that it will work. You'll have an idea of where you want it to go, but you're subject to market forces a lot more. In a scale-up, um, you have the opportunity to dictate to the market to a certain extent. You want feature X? Well, actually, we can't give you feature X, but we're working on this which is similar and has a broader appeal, and we think this will get you 80% of the way there. Is that, is that good enough? Um, I had one occasion where I was on site with a client in a previous job, and we were helping them with their travel solution. And all of a sudden, it morphed into a conversation about trying to, trying to get the system to also cater to their insurance solution because they had unique insurance requirements based on where they were traveling to. And, uh, so we had the discussion with them, we helped them understand what it was they were asking for, and as part of that process we came to the realization that actually whilst what they were doing was good and immensely valuable, it was so unique it would only ever work for them, so had very little value to us as an organization beyond tying up a lot of our development resource for a while. And that meant there were other things you couldn't deliver. And in that instance, if it's just not worth it to the rest of your customer base, you have to have the conversation which says respectfully, this is great, but this isn't our wheelhouse. We recommend you go somewhere else. Then you shouldn't be afraid of having those conversations. The worst thing you can do is try to be all things to all people. And that's where you end up with diverging code bases that are a nightmare to manage and maintain. And you tie yourself up with technical debt down the line that cripples your growth as a business.

I like that very much, Bob, because I can resonate with that. Um, in one of the startups, we, we effectively took pretty much everything what the flagship clients were telling feature-wise, you know, can you get this done? Of course, because that's our biggest, you know, couple of clients. And then eventually you end up with these almost like bespoke features which works for that particular client, but it's like if you talk with others who have a different context, you know, different size businesses, you know, maybe different demographics, they go like, we don't need that. And then yeah, you just end up with a bunch of customization work and you almost just end up like, here's a platform and we just agency around that platform rather than actually building a product for, you know, for the market. So very good shout. So the value, You touched here on the, on the customer feedback, you know, effectively, you know, going out asking, you know, what needs and having these tough, tough conversations. So once you get that coming in, um, how does that sort of play into customer acquisition? It's like, um, what's the full circle, you know, in your experience? It's like, how do you build something which, you know, market needs so you can acquire more customers, aka, you know, just you know, get the bigger market share? Is there any secret sauce or recipe or framework or just your, you know, your thoughts around that?

Oh, if only there were a secret sauce, then we'd all be millionaires, right?

Someone would write a book and it would be bestseller.

Yeah. The reality is everything that you do is a risk-based approach, right? The key is, I think, to understand the sector that you're in, understand what will have an impact if it's a new product or an adjacent product. Try to sign— sound out some of your customers beforehand to see if they'd be interested in the development of Feature X or new product, why? And if there are positive outcomes from those conversations, then start to take a look at what a prototype could look like. And again, keep some of those customers engaged so that they feel like they're part of the journey and providing input. And then, um, if you do come up with a new, uh, product or a new feature, then, um, especially if it's something that's going to be chargeable, my advice would be offer it up as a beta to some key customers first to try and get them engaged, but also find out if it really works in a real-world situation. And then do that with an offer of a discount on, on the list price when it goes live. Um, or if you have the opportunity, I mean, one organization I work for, we, um, we built a product feature that, or new product, and we were looking at beta testers and then COVID hit. And it was a performance management company, so HR-related performance management. COVID hit, a lot of organizations all of a sudden had to send people to work from home because, you know, nobody was allowed in the office. So what we did was this new product we offered for free on a 3-month trial. So that did a couple of things which are really valuable for us. One, we got a large amount of data coming back on how people are actually interacting with the platform. We got the beta shakedown we wanted and then some, and some bugs came out that needed to be fixed, which is great. And then the, the third thing, which was worth it all by itself, was that it got people enthused about product. And when the salespeople then went to market to sell it as a bolt-on afterwards, it was much easier for them. Now, you can't always do that with everything that you develop, but if you are looking at building something that is going to be an additional product or an additional charge, how can you launch it in a way that, um, that makes the sales job as easy as possible. And you know, that's where everybody needs to come together and have that discussion. I mean, it's not an IT discussion, it's not just a marketing discussion, it's a commercial organization discussion. And especially when you're in a scale-up, you've got a lot of expertise around the business that will come up with good ideas on how to do things like that.

Okay, so two things. One, does that So what we just talked about is we're talking with our existing customers. So we already have a product, you know, which is getting sold, and we're talking about additional features. So we're talking with existing customers. Does any of you— what you just gave differ if you're talking with customers from like just general market? They're not yet your customers, but they are, you know, your persona of interest. If you're talking, you know, with that sector, does any of that approach differs in any way?

There it— yeah, it will differ, and that's a good point. Um, your go-to-market strategy changes drastically. I mean, the, the thing that is key to keep in mind, and to be honest with you, it doesn't matter which part of the business you're in, is what is the problem you're trying to solve. And, um, when you go to market, it's what's the problem I'm trying to solve for my potential customers and how can I make their lives easier? And when you do develop new features, new products, it's how do you position that in such a way that it becomes obvious that this is a solution for a set of problems that organizations are facing. And your business development team will be in contact with various leads, and they should if they're— if they have managed to get inroads, have an idea of some of the challenges that organizations face. So how do you position your products to address the challenges that they've got? How do you make life easy for them? Because nobody wants to complicate life at work, do they? Um, and then the key thing is how do you get that in front of the decision makers as opposed to the people at the ground that will feel the impact? And especially when you're at the early stages and you're not a you're not a well-known industry name, trying to get in front of the decision makers is key because they'll be the ones that will either provide the support that you need internally and help knock down doors, or they'll be the biggest obstacle, and then you're fighting against other, um, other platforms that may have similar capabilities but may not be as good.

Yep, I like that very much. I feel like If you are a startup and you don't have a strong sales process or a strong sales, you know, person, that realization that you need to be talking with decision makers or people have budgets to spend, it's just gonna— you're gonna waste less time. Because, you know, usually people go, they try to sell to, you know, maybe closest friends, the network, which effectively is not who you should be talking with if you want to just have a much quicker sales cycle. So, um, from my perspective, like, what— everything we just talked is applicable to startups and scale-ups in the same way. Would you agree or disagree?

Oh, I would agree. Um, in fact, I would say it probably applies more to scale-up, and that sounds counterintuitive, but I'll tell you why. Um, With a scale-up, if you take a look at the definition I used earlier, it's an organization that's got money coming in and they've gone through Series B funding, Series A, Series B, so they've got a good amount of cash. Don't let that be an opportunity to fall into complacency because you're not as hungry because there's a longer runway in front of you. If anything, it needs to be the other way around. You need to be even hungrier, even leaner, and making sure you're maximizing every single pound that you spend to make sure you're not wasting the opportunity. And so, well, if that means you're chasing down those sales leads and you're, you're increasing your attendance at the appropriate conferences, industry events, etc., to help develop that pipeline, happy days, that's what you do. Um, if it's accelerating your your product delivery, fine. That's based on a known roadmap that will add value, and you know things will land well. But you have to be obsessive about value.

Good shout, I get it. Risk management. So small or big, your risks will be different, and they, you know, they will grow. Like, as a startup, you, you In the beginning, you're just going to be thinking, you know, how can I make money? How can I increase my cash flow? Eventually, it will all grow. And we're talking about tech solutions, we're talking maybe about SaaS platforms, you know, data governance, you know, regulations comes in play. So, if we just talk about cybersecurity a little bit, or just securing your applications in general, any insights for startups? Like, do they need to worry about this? From the get-go, you know, from day one, or is it something which comes in, you know, down the line when you effectively try to sell to maybe a government sector or a bigger organization and they suddenly ask you questions such as like security self-assessment or whatnot, and you go like, oh, I should be thinking about that?

Yeah, um, that's a good question. And, um, I, I would say that you can never start early enough with any of the regulatory stuff and the security stuff. That doesn't mean spend your entire budget on it. It's got to be pragmatic. And it's got to be proportionate with what you're doing. Now, if we take a look at the regulations, as an example, we'll use GDPR, privacy by design, etc., etc. Yes, you can do that after the fact, but it will be a lot harder to retrofit into something that's working versus designing it from the ground up to operate that way. Similarly with security, bake in your security considerations, your security concerns from day one. Have secure coding practices embedded. At the very least, make sure the OWASP Top 10 are catered for as part of your application. There's a whole host of testing tools that are available now that will do code analysis or do vulnerability scanning, or you can get pentest as a service. Bake that stuff in, factor it into your budget, factor it into your spend. Because guess what, if you're going to market, your clients and customers, depending on what solution you've got, will be asking for some of that, or at the very least, there'll be an expectation of that. And the consequences of getting it wrong are massive. Loss of reputation can kill a business, and loss of reputation for doing something that could have easily been done at the outset by just taking some time to consider the security concerns or taking some time to consider the data privacy concerns— just, it, for me, that presents a level of risk that no business should, should be considering. And then as you grow and you start to expand on what you do, guess what? The size of the budget you apportion to those things goes up as well, because it's not a case of when you get— if you get hacked, it's a case of when you get hacked, because people are trying to exploit vulnerabilities all the time. And keeping on top of Vulnerabilities and keeping on top of keeping things secure are full-time jobs for many people. So try to leverage as much of that as you can.

Yep, fully agree. Um, maybe, maybe to add how startups should be thinking. So if I'm B2C and, uh, you know, I'm selling to customers, which effectively is, you know, a person at home just subscribed to whatever is my service, You likely have different security profiles to, you know, consider. If you're selling B2B, the size of a business will effectively create a requirement list for you. So if you want to, you know, land a big flagship client, you know, which has many offices, many people, you will be asked those questions. Like, you will need to convince them that your platform is secure enough because they have full-time security people, you know, CIOs, you know, they have their forms to fill, you will need to pass those security self-assessment questionnaires to be able to offer your service. So that's just by default. If you don't think about this from the get-go and you're thinking about B2B and you're thinking about, you know, big clients, you're just going to take a step back and, you know, need to fill that gap. Absolutely. Yep. And there was a second point which I wanted to add and now I forgot about that. Just flew from my mind. So startups, how does the cloud help in this perspective? So let's say, you know, maybe I'm using AWS, maybe I'm using Microsoft Azure. Are there any particular services potentially I could be sort of baking into my product which allows me to have that a much better, you know, posture security-wise, you know, from the beginning of building my product?

So if we take a step back and look at cloud, not just from a security, security perspective, but from the benefits it gives to startup, you go back 10, 15 years, and the number of startups that existed were vastly, vastly reduced compared to today. And the reason is the barrier to entry was so high. If you had to buy servers, host them, expensive. Now you can get started tomorrow if you wanted with a few hundred quid and have some servers up in the cloud. But the other thing is, uh, and coming back to security, all of the cloud providers have got massive teams of security people. They have tools available on the platform that you can subscribe to, and a lot of them produce, um, blueprint architecture as well. So follow that and you've got a really, really, really well-defined path to go down which outlines how to set up your environment, how to protect it, how to ring-fence it. And then on top of that, you've got a host of organizations that specialize in bolstering that and adding to the standard tools that are available. So In my opinion, it's very, very easy for organizations starting out to have a really good security posture out of the gate.

Just by going and using cloud, isn't it?

Exactly, exactly. I mean, I was at one organization, um, and this was 5, 6 years ago, and we needed to build a data warehouse. We had the data warehouse up and running in a couple of days. Now, If I go back 10, 15 years ago, that would have taken us a couple of months to get the hardware, get it procured, get it installed, get it configured, then install all the software and then start building the data warehouse. I mean, the lead times alone make cloud viable and never mind the cost because all of a sudden you don't have to buy all that kit and have that hosting space. You can have something up and running and you pay for what you use. Similarly, with all of the security services that are available within the cloud, it's all consumption-based. Yep. So you've got enterprise-level security available for pennies versus tens of thousands of pounds that would have been, um, a decade ago. Yep.

And as well, using cloud— come back to that startup scene— AWS, Azure, and GCP being Google Cloud, all of them have their own startup initiatives. You know, it's almost like incubator programs, right? And you go through that, you register, you get credits which you can spend. So meaning, you know, from day one you can offset that cost to some extent and, you know, build your product straight in the cloud, you know, get all the security posture and just not really, you know, worry about infrastructure at all. And I know currently at least Azure and GCP are chasing all the best ideas around AI. So the startup programs, if you're coming with AI product, is, you know, it goes up to £250,000 in, in like chunks. So if any startups thinking, you know, AI products, yeah, definitely to take a peek. Um, any best practices?

Yep.

Go, Bobby.

Just on that, before we, before we move on, there's, uh, quite a few of the cloud implementers as well also get, um, subsidized, incentivized, uh, by the cloud providers to do, uh, an audit on an implementation. So they can also flag if there's any gaps. Now obviously they do that on the basis that, um, you'll use them to remediate those gaps, but that's a very, very useful way to find out whether or not, one, your infrastructure is being used as it should, two, whether it's fit for purpose or whether there's a more optimum way of using it, and three, whether or not your security is what you anticipated or whether that can be improved. So I would absolutely recommend that anybody listening to this, if they've got any concerns, explore that route.

Good shout. Thanks, Bobby. Practice-wise, so we talked conceptually, right? Security, one of the, you know, risk management factors for any business, any size. Start early, use cloud. What about lower-level processes like development teams? You know, I'm writing code, you know, I'm getting Jira tickets, I'm seeing features I'm building, I'm writing code. That's what I do. Is there any recommendations you would give how organization can look at the, you know, different levels of processes and sort of bake the security in all of them? Is it like a mindset, you know, is it like a memo from CEO, let's think about security, or is it more like practical ways you can do about this?

When you say memo from the CEO, I'm reminded of the memo that Jeff Bezos sent out about everything has to be services. I think it's, it's mindset first and foremost. Because anything else you put in, if you don't have the mindset, right, people ignore. So you can have code analysis tools. And, you know, they've got their own challenges, because you've got to bake out the false positives. They are useful, they are very, very useful. And I would recommend using them. But you need to have the mindset that people need to take ownership and accountability of their code. And, you know, give them a— ensure that their code is performant, it's secure, scalable. And, you know, that way you don't end up in a coding cul-de-sac because the code is taking you to a dead end point. But the other piece as well is information security people are expensive, right? And as a startup, you won't necessarily have the funds to have somebody on board full time. So again, take a look at the professional route, or take a look at partnering with a security firm that can provide the capability as and when you need it. And if you have the funds, take a look at maybe outsourcing your production security to a managed security operations center and let them provide all the monitoring and, and management of the security posture of your estate. And, you know, there's some organizations that will do managed detect response service. So if there are issues, they'll deal with it and you'll get notified. And that way, you don't have to constantly try and play catch up in a market where information security professionals are getting more and more expensive. And if you're a startup, you probably at a push can only afford a fractional. If you can afford a permanent, that's then if they go, you're then in trouble. So outsource it and make it somebody else's problem to retain the staff, because actually it then leaves you time to just focus on doing what you need to do, which is building great products, selling them to the market.

Okay, so we're talking about people now. Let's talk about team structures. Right. So let's say we're building a SaaS platform. You know, we went from a bootstrap angel, a couple of people. Now we in 20s. And, you know, once we in 20s, we raise the money. So we're going to go, you know, into like 60s headcount and beyond. How does the, how does the team structure changes? Like in your experience, like, do you have a way to think about how you structure, you know, development, product and all of the teams? I want to throw the Team Topologies. Not sure if you're familiar with that book or not. It's a book effectively which defines 4 different types of teams and where they sort of fit in organizations. What's your experience around just team structures, Bobby?

So, pretty much everywhere I've worked, you've got a product team and development teams as separate entities. And I quite like that approach because there's that competitive tension between the two. Ultimately, they may end up reporting into the same person at the top, but, you know, at the implementation level, they are separate, and they need to be to hold each other to account. In terms of teams, team sizes, it's, it's really one of management and oversight, and that determines the different levels. Now, I'm a big believer in— I think the maximum amount of people an individual can manage well is up to 8 people. Now, um, when I build teams, I tend to have teams with team leads that are autonomous, and then team leads reporting into, um, a dev manager if you get to the point where you have multiple teams. And then multiple dev managers reporting into a head of dev, uh, and so on and so forth. Now, in terms of the makeup of the teams, it depends on whether you're startup slash scale-up versus a large-scale organization or enterprise organization, because for me, the team makeup shifts massively. Because in the startup scale-up, you want to get as many experienced people as possible so you can push product out as quickly as possible. Whereas in an enterprise-level organization, or even at the upper ends of a, of a scale-up, I then like to mix up the, the skill level in the team to get more juniors in. So then there's progression. Startup scale-up, it's all about pushing things to market and getting, getting revenue in and maximizing the opportunity. Whereas larger organizations and the upper end of scale-up, it becomes about making sure you've got defined career paths for, for everybody there. Um, you know, how do people progress? And the seniors progress by mentoring and coaching the juniors, and the juniors progress by absorbing everything they can from the seniors.

I like that, and I can very strongly resonate with the, the fact that you should be leaning towards seniors when you think about the startups and, you know, those first people, because the cost, cost of opportunity is quite big. And if you hire someone who's not fit for purpose for that role, or, you know, maybe a little bit more junior, so they make, you know, mistakes, it can be costly, especially because, you know, things moving so quickly, people wearing multiple hats, and, you know, you just want to get that product out. Okay, any, any common, you know, mistakes or thread or challenges you faced when you, when you scale the teams? So I like this exercise of, you know, we are like 40 people in a well-oiled machine startup, we know what we're doing, you know, the board, the CEO went and raised money and we just got you know, for sake of argument, we just go like 9 million investment. In the next 12 months, we're going to go from 40, you know, to 140. That just changes, you know, everything, right? It's just totally different room. It's like, and you do mistakes in that rapid scale, you know, that, that change management is actually not, not easy. Anything from your experience to sort of shed light on some of the challenges and, you know, how you solve them?

So that's a very, very hard problem to solve for, um, and the reason it's a hard problem to solve for is because with the influx of that money, there's an expectation of an immediate impact to the business, and hiring people takes time. So the very first thing I would advise is, if you find yourself in that position, figure out which parts of your roadmap you can get a trusted partner to start working on, so you're not holding up delivery. Because whilst you go through this, um, scaling process of the teams, it will have an impact because you can be pulling people off to do interviews, right? So you need to make sure your delivery mechanism is working. Um, the next thing I would say is, um, technical people are technical. You'll get a mixture of people that are good, bad, um, exceptional as you go through the interview process. The key thing is, with all things being equal, um, go for the cultural fit and the people that fit with the values of the organization, because you're a lot better sacrificing slightly on technical ability if they can blend in with the team. Because, you know, I use the shopping trolley analogy. You get a shopping trolley with one wonky wheel and it just throws the whole shopping trolley off. You can't push it in a straight line. Um, same thing with team harmony. You get the wrong person in a team and the team will implode. You get the right person in the team and they become greater than the sum of their parts. And you always want to try and make them greater than the sum of their parts. But the other piece is, and I'm— and it's, it's, it's one that I'm not sure people do a lot of, is recognize the probation period is them trying out you as a company as much as you trying them out. And if they're not fitting in, fail fast. Um, if they're not the right individuals, they're not the right individuals. You know, it's unfortunate, it's not malicious on either side, but sometimes things just don't work out. Then make a decision, move on, and then try and find the, the individual that's right. I mean, you could spend ages trying to fit a square peg into a round hole, and that's opportunity time that's lost elsewhere.

Yeah, um, and energy as well. And just, yeah, Yeah, um, so sorry to, to kill your flow, by the way, Bobby. Just, um, no, it was like what you just said, it, it goes so deep with my experience that I just wanted to go like, yes, yes, yes! I mean, the, the social, uh, the soft and hard skills is, uh, is how I, um, by the way, I love the trolley analogy. Uh, soft and hard skills, that's how I look at it. Like when you have an interview, you have these soft skills, which like communication, social skills, ability to gel with other people, and how they're gonna fit the team, how the team will accept the individual. And then the hard skills, which is basically their coding capabilities where you absolutely want them to align to whatever you're looking for. That shouldn't be the decision matrix. Like you look at the soft ones because the hard skills are easy, easy to teach. As long as you have someone in the team who has the skills, any good professional will pick that up in, you know, 3 to 6 months. But the character traits of, of, of just that, that soft skills element, that, that character traits, if they don't fit, you know, your organization, or as you mentioned, that, that cultural vibe, that person is going to walk into your environment and he's just not meant to grow in that environment, and, uh, and it's just going to be trouble for everybody. And then if you recognize that, just cut the losses, you know. And again, yeah, it's not about you, it's not about individual, it's just not a match. And, um, yeah, which— yep, go, Bobby.

Typically, just, just on that, typically what I tend to do is, um, when I do hire technical people, is obviously there's a technical round, there's a tech test, um, a technical interview by my, my tech team, and then I do the team fit, the, the soft skills side of things. Um, and you know what, that I know HR people love to have set questionnaires that everybody follows, but it's not like that. I mean, you've got to take a look at the individuals and you've got to understand how they fit in. And I had one chap interview, um, with me many, many years ago, and I had quite a boisterous team, though, quite lively quite outgoing, and this, this person was very, very introverted, um, very, very quiet. Technically really, really good. And I had concerns, um, when the guys were chatting to me going, look, he's really, really good but really, really quiet, really kind of skittish a little bit. And then I, I walked in and I saw him and I, and I knew I wouldn't have a problem with him. And the reason I knew was after speaking to him and also when I saw him. Young, slight lad, bright blue hair. So I just started talking to him about his hair and he's like, "Look, I just like just expressing my individuality through my hair." It's like, you know what, great, because that tells me that you've got enough of a presence to express yourself like that. So in an environment where everybody's loud and engaging, you know, you can work with your headphones on, that's not a problem, but if you're prepared to just have something visibly that says, "I'm different, look at me," then you'll fit in perfectly with the rest of us here because we're all a bunch of misfits and we all get on really well. And another example, I had somebody that listed that he likes comic books in his CV, and so one of my interview questions was, "Right, tell me what your favorite comic book is and why?" And, um, you know, just understanding what it was that drove that individual to resonate with that particular comic book, and then using that to understand how to fit in with the rest of the team. So sometimes the HR questions, such as, you know, tell me about your values and everything else, they're great, but they don't really work all the time.

Yep, I like that. That's, um, that's a very You know, very skilled leadership skills, which you're defining, which, let's talk about that. But before we go to leadership, last one, how this approach of paying attention to all of that changes when you actually become a large organization? Because at, you know, at the very large scale, we're talking now, you know, around like 1,000 employees, you know, across the globe, you probably don't have that much time in being so due diligence around, you know, the the social skills, the cultural fits, or would you say that this still exists and that's the result of why people have like 5, 6 interviews when they're trying to join big organizations?

I think big organizations try to get around this by having multiple people interview. I mean, Amazon's famous for making sure that the interview process is done by people that you're never going to work with. So they look for the right fit as well as the technical skills, and then you place into a team. But the other piece to this as well is, I think it's actually okay for it to differ from location to location. So, you know, one organization, I had a team in Edinburgh and a team in London. The two cultures are going to be different because they're completely different places. Similarly, where I've had offshore teams and teams in the States, teams in Romania, teams in, in London. I don't expect them to have the same culture. I expect them to have the culture that's appropriate and fit for the environment they're in. And so as you grow in scale, you're reliant more and more on the people that you've got in charge of those places to ensure that what they do enhances the culture and doesn't break it.

Yeah, I like that. I mean, the cultural differences is, is a big oversight. It's, it's a lot, it's a blinder to a lot of leaders where, especially now with the, with the remote, you know, and offshore business modules where you get very distinct cultures like, you know, India and London, or, you know, Eastern Europe and London, where, you know, they perceive leadership in different ways, they perceive feedback in different ways, they communicate in different ways. Some are, you know, a lot more fragile, some are very to the point, you know, almost to an edge of, you know, feeling too aggressive. And balancing all that out when you actually have a multicultural team is a, you know, it's a big challenge, you know, for a leader of that team. Which leads me to my question: how do you solve the challenge of having a team in India and let's say, you know, a team in London and having totally different time zones.

The first question is how much do they need to interact with each other? Are they working on the same thing? Is it a team extension or are they separate teams? Is it the same team working on separate things?

Let's say it's the same team. Let's— no, let's say it's two teams. Let's say we have one local which is London and we have one local which is India. So two different teams but working on the same product.

That's, that's the recipe for disaster. And I laugh when I say that. The, so the biggest challenge you've got is when you've got two disparate teams geographically dispersed, or to be honest with you, when I say that, it could even be geographically dispersed on different floors of the same building, working on the same codebase, working on the same problem. You're going to come into issues. Now, the— it's become a lot more accepted for people to be working on similar code bases and being geographically dispersed since people have started to work remotely a lot more. So you factor in that, you just need to be careful about code merging and everything else. And you take that off the table and assume that that's standardized, right? Um, then you come on to the cultural differences. The time zone, I'm— I don't see as being that much of an issue provided there's some overlap and there's some time for the team to get together and start talking. I've worked in some organizations where they're adamant that they want all people to work the same time zone, which I think is just wrong. Um, What's the problem you're trying to solve there? If it's collaboration between the different units and they have to collaborate to that extent, you have to question whether or not it makes sense for then the team to be split across different time zones rather than forcing people to work to different, different, uh, times. Um, I think the biggest, biggest, biggest issue you find when you're trying to get local and remote teams working together are the cultural differences and understanding what leads to them. And, um, you know, if I take a look at Romania, when we started to do stuff in Romania, and this was 15 years ago, um, Romania was very, very hierarchical at the outset, you know, whoever was in charge was right. And, you know, as it's developed more and more, more of the challenge that you get a lot more in the UK has started to come to the fore, which is great, and that's exactly what you want. But understanding some of the historical reasons why that was the case is key to being successful, certainly at the outset, and, and helping people realize that challenge is normal, is accepted. Now again, you take a look at India, again very hierarchical. Um, how do you ensure that when you're working with people in India that, um, again it's very, very clear that you're expecting challenge, you're expecting pushback, you're expecting, uh, people to come with their opinions? You know, the hierarchy is there from the reporting line, not necessarily because only people at the top have got good ideas. Good ideas come from anywhere in the business, and you are better when you leverage the wisdom of the masses, certainly when you're dealing with some of the technical problems, challenges.

100%.

And if it's a case of the majority of the work is being done offshore, uh, with oversight onshore, then it's making sure that those guys are plugged into what's being done and understand how it's being done and, and can drive those conversations.

So when you look at the leadership of the teams, um, let's, let's just define it. You have your, um, trust and inspire a leader, which is, you know, very, very common way of leading, like in UK and, and in the West. And you have this, you know, command and control, which is a lot more you know, in, in like Europe and Eastern Europe, you know, we're talking like, you know, Bulgaria, Ukraine, and, and Russia. Um, what happens, and you know, maybe you have some use cases, when you take a command and control leader and you put it in a team which expects to be inspired and, and trusted? Recipe for disaster.

Yeah, it's, uh, it's a challenge, and it really comes down to the individual. When I look at people, I, I classify them as— I call it two Cs. I don't know whether it's a formal framework, it's what I use. And the two Cs I look at are capability and capacity. So if I, if I want an outcome, and I believe somebody could be possible of delivering that outcome? Do they have the capability of changing their behaviors, changing their style in order to get to the right outcome? And if they do, do they have the capacity for doing it? So if they have the capability but not the capacity, you free up the capacity. If they have the capacity but not the capability, then it's a simple binary problem. Do I think the, the capability can be developed, in which case develop the hell out of them. Because guess what? You develop people, they'll grow, they'll, they'll add benefit. If they don't have the, um, capability of being developed, then it becomes a different scenario. Then you've probably got the wrong person in the wrong role. And I think that's the same irrespective of whether you're taking somebody from a command and control environment and bringing them into a more inspire and and lead environment, they have to have demonstrated that they've got the capability of doing that before you trust them with something like that. Because again, this comes back down to the squeaky wheel. Um, you put the wrong person in the wrong role, the ripple effects will be massive and will have an impact not just on your area but potentially across the rest of the business as well.

Yeah, I love, love that, love that, Bobby. Exactly. Exactly that, which leads to my next question. How important is a leader to the team and the team's performance? And to give you a context, I have this concept which I call lifetime value of employee, which effectively starts before you even, you know, hire the person. Like, you interviewing someone is you spending time on that person because because, you know, it's an hour, it's emails and whatnot. So, so that value starts, you know, very, very early. And then you hire the person, he comes in, and, you know, they, they're likely going to be a negative value or net negative because they're going to be just onboarding, learning, and whatnot. And eventually, you know, you're looking at that value growing and as high as it can go, right? So from my perspective, when you, when you have a team lead or anyone leading a team, you know, their job is to make sure that everyone you know, has that value as high as, as he can go. And if you put a wrong leader in a team and team just doesn't respond to it, you know, the value diminishes because they just, you know, become disengaged, you know, maybe they don't want to do this, and, you know, and all other issues. So value goes down. And you have 8 people, you know, that's multiple by 8. So, you know, if you have an average per person value, let's say 5, you have 8 people, that's 40. If you have a good leader that you know, average goes to 7, suddenly the whole team, you know, output increases, right? So my perspective is a right leader for a team is pretty much crucial when it comes to high-performing teams. What's your take on that?

Absolutely. I think the— so there's a couple of things. There's, um, the leader is ultimately accountable for the output of the team, the division, whatever it is underneath them. There are different levers they can move to affect the output, but ultimately they're accountable. For me, the right leader is also transparent in how they operate. They build a level of trust with the people in their teams, and more importantly, they trust the people in their teams. So there's no need for micromanagement. You've hired good people to do good work. You don't need to be looking over their shoulder unless they're not performing, but that's a different set of problems. Um, if you've got somebody that doesn't exhibit those traits, then that will start to set a different sort of culture into the environment. Um, you need to know that you can go to to the leader with good news and they'll be ecstatic. You need to know that they'll go with bad news. And whilst nobody likes delivering bad news, um, it's how is that dealt with? How, how does, uh, the team and the leader then pull together to, to arrive at a solution? How do they— how does the leader then work to make sure the team's got air cover to do what needs to be done, rather than ending up in a finger-pointing exercise or there being a loss of faith across the wider business as a consequence. I mean, things happen, right? If software delivery was easy, everybody would be doing it. Every project would run on time. I mean, not just software projects, any large-scale projects. Look at HS2. Over time, over budget, right? But it's a highly complex piece of engineering. Um, it's not like just putting together, um, a 3-year-old Lego set with instructions, you know. Things come out of left field. It's, it's, I think it's incumbent on leaders, and this is, is irrespective of whether they're IT or not, to be able to engender an environment where you can have the difficult conversations. If need be, you can have robust discussions behind closed doors where you can disagree with each other inside the room, but once you come out the room, you're aligned and you're all focusing on a way forward.

I love that. Do you think leadership style changes with the size of our organization? So come back to our you know, kickoff theme of scale-ups versus startups. If I'm a leader of a startup which is, you know, 40 people, and I'm a leader, you know, of— I mean, it's the same 8 people, but right, just come back to the fact that one person couldn't, you know, couldn't really manage, lead more than 8 people. So it's always going to be a hierarchy. But, you know, let's imagine you're like head of engineering or a CTO. And it's a startup, so you have 40 people underneath you, and then, you know, you get the money, it grows, and it's now 150. Do you think your style around leadership has to evolve in some way?

It inevitably does with size and scale. Now, that's not to say your— the core way you operate and the core principles and values you hold change. I mean, the transparency, the honesty, the trust, that's the same irrespective. Um, yeah, what ends up being sacrificed sadly is time, right? And individual one-on-one time, because as you grow and scale, you don't necessarily get to spend the time with each and every individual as you did when you were a smaller stage organization. And you know, I've managed teams that are as small as 5 and as large as 150. Um, now, um, span of control changes. The thing that changes massively is communication style. It's not feasible for you to sit down and have a chat with everybody, so you become more and more reliant on communication tools, on all-hands meetings and everything else. But then the downfall of the all-hands meetings is that typically, and let's face it, developers typically tend to be more of the shy, introverted types and don't like speaking in groups. You know, there's exceptions, as there always are, but you don't tend to get as much feedback in large-scale group all-hands sessions as you would in one-on-one sessions. A guy I used to work with did this fantastic thing, which I've shamelessly stolen, which is when you get to an organization of a certain size and you no longer can do the one-on-ones with everybody, he would have open hours every week between, I think it was 10 and 12 on a Wednesday, where anybody could come and grab him for a coffee and have a chat with him. Doesn't matter what level of the organization you were, you could just go grab a coffee. And the commitment was every Wednesday between 10 and 12, there wouldn't be any meetings or anything else that came in that, um, that would, uh, take that away. So people could just come up and have a chat, chat about the football at the weekend if they wanted to, but at least it gave them that opportunity to have one-on-one time. And I think that's massively important. And as you, as you grow and as your teams grow, I think the key thing is to ensure that you remain visible.

I, I like that 10 to 12 situation. I would be interested to see if people are actually using it, you know, because like when you think about introverted personalities and, you know, maybe if the person comes from a position of influence like CTO in a big organization, I do see some people potentially being like, you know, not comfortable to sort of go in and ask for that time instead of being given the time. But that being said, I do very similar, which is, which is lunch. But that's, that's because I, I go to office, you know, I still do remote, but I, I go a couple of days and I always try to fill my lunch, but with just, just someone. And I just go across the organization, I'm like, you know what, we work in this area right now, you know, let's just have a lunch together. You just share food and you, you know, you discuss everything. It does help to cover more base when you have a lot more people, uh, reporting directly to you. Sometimes you don't see them like at all. And, you know, and they report in one shape or another. So that's a— yeah, that's a good shout. So in the spirit of the show, Bobby, we have this question. From your point of view, what is the most important, uh, factor for a tech growth?

Focus on what is the problem you're trying to solve, and, um, as part of that, have the awareness to understand whether you're going to be building something extensible and scalable, or whether you're deliberately going into what I call a coding cul-de-sac, which is something you know is going to be disposable, but you have to just get it to market as soon as possible. And I think the reason that's key is, uh, it lets you have those discussions up front with the stakeholders around the business to say, look, you want feature X, um, and it needs to be in front of the market in a really short time frame. I can do it and we can get it out there, but know that if I do it and I do it in that time frame, it cannot be aligned to the future architecture. Um, we're making a decision now that what we're doing, because the market need is so, uh, time-sensitive, that we will take the time to do this right after the fact. And that presents a different set of discussions versus just doing it and then 6 months, a year, 2 years down the line having to go, hold on, what do you mean I need investment to redo that piece of work you did before? Well, no, you did it before. Why do I need to do it again? And I think this comes back to that transparency. And as IT leaders, it's incumbent on us to have those discussions. You know, if you need to build a garden shed, build a garden shed. Don't build a cathedral, but build the best garden shed you can in the timescale. If you can't and you have to just get flat pack, fine, put flat pack up, but then have a very clear discussion that this is only going to last for 6 months to a year, and then we need to rebuild.

Excellent answer. Thanks, Bobby. I really enjoyed that. It's a good conversation. Before we close, Last one, a person you personally know which would be good for the show, as in, you know, invite to the show.

Yeah, there's a chap I know, former architect of Betfair called Asher Glynn. I think he would be a very, very interesting guy to have on the show. He's worked across multiple sectors and he's doing some interesting things with a startup of his own. He's done lots of advisory work, lots of consultancy work, so I think he'd have a unique take on things, especially, uh, at a low-level technical perspective.

Awesome, we'll try to get him on the show. Thanks for name-dropping, by the way. So that was lovely, Bobby. Thank you for coming, joining, sharing your expertise. You know, we went through so many topics, you know, I'm 100% sure people will enjoy listening to this. Any last words?

It's been a pleasure and I've enjoyed the session. And if people are interested, feel free to hit me up on LinkedIn. More than happy to chat. Yep.

Cheers, Bobby.