SPEAKER_01 0:00

I've been in the industry for 25 years or so now and nothing has changed the job so much as this. My team are mostly not writing any code anymore. Um the AIs are AI agents are writing the code for them.

SPEAKER_00 0:11

I've got a computer science degree and and now I'm gonna let an AI agent do this for me. It it's not real.

SPEAKER_01 0:18

This is kind of a bit authoritarian. This is a bit non-negotiable, but we are going to do this. Our engineers are becoming much more like coaches. They are training and teaching the AI engineers. Should people be worried? Maybe.

SPEAKER_00 0:36

Today on On the Pulse, we're joined by someone who has spent over 25 years in software and engineering and who is right now at the sharp end of one of the most important conversations in technology. Matt Wetton is Chief Technology Officer at Acquired.com, part of the Quint Group, a bootstrapped fintech and payments business building real, profitable products in a world obsessed with venture capital and hyper growth. Across his career, Matt has led engineering teams at scale, built platforms in regulated financial services environments, and held CTO roles at businesses including Oakbrook and Salary Finance. He's also a CTO craft ambassador, one of the most senior and active voices in the UK CTO community. What's particularly interesting about Matt's perspective is that he's made a deliberate choice to move away from VC and PC backed world, and he's got strong considered views on why. Today, we're going to cover three things. First, what it actually means to lead engineering in a bootstrap business versus a venture or private equity backed environment and why that choice matters more than most people realise. And second, how Matt's team has embraced AI not just as a productivity tool, but as something that is fundamentally reshaping what engineering leadership looks like. And third, what all of this means for the shape of the engineering career and what people in products and technology need to do right now to stay relevant. Matt, welcome to the podcast. So I think let's start at the top, really, um, and particularly honing in on that VCP move, because you came up in VC and PE, right?

SPEAKER_01 2:32

Yeah, that's right. Yeah. I mean, I spent um particularly in my CTO years, I was working at um Obruk Finance and um in salary finance, both part of the Blenham Chelcott group, who is a sort of venture builder group, which is very much somewhere between like a family house PE and venture capital type arrangement. Um so there's a lot of a lot of finance involved, a lot of money moving around in there. Um and then yeah, made the decision in 2023 to move to acquired part of the Quint Group, and the Quinn Group's very much more a bootstrapped startup, so or not startup, but bootstrapped environment with um several businesses built in the financial services sector, um, using a very different model, actually, which um on the on the face of it people wouldn't recognise, but actually makes quite a lot of difference um as you get into it.

SPEAKER_00 3:17

So it's not the usual trajectory or career choice people will typically stay in that PE, VC world. What kind of led you to making that decision?

SPEAKER_01 3:29

I mean, there's lots of little things, I think, over the years. Um, but I guess what you start to see certain patterns when you work in like a larger in like a more VC type world or even a PE type world, um, with sort of boom and bust cycles. Um, I think that you will you you will grow very almost uncomfortably fast at times. Um and that when I say grow, I mean both in terms of like the revenue in the business, which I think everybody would like to grow as fast as possible in that kind of space, but that often means, um particularly as you're developing a product, you're having to grow the engineering team very, very quickly. And it's very difficult to grow an engineering team quickly. Um obviously a lot of that's changing nowadays with AI and the the way you would tackle that. Um, but there was still like a drive to grow very quickly, to deliver very quickly and to get things over the line in order to sort of get the revenue moving. Um, often that meant going into sort of a deep J curve in terms of the amount of the profitability of the business and when the economy struggles or when there's something going on in the economy that can then turn around and and have a sort of, I guess, a negative impact on the business, or it can mean that you end up having to do a lot of layoffs or or or you're working through kind of cost-cutting exercises. Um, I think it's quite just quite normal in the VC world. Um, I think the the the PE world is slightly different. I think they will go through a very strategic growth period and then go through a very strategic um cost-cutting period as well. But in both cases, you have this same sort of big investment period followed by quite a painful period. Um, and to some extent, you know, the the big investment period, you're more often fighting for growth over anything else, um, rather than necessarily building what I would call like a good going concern of a business.

SPEAKER_00 5:08

So like when you're in when you're CTO in one of those businesses, you do you know that that cycle's gonna happen, or do you do you go into it thinking that it's may maybe we can hold this sort of headcount? How does that affect how you lead and how you build?

SPEAKER_01 5:22

Yeah, so I I mean I would certainly say you you probably don't know that that's gonna happen, um at least in your early uh in the early part of your career, um, for sure. You can definitely see you might you may have some inkling that that's gonna happen, and it doesn't always happen either. Sometimes there is this, you know, forever enormous growth, kind of unicorn growth that can happen. But in the in the reality of the the kind of economy in the the environment we work in, um there's probably more losers than winners, right? So there's gonna be companies that also that doesn't mean that they necessarily don't succeed either. It means that they maybe just don't turn into the unicorns. You know, there's only a handful of the unicorns in in reality. So I don't think not for me, I don't think you I certainly wouldn't have recognised it immediately. Um I just noticed that it was happening. And and some of it could be attached to like what's going on in the economy at the time. So obviously the last few years have been quite tumultuous. Um in terms of what it does to you leading, I think I think probably you get into you can get into a bit of a mindset that you just need to focus on growth and adding people, um, getting, you know, growing the size of the the technology effort that will accelerate things and moving that at all almost not at all costs, but that becomes a huge focus of your job. Um, I think for me personally, I found that it um took me away from wanting to work out um spending time on what makes the team more effective. It was definitely an easier metric to talk or to to have a conversation with investors about is like the size of the team as opposed to the efficacy of the team. Um it's very hard to describe the efficacy of an engineering team because there's no simple productivity metrics you can attach to it. None that are real, none that really, really, truly honestly say this is how effective the team is, apart from potentially the success of the business and the products that we're generating or creating. Um so I I think you you tend to you can quite often end up being that's all of your focus is is growing and retaining people, um, as opposed to becoming really effective. And that that was something that I certainly didn't enjoy that much, or at least I got into it, I I learned to realize that that wasn't how I wanted to spend my days working. And I think I realized that where I had most of my joy working was when I worked with a relatively small team of highly effective people that I knew quite well personally, um, that I was quite intimate's probably not exactly the right word I would always use the word, but it's um having a team that I know very well ultimately, that know me, that I have a friendly relationship with, um, and I know who's good at what, and I know um what we can do to move the dial. I think once you get to a certain scale of team, it's very, very difficult to do that. I think as well, you're you also kind of get this sense, or at least I did, that um you lose a level of like efficiency and efficacy the bigger you get. It's like a it's like a curve that gets sort of starts to flatten off. You know, if you get into a team size of say a hundred people, um, which I was I I was managing over a hundred people at one point in time, um you just can't be that close to, you know, actually, if we if if we could make this part of the team twice as effective, you'd get a lot more benefit than making the team twice as big. Um, so so I think some of those kind of things is what I missed from from working in a smaller team, and what I I sort of wanted to aim more towards was actually how do we build smaller but super efficient teams that can be really effective at what they do. And actually some of the other noise that we then have in engineering maybe goes away. And I I think we've I think both us as engineering leaders over the years and probably the environment that we work in as well, I don't think there's anybody to blame for it, um, have generated a lot of like noise and signals and things in that environment of engineering and and creating things um that get in the way more than they help.

SPEAKER_00 9:09

Um was there was there a specific moment where you had like this realization of okay, like I don't want to do this again. Oh, that there's got to be something different out there.

SPEAKER_01 9:21

Um, I mean, I think there was probably a series of them. I think I think honestly, um being in a position to have to do like a my build a build a team that I thought was very effective at one one of my prior employments, um, then have to basically let a lot of that team go after painfully building the team over a period of years, um, was definitely something that did impact me emotionally. It was something that I felt very deep inside. Um and but that didn't necessarily do it at that point in time. I think that that was just one of the signals that built that was I think there was I I started to realise as we were running teams, even before that, that um, you know, we were having to hire um and it wasn't that we were looking for bums on seats, so to speak. We wanted to get the right people, um, but we also knew that our roadmap was attached to getting the right people in the door. Um, and it was really hard to get the right people. And I think you know, you start to realize some of the things we were doing um with like the larger teams, sorry, just bang that. Um, with the larger teams would be you you would question yourself and think like, look, look, we could definitely do this more effectively with a smaller team. You could just clearly see that actually, and then and then there was a few small initiatives that we ran, and because of the sensitive nature of them, I sort of created a different environment for those initiatives um where I would take a smaller team, maybe just two people, maybe two people and myself sort of consulting on a daily basis. And we managed to move the needle massively in a very short period of time. And I probably did a series of those and increased those over the years and realized actually this different model of working um of focusing on the problem in a different way, removing some of the noise, making sure that the people, the people that we're working with are properly empowered and that they also take that empowerment and use it as agency. Um created like this sort of massively, I hate to use the sort of 10x effect because it's it sounds sort of a bit trite, um, but you would see massive, massively more effective teams with smaller, smaller sizes of teams than you would do in the the other environment. So I think there's probably a couple of things in there, but they were the two big things that really always resonate with me.

SPEAKER_00 11:29

So surely that's music to a PE or VC's ears, right? I can do more with less, and we don't have to spend as much money. Do you so what what what what was kind of the blocker or why have people not why are we not seeing a trend more in that direction? Perhaps we are now.

SPEAKER_01 11:44

Yeah, I mean, I definitely think we are now, and I think we we saw it in pockets. Um I think like you would see certain whether whether they're popular companies or not, um, certain companies that were famed for sort of running or have become famed for running, you know, massively successful um organizations with very small teams, whether it's like um the kind of model that um like Basecamp um ran that's like not a massive team, um you know, probably bigger than 20 people maybe, but not a massive team. Um even Telegram, very small team, but very effective. Um some of those kind of companies have done that and would do that. Um I think the reason why not is because it what it also probably doesn't necessarily get you all the time is is that that massive moonshot. So I like you probably not you probably got to be a little bit more reasonable and realistic about where the end goal is. Um maybe that's part of it. I think as well, it's I think in order to do it, you've got to put quite a lot of trust in your engineering team. Um, and I think it's harsh to say, but I think that's actually quite hard to do in a in an environment where there's not many engineers. So I'm one probably not sorry, sorry, there's not many engineers in like the true sort of investment and leadership space. Yeah, I think that you know, engineering is one of those disciplines that's like quite difficult to grasp. It seems like, or it could have seemed like, you know, black magic that somebody's doing in a corner somewhere. Um, you get these guys and they disappear into a box and write some code um and nobody knows really what they're doing, and they seem to moan about a lot of stuff because engineers do moan about a lot of stuff, myself included. Um, and I think that lack of understanding kind of gets you to a point where it's not very trusted. So there's a lot of noise that's generated around it. Um, there's a lot of decisions that get blocked, um, a lot, or not blocked, but can get slowed down and not made quickly, which will slow down the whole effort in general. Um, and I think a lot of this control environment that gets put around it sometimes ultimately is to give comfort that things are going in the right direction, but they actually harm the overall, the overall output. I think you've got to have like a really good, you've got to have the right engineers and be able to trust the engineers to do that job. And I think that's kind of hot, it's harsh, but I think that it's hard to get to that in a lot of these environments.

SPEAKER_00 14:03

That okay. So that versus scale. Do you think there's an I can't it makes me think of my industry a little bit because you know you know I came from a big business, global business. Um, and then obviously you have been building sort with a lean, highly profitable team. Um, and I would imagine there's a lot of synergy. Do you think and and what we always talk about is headcount vanity? Like we don't want to just grow for headcount vanity. Obviously, there's nuance, but do you think there's an element of that in in the ways of thinking?

SPEAKER_01 14:35

Yeah, it's a great term. I've not I've not heard that one before, actually, headcount vanity, but I would I'll definitely tell you that one and use it myself. But I think there's definitely an element of that, um, like a vanity metric, you know, it's sort of it's a measure that's easy to point at, it's easy to understand. There's definitely something about um, and I had to do a lot of this when you're sort of like making um you're making decks and presentations and you finding the story to tell the investors so that they understand what's going on. Um, but you often have to reduce a lot of nuance down to just simple things, which are not not that the investors are simple because they're not the very, very clever people, um, but you you've got to reduce it down to kind of like number of resources, types of resources, um, what that, you know, how what the timeline's gonna be around that. And really, once it's pretty much down to timeline, resources, and cost, and it simplifies it so much down that you you kind of lose all of the nuance in it. Um and and and that's almost unavoidable at times. But there is definitely there is there can definitely be a tendency to want to just hire more people. Like I think it's partially vanity. I think it's partially like it just feels like it will make it feel it'll make things better, it feels like it will make you go quicker, it feels like it'll reduce some of the stress or some of the uncertainty. Um, but often it's not true. I think a lot of that is it's it's that thing where it just feels like oh, if we had another person to do that extra thing, but it just never pans out that way. It never quite works like that. You I mean, if it's the right person and you need that right person, then yeah. But if you just add 10, 20 people that aren't the right person, um, or even just 10, 20 people all in one go, then you're gonna lose a whole bunch of other stuff. So yeah, I I definitely think there's an element of vanity in there, but I I I don't think it's probably like m anybody's meaning to do it that way. I don't think anybody's thinking, oh, we need to get to that number. Um, but I think it it is a little like a vanity metric, is a metric that actually isn't it isn't helpful, you know.

SPEAKER_00 16:29

I I'd imagine it's not helpful also when it comes to you know that those layoffs come. Yeah. And the damage that that does longer term for the people that are left behind or still there waving the flag, just knowing having gone through that and then bringing more people into that, knowing it's happened before, I would imagine can create its own issues in itself.

SPEAKER_01 16:49

Yeah, I mean, it certainly is um hard to do that right, or hot maybe that's not a fair way of saying it, but it's it's it's it's not a nice thing to have to do. And I think that sometimes it's just n necessity that causes it. And I've certainly seen that. And and I think that in those cases, actually, what I found was um the team that are left understood. And I think that when there's an authentic and honest explanation like that, I think the team really gets it actually out of I I actually think this is one one of my reflections of all of those times was we can often, particularly in executive positions, um, like not give enough um I don't want to say respect, but like like we could give give enough stock to people's ability to um understand the truth of the situation and to actually respond to it well. So I have seen that, but I think there are times where it's maybe not as defensible, not as easy to appreciate, and not as easy to swallow. And certainly the the what happens after that is then gonna have like a much bigger impact. It's definitely gonna be culturally quite significant.

SPEAKER_00 17:54

The horror stories of the cold emails out the blue. I mean, obviously, I I would can't imagine you're ever part of anything like that, but it's it blows my mind just to hear those stories in today's day and age.

SPEAKER_01 18:03

I've heard some pretty awful stories like that of yeah, I mean lots, lots of them. I've never been involved in any that have been that harsh, if I'm really honest. But most of the ones which I've been involved in um have been handled very well or as well as possibly could um be handled. Um, but yeah, still never nice, and it's such a big impact to people's lives.

SPEAKER_00 18:24

Um so that decision then to move to a bootstrap business. What talk talk talk us through some of the mm fundamental differences that you notice straight away um compared to what you'd come from?

SPEAKER_01 18:39

Yeah, I mean, for sure. Uh like the I I guess like one of the ones um is um the relationship to the owners of the business changes things fundamentally straight away. Like you you I find myself very much more connected um to the owners of the business in in acquired and in the quint group, um, or the owner of the business in in our case. Um you can have a much more personal relationship and see where he's coming from and understand what his perspective is on things. Um I think that that can be really, really useful and really helpful. So I I I enjoy that personally of being sort of that close to the to the metal, if you like, as we'd would have said in the old sort of um data center days. Um but I think some of the other things is is the way that growth is thought about and the way you have to adjust your mindset to think about that growth. Um it is a strange one as well, because it doesn't necessarily mean like like you don't necessarily have the same money or the same boom cycles. Um I think you do tend to go what I do find is you do tend to go on a like what I would call almost like a parabola growth trajectory where you'll go through periods of growth where you'll probably go into a little bit of a loss. Um, and then you you just have to know that there's got to come a point where there's got to be a correction point, and we can't go into these super deep J curves where you're gonna be in, you know, multi-million or tens of millions of losses for the next five years. They're just they're just not gonna happen. Like there's not many people out there who can sustain that kind of cash burn. Um, so you tend to go through periods where you have to keep correcting. And I think what that does is it makes you ask those questions like, do we need to grow as quickly? Can we be more effective? And I think actually I'm a great believer in um I you know, I've always I would have always said, you know, don't pre-optimize, don't optimize any system until you need to optimize it. But check in sometimes, definitely, and optimise when you do need to do it as well, and optimise when you've got an opportunity to do it for sure. That's both with like a program assistant that you're building. I'm a lot of the the the sort of um similes that I'll make in my head end up being very engineering-led because I was I wasn't an engineer still, I would still classify myself as an engineer. Um, but you know, like you can make small corrections now that are much easier than solving those things later on. Um, I've certainly been involved in businesses where, you know, some earlier interventions, um, fixing some certain bugs earlier on, which probably weren't critical at that point in time, would be a lot easier than fixing them five years down the line when it's costing tens of millions of pounds, kind of thing. Um, and I think this is similar in this case. I think when you're building the business, taking those moments to go, okay, look, let's not keep growing. Let's actually work out how do we optimize ourselves, let's work out how do we um be more effective, more efficient. Um, let's cut out the noise where we can. And I think that's something that we don't do often enough. Like, you know, this there's so much noise and rubbish that you end up doing in business, and we all want to stay focused. Things like OKRs we will introduce to stay focused, but without having the harsh thing of what are we going to get rid of? It's just more. It's just more things to add on top of the existing noise. So actually it forces you to have that thought process, which is what do we get rid of? What do we cut? What do we keep? What do we focus on? Um, what can we do to make this more effective and more efficient? Um, what's getting in our way? Um, and and I think these are really good practices to have. So you can kind of get into almost like a certain cycle where you'll you'll be you'll grow for a period, then you can pause and go, right, let's. Let's correct some of the things that have gone wrong during that growth or some of the things that have happened during that period. Let's work out what were, what didn't. Actually, it's very much like if you take it back to a sprint cycle where you'll do a retro, that's a much smaller cycle, but it's another cycle which you'll go through and say, okay, we've got to the end of that cycle. How did it go? What can we improve? What can we take away? What do we need to add? And then you do another cycle. So you kind of, it's a very different cadence. Um, but I think you get an opportunity to have that kind of cycle in there, which you wouldn't really think of. You would just think, oh, and it and I won't lie, sometimes it can be frustrating when you have to kind of like stop the growth, you know, stop adding the people, maybe when you think it's really critical. Um, but actually, some of the most the things I've been proudest of, I guess, in my head um in my career have been when have we been forced into that difficult situation where actually we can't just throw money at the problem, how do we solve it creatively? And you'd be amazed at the things that you will do in those periods, um, much more so than potentially you would do if you can just keep throwing money at it.

SPEAKER_00 22:57

And that's challenging you as a leader and your skill set absolutely to to start thinking in that way. I guess it is there is there a is there a version of this that neither is right or wrong, right? It's just more aligned to what you what you want to be part of and how you want to develop in terms of your own career.

SPEAKER_01 23:16

I 100%. Like I I don't think there's any rights or wrongs in this, they're just different. Um I wouldn't even say to myself that I will always, you know, I I wouldn't necessarily say I would always be in a um a bootstrap firm. I'm enjoying doing that at the moment. Um I wouldn't write off going another direction, or if if if in one of these firms we wanted to take on like a significant investment in order to boost growth, I think that that would be a it could be a sensible decision to make at a point in time.

SPEAKER_00 23:40

And what a great choice you would potentially be. Um this isn't a job interview or anything like that, but no, but the skill set that you picked up, you've spent the money and you've also worked with probably limited, more limited budgets. That creativity mixed in with a VCP, like we said, like I said earlier, it's probably exactly what's needed. And to have been there, done it, and then implement that somewhere else would be a great skill set to acquire, right?

SPEAKER_01 24:06

Yeah, I mean, I I would hope so. You know, I mean, it's kind of I mean, I definitely think that I it's something that I will bring to the table in that sense. I mean, there's a lot of others that do, but being able to sort of switch and think about those things, being able to face into those kind of like those cost-constricted moments and see that as a as a leadership challenge and that there's something interesting in that and sometimes something exciting. Sometimes they're the best periods, times that you'll work for sure.

SPEAKER_00 24:30

So something that really interested me when we were speaking previously is how, and it might be linked with the the budget stuff, it also might be linked with just where the world is going right now. But you you guys have pretty much gone all in on AI.

SPEAKER_01 24:43

Yeah, from an engineering perspective, and we'll do it more across the board. Well, in not just in engineering, but that's one of the biggest areas where we've gone really deep in in AI. Um, I mean, it certainly links to the cost aspect of it, albeit I think there's probably a lot more turmoil in that than we all think. We all think. I mean, a lot a lot of people probably do believe that now as well, but there's you know a lot of movement in the cost landscape and how that looks from an AI perspective. Um, but definitely what I have found with it is if you're running sort of a small effective team and you have that kind of relationship that I have like with my team at the moment, um actually introducing these AI practices is it it can be like a net positive to the team. Everybody's really excited about it. Like I certainly feel very fortunate that my team at the moment has picked up and ran with this with a lot of um gusto and excitement and are really driving it forward. So we've we've gone really, really heavily into it um and and really want to make that a central part of the work that we do.

SPEAKER_00 25:41

Yeah, it's worth headlining. It's not that you've kind of got rid of everyone and you're now working with pure agentic software engineers, right? It's but maybe help help help me to understand like what then does that impracticality look like in terms of how you're utilizing it.

SPEAKER_01 25:56

Yeah, I mean it's it's I I I mean I think we'll go through multiple phases of evolution with it. Um I think like when we were talking before, like the big focus for me um when we introduced this um with the team was things are moving so quickly that the best thing that we can do is become kind of an ad adapt adaptability machine. Like we we have to become very, very quick at learning and adapting and changing because I think that um the world of AI and the tools that we're getting access to and how they're evolving, uh it changes weekly at the moment. So we need to be able to move very quickly. That's the first point. In terms of just practicalities, though, lots of fundamental areas of the job are just different. Like my team are mostly not writing any code anymore. Um, the AIs are AI agents are writing the code for them. Um, you know, in some areas of the team, depending on where we are on that kind of evolutionary curve, some people are running multiple AI agents doing lots of different things at the same time. Um, I think what's interesting is some of the sort of conventional wisdoms of things that we know aren't good, um, we're we're starting to run into now because it's just a practical way to work, which is we know that switching tasks or task switching is not a good thing. Um, when you context switch between tasks, um you you tend to like lose time and it's hard to concentrate and know where you are. Actually, it's quite stressful as well. Um, but with the way that age entor at the moment and your AI agents, um uh your AI coding agents, you tend to have to trigger off multiple at a time, maybe and have them running on different things, which you may then need to come and inspect or intervene at different points in time. So you you're kind of forced into task switching as well, which is one of the sort of challenges at the minute. Um, but even down to like, you know, we'll get things now where um some other examples that aren't just like the simple, it's writing all the code for us, which it is. We are still getting in and doing some of the code. We'll still review things, we still have to coach it and course correct it. Um but to me, it feels much more like our engineers are becoming much more like coaches. They are training and teaching the AI engineers, they're keeping it on track and pulling it back where it's taking the wrong direction, um, spotting it early enough so that it doesn't go too far, and then training other AIs on how to sort of review that work, how to consume that work. Um, so as you see, our almost our uh engineers almost all being leaders of AI engineering teams, um, which is um a weird kind of like think place to end up in, because I think at one point in time, you know, you you do find that a lot of engineers will want to step up into leadership roles. Um and they'll give it a go and then realize, you know what, this isn't for me because of some of that context switching that you get in the more leadership roles. Um, I kind of think it's almost inevitable that that's kind of what this starts to look like. But even other things that we'll be doing in there. So, you know, right now we won't be necessarily, you know, if an issue comes in through JIRA, for example, um, we'll just be telling the telling the AI, I'll, you know, have a look at this issue and diagnose it, maybe prepare a fix for it if you know what it is, and then we'll look at it and see if you've you've got it right, or we'll I'll sit and watch you do it and see if you're getting it right. Um, so it's doing everything, even the earlier stuff in the ALM cycle. It'll even, you know, prepare all the PRs for us and write out the PRs and and even review the PRs. So there's lots of things that we are that are changing in that cycle. Um, some of the great stuff recently has just been doing doing data analysis for us as well. We have a great tool that we use um at Acquired, which um hooks into our data warehouse and can kind of like give everybody access to sort of like um natural language data analysis through Slack. Um so everybody's almost got like their own little analysts working for them. And and we're not just talking about it doing simple queries, it can produce PDF analytics, it can go into some quite some depth. So so many aspects of the engineering game across data and across software engineering are changing. I think where I I'm kind of excited about, but also can't see as much evolution in there at the moment. Uh it's definitely coming, but is in around sort of test engineering and testing. I think there's a huge opportunity for AI in that space that um looks most, I don't think it's completely untapped at the moment, but it's, you know, AI writing automated tests, fine, it can do that, that's great at that, it can write code. It's the you know, writing code is the killer use case for it. But um, I actually think, you know, doing things like more AI exploratory testing, AI smoke testing, doing having AIs being able to sort of do stuff a little bit more like a human would, where they're going to do things that aren't expected and aren't necessarily planned, um, would be really interesting to see. And and more in the infrastructure space. I think infrastructure and security is if anything, it's AI is causing us the opposite problem in that space at the moment, where we're still, you know, having to do a lot of this work manually, not all of it, but a lot of it we're still having to do manually like patching servers or patching software and stuff like that. Um a lot of that is because of the sensitivity of it and how we want to be careful with it. So I'm sure we will get more comfortable with letting AI into that space. Um, but obviously you also hear all the you know the horror stories of AI is deleting databases and things. So we need to we do need to be very careful with production systems, but obviously, all the AI at the so many stories around AI at the moment, um, you know, basically finding so many more vulnerabilities that so many more patches are coming out. So we're constantly finding that you know, like more focus needs to come from us on constantly patching things, constantly keeping things up to date. So if in that area, it's probably not helping us in a in a sort of macro sense. Um, but yeah, in terms of engineering, lots and lots of benefits in there, or at least at the moment, perceived benefits. I think you know, there's definitely some downsides though, for sure.

SPEAKER_00 31:14

So I'm really interested in it like in a couple of things. Firstly, how it feeds into leaner faster, but secondly, how you manage that as a leader. I'm sure it wasn't a simple, okay, everyone, huddle up, we're gonna now start utilising AI. That's gonna it bring up a lot of feelings, preconceived ideas, fears, uh questions. So maybe if we start with that and then kind of what you've then seen and the results of that in terms of how the team are now working, how do you even approach going all in with AI in a team that maybe hasn't historically been that way?

SPEAKER_01 31:53

Yeah, I and I I would definitely caveat this with I've been very fortunate with the team that I've got. The team that I've got have been, you know, received this as well as any team ever could have done. Um, I certainly know from other colleagues and other people I'm connected to um in the industry that that isn't the case in a lot of places. There's a little there's a lot of resistance to to these kind of tools. Um, and I think a lot of it is coming from a place of fear. Um I think some of it, you know, is is justified. There is like you know, some concerns that people should have around it, but actually a lot of the fear and a lot of those concerns get alleviated when you just give it a go. Um, so I think from my perspective, the way that the way that we handled it with the team was was really around um being honest, I suppose, was first and foremost, but it did take a little bit of planning. Actually, in in truth, it wasn't far off having a big meeting with everybody and just saying, right, we're gonna use it now. Um what I was finding was that we had we had made acquired, we had been using a lot of sort of the the peripheral AI tools over the over the preceding couple of years up until we made the decision to go kind of more all in. Um, you know, we'd been using things like there's been you know, GitHub Copilot, which you liberally, we'd been using it for PR reviews. Um so there was like a level of autocomplete we were getting with GitHub. Um, some people had been playing with open code, some people have been playing with um cursor. So we had like small pockets of little bits of experimentation, but it was all done very tentatively, sort of almost around the seams, and it was almost like maybe a point of if somebody had done something with with AI and like it had, you know, written some code with AI, they probably weren't being very public about it. Uh and and maybe you know, people were obviously using things like ChatGPT or or Gemini in our case to use, you know, generate code and copy and paste it around. Um, but really what we were trying to do was get a step change. So I think you can kind of get so far with people playing with things like that, which I would describe as making the tools available and people will play with them. Um, I think what that allowed us to do was people to get somewhat more comfortable with the tools and somewhat more comfortable with that. So we weren't just kind of coming into people that hadn't played with it at all and like completely upending what they were going to do. But I did realise um we weren't gonna make that step change without a certain level of force, if if there's maybe not a better way of saying that. Um so it was one of the few times in my career where I did say to the team, look, this is this is not this is kind of a bit authoritarian, this is a bit non-negotiable, but we are going to do this and I'm gonna make some decisions now so that we don't spend a lot of time on it. And I kind of set some expectations. I just said I would expect that you know, within the next sort of six months, most of our code's gonna be written by AI. Um, but also being really honest with the team about like, look, we not only do we need to do this to remain competitive as a business and acquired, um, which which everybody wants us to be a success, we need to do this to be successful. Um, and we have an opportunity to sort of be somewhat ahead of the curve in payments. I'm not saying we're gonna be ahead of everybody, um, but there's certainly probably, I would say, a lot more people that are not using these tools than are using it in if we look at all of you know the the world of engineering. Um, but also for the individuals, it's kind of like really making them understand that this is good for their career, this is something that they actually really should be investing in for themselves. And actually by being here, being on this journey with us, they'll get to invest in themselves and invest in the tools.

SPEAKER_00 35:11

And I think Yeah, that's the crux, isn't it? It's the what's in it for them as well.

SPEAKER_01 35:14

Exactly. And I think that mix, plus the team being super positive and being willing to give things a go. Um, I think there was that there was also, you know, a really clear set of understanding around we know things are gonna go wrong, we're not expecting it all to go right. Um, we want to get out the gates really quickly with this, so we're not gonna apply a whole load of rules and spend a whole load of time doing things formally. We're gonna give you the tools and we're gonna have like regular catch-up. So we did like um a weekly huddle with the whole of the engineering, in fact, the whole of the engineering effort across the whole of the group at this point in time in in Quint. And where we would do like show and tells and share what we've been doing, and we'd try, and you'd see like the um evolution of practices across the whole group happen week by week. Somebody would say, I've been doing this thing with um, you know, um as an example, um, with one of the frameworks that can um sorry, the the name of it's escaping me now, but one of the frameworks that can do sort of like spec driven development, and they would demo this is how I've been trying to do that, and then a bunch of other people would pick that up and maybe evolve it a little bit further. Um so excuse me. So you would see that evolution as a group and the whole team was pulling in that direction. Um, but making sure they understand, you know, that the team understood this is as good for them as it is for us. Um, I think one thing that really helped was that we were already this lean team. So, kind of to your point before, we we already were priding ourselves on being lean, um being highly effective for the size that we were, and this was seen as an extension of that. I think regardless of how lean you are, there is, I would, in my opinion, there's a reality of like depending on what kind of business you run in. Um, in a quad, you know, we're highly regulated, we're in financial services. Um, you know, we work with a lot of financial services organizations, so we provide services to them, which means that we are, you know, we have quite a high standard to meet from a security, from a due diligence perspective and all that kind of stuff. Um I think there is like a critical massive engineering effort that you're gonna need in the team. I think if you were in a if I was in one of my previous situations where we had a team of 100 or so people, it would have been hard to introduce this without some reality that there's probably going to be a downstream impact of that, i.e., maybe some people are gonna lose their jobs over the over this. Um, I think because of the size of our team, we knew that we were at a probably the critical mass where we probably couldn't be much smaller. We were already very effective at that, and this was just seen as another notch up. Um, we were also doing it almost as a practical choice to not to do it instead of growing the team a lot more over the next year. So we made the decision that actually we're not going to do a whole lot more hiring over the next 12 months. We might do bits where we need to. Um, but but the current position is we're at a good size now. Let's focus on making ourselves super effective and let's grow the business through the adoption of these tools as opposed to growing the business by throwing more people at it.

SPEAKER_00 38:03

Was there any pushback? Did you lose anybody along the way?

SPEAKER_01 38:06

No, we didn't lose anybody, so we've been really fortunate. There's definitely been like little pockets of pushback around certain things, but it's been more navigating the field than it has been um resistance to using the tools.

SPEAKER_00 38:17

Do you think there's an element of um like it's cheating? Like, do you think that like it just like an instant reaction? Like I I've put all of this training, I've got a computer science degree, I want and and now I'm gonna let an AI agent do this for me. It it's not real. Obviously, it is real, it's real results, it's real steps forward. But coming from somebody that really likes to own their work, do you think that's that's a a real feeling that might be have been felt at times?

SPEAKER_01 38:48

Um definitely. I think I think definitely before we set the expectations, there was there would have been an element of that people feeling like using these things is somehow cheating. That that would definitely have been the case. I I would have said that I felt the same way. Like I might have used it to kind of like help me do something and felt like I want to keep it quiet that I've helped it do me that, help me do that now. But then you celebrated it. But then we celebrated it exactly, and we kind of said we celebrated it, we get per gave permission and set expectations.

SPEAKER_00 39:12

Yeah, you brought it into the into the the conversation, and I love the fact that you started bouncing off each other, and then it became this thing that yeah, it's enabling us to it's a it's a superpower, it's helping us to be better than we've ever been.

SPEAKER_01 39:26

Which I think is exactly what happened, and I think that like that that for me um that that was great, and that that was how it worked. I think there is some reservation in there, which I think is like we shouldn't be blind to the fact that like it is easy to get carried away with it, and it can go so much quicker than you expect it to in terms of evolving practices. Um and and I do think there's some like rightful um reservation around how how fast we should adopt what things and how much we should roll it into new practices, and and I think it's really hard to sort of meet at the moment with moving fast enough, keeping up, keeping ahead of the curve or on the curve, if you like, um, but doing it not recklessly. Um I think there's a sweet spot. I would I would always hope with these things that there's a sweet spot. Um, but that's I think where we are now is trying to navigate that sweet spot. For example, um, you know, one of the big conversations we've got at the minute is is we still do a lot of we we still primarily we have AIs doing helping us do our um pull requests and doing our peer reviews, um, but we still have humans doing it. So every every pull request is reviewed by and approved by a human in the way that we would traditionally have always have done it, um, which is like you know, you look at a pull request, look at the diff, and look at the code and try and provide some feedback or try and you know find things that might be wrong with it. Um one of our big conversations at the minute is that is like the bottleneck, is one of the points that we're getting stuck at at the minute that's like it doesn't feel like it fits very well. And actually, a lot of the time you're sort of landing in these PRs and you don't have all the context of what's been there. Um, but I think you could swing right to the other side because it's just like, okay, well, just you know, let the let the AI agent review it and then just if that's fine, then just approve it. I think that's probably like a bit too big of a leap. And I think there's some like natural reservation to jump into that. But actually, what I'm where my opinions landed on this is actually PRs were always a bit rubbish. They were always not very good at doing the job, they were always like quite a weak control. Um, but if we if we can leverage AI to make them good and we can do a better way of doing it where it can we can have like 10 agents all reviewing different specialist activities across that, one may be doing security, one may be doing compliance reviews, one may be doing you know, functional reviews, non-functional reviews, performance reviews, and things like that. Um and then summarising it up and presenting it in a better format that's more human-consumable. I've never felt that the PR, um, which you know you're probably not that familiar with, is a very human-consumable way of doing that activity. I think that what you could actually end up with is something that's on aggregate better, um, leveraging AI and actually moves more quickly. Uh, but again, we're kind of work, that's kind of where the sort of for us, I'm sure it isn't the frontier for anthropic, but for people like in in us and uh acquired and within the quink group, that's kind of where the frontier is at the minute is how do we do those kind of things and how do we find our ways through those more quickly?

SPEAKER_00 42:14

Nice. And that's the that that's kind of the next precipice to push over in your mind.

SPEAKER_01 42:20

Yeah, I think for us, we we I think I what I've noticed is with this is um we took that um intervention that I mentioned earlier where we I I kind of say, look, we are gonna do this, set a load of expectations, give a load of permission, um, you know, accepted that we would, you know, have some missteps, but this is the right direction to go in. That kind of accelerated us quite a lot and everybody got excited and has got into it. Um what I've noticed is with this is because I think it's moving so quickly, um, and you've got to align a group of people around something, I think we're gonna have to do it again. I think we're gonna have to set have almost a pause and say, right, okay, we'll we've we've got to this point, but some of this must need standardizing now. Um, what are the things where we're all solving the same problem but doing it slightly differently, where we should all be solving it the same way? Where are we creating more problems? Like, for example, where's somebody else picking up some code and somebody else is using their agent framework in a completely different way and they don't know how to even get started with it and it starts doing weird stuff? Um so I think we've got to almost take that next step now, which is what bits do we standardize on, what bits do we don't? Um, where do we expect people to be using sort of like the multi-agent frameworks with orchestrators versus where not? Um, so I actually think it's gonna be that's and things like the PR process, how do we overcome that? So I think there's almost like another big nudge over the the edge that we've got to do. And I I suspect that it's gonna keep needing those nudges to actually get it to kind of like get the whole team forward. It's almost like everybody's playing on, you know, sort of running on the track and running around, but you almost need to just drag everybody right roll at this line now, and then right roll at this line now, just to make sure that we all have a clear understanding that it's okay to do it this way. It's okay to do it that way.

unknown 43:59

I mean

SPEAKER_00 44:00

Super interesting that and I'm sure really interesting to people listening, watching, of someone that's gone on that journey with the team. And obviously it's going to raise a lot of questions around the future of engineering. I mean, what you mentioned to me, you know, if someone hasn't shown a real interest, that's probably one of the first signs of whether or not they're going to be right for you and your teams moving forward, right? Um, how do you um how do you let's start maybe firstly with job security? I know you touched on it with the bigger organizations versus a lean one. Like what's your take on job security within engineering with all of the momentum that we've got now?

SPEAKER_01 44:41

Yeah, it's probably the hardest call to make at the moment. I mean, I I'm generally an optimist about these kind of things, and I generally think there will be still a lot of places for engineers for quite some time to come. Um I think the nature of the job's changed. I do. I think that the nature of the job has changed. It's nothing. I mean, as you mentioned, I've been in the industry for 25 years or so now, and nothing has changed the job so much as this. So, not so quickly and not at all, like going through moving to the cloud, moving to hypervisors and VMs and doing this out of order, but you know, moving to CI CD pipelines, all of these kind of like evolutions that we've had, containerization, Kubernetes, all of that kind of stuff. Um, it all changed things, but not even close to how much this is changing things. Um, so I think the nature of the job's changed, but I do still think there'll be a big place for engineers. I think that we'll just want to do more things. Um, and that that will most likely be. I I think there'll be interesting new practices that crop up as part of this. I think that you know, learning how to be efficient with using the AIs is going to become more important, I would I would imagine, over the years, because the cost associated with it is going to become very important and very significant. Um I still think that and again, this is my personal opinion, not everybody would agree with this, but um I I still think you need engineers driving the AIs to do this work. I I don't think I think if you're not if you've not got engineers involved in it that can rightfully challenge the AI um and keep their eye on them and coach them and bring them along, then you've got a you've you've got a problem, and I think, or a problem waiting to happen. So I would definitely believe that that's going to be the case. Um so I do think that like from a job security perspective, I think should people be worried? I think if they're not investing time in their skills in these these kind of things, if they're not curious and if they're not, you know, using these technologies, or at least, even if it's only in their own time, um, not get an exposure to them. Um ideally in a commercial in a commercial um capacity, um, then should they be worried? Maybe. Um, but I do think that if you are investing your time in those things, if you are being curious and you are pushing forward, then there's a lot of jobs out there. There's still lots of people wanting to hire, there's still like lots of opportunity and people wanting to make things, and I think that'll carry on going. I I think that you know, more than anything, to just run these agents, it takes like a lot of curiosity, a lot of engineering skills still to make it effective. I think that's probably part of the reason why there's so many projects that haven't worked out quite so well in with AI as you would imagine in organizations. There's departments that you would think would have been more disruptive or adopted things more quickly in a lot of companies. I think probably the AI, sorry, the engineering heavy organizations have probably made a good job of that. Um, but you need these people who can, engineers who can understand the technology, how to implement it, who can problem solve around it, which I think is what engineers are fundamentally really good at doing.

SPEAKER_00 47:35

I think something that's coming out more and more people that I speak to on on the on the post podcast is um plugged it there. Um is you in in a world where you can build anything, actually deciding what to build is now gonna be one of the biggest things. I and I specifically my product guests, you know, having that yeah, moving from we want this, we can build it, to okay, really thinking about well, what it is that we build, how it's gonna impact the business, and is it something that's gonna be positive for the business?

SPEAKER_01 48:10

Yeah, I think that the there was always a friend of mine actually wrote an article about this, but I think that there was always a natural resistance to like like a have being a feature factory was generally always considered not a good thing if you're in technology. It was you if you're churning things out um but not really understanding the value that that brings or the the needle that that moves, it's not a good thing. You're just churning stuff out. Um, I would definitely say that um there was a natural resistance, like a healthy resistance that was sort of inbuilt to not becoming a feature factory, which is you needed engineering resources and people and effort. So it took time and money to do that. So you can you were somewhat limited, and I think you're right. Um by introducing AI, that kind of eliminates that aspect of it, and you can see a whole load more junk coming out as a result of it. Um, I think, yeah, choosing the actual difference-making things and keeping a track on that, making sure that the quality is good. I think as well, like a lot of the stuff that AI is changing out, the quality is quite poor. Like you can visit being really critical. Like if you look at Anthropic who are great, um, the quality, a lot of their work is not great. You know, they're they are struggling from they've got one of the the sort of worst availabilities out there at the moment. Um, they're clearly incredible engineers and incredible at what they're doing, but um it if you're moving that quickly, something's gonna suffer, and often quality is gonna be the thing that suffers. So, yeah, I think choosing the right things to do, finding the right thing that's gonna move the market for customers is certainly gonna it's certainly gonna be very important for sure.

SPEAKER_00 49:43

Yeah. And I don't I can only speak from from a pulse perspective in terms of what we're seeing in the UK market right now, which is absolutely uh a better market than we've seen for a number of years. I'd say over the last three years we've seen a consistent increase in job flow, specifically around product and engineering. And I wonder how much of that is attributed to the fact that we can now do so much more and so much quicker, and that's actually having the reverse impact that we maybe was predicted. And obviously there's nuance and lots of other things, but is there some truth in the fact that this doom and gloom of it's gonna take all your jobs? Actually, it it at the moment, for now, it's creating more opportunity because we can do so much more so much faster than we ever thought we could.

SPEAKER_01 50:35

I could certainly believe it. I I it feels sort of too early to call at the minute, um, but but in the immediate future it could definitely be having um the opposite effect to what we thought it would. I I think as we um as I was saying earlier, I think the the thing that's really going to be different is you being the person that they want to hire, being having the hireable skills, and I think they may maybe weren't the skills that they were five years ago or or even two years ago, which is go on.

SPEAKER_00 51:02

What are those skills?

SPEAKER_01 51:03

I mean, I think for me, um, and again, I I've been very fortunate, but I've I've always been a believer in hiring for certain qualities in a person, and they've they've they've not always been obviously you want somebody to be technical, technically competent and curious, and that's really important, but a lot of it comes down to sort of attitude and personality, really. And I think that that carries over even more so now. Having people that um, as I mentioned, curious is definitely important, but people who are you know pragmatic can pick things up and run with the ball, get you know, get the ball over the line and and score and finish the job. Um, people who in enjoy what they're doing and can and can get stuck into things. Um, I think optimizing for those kind of skill sets, being willing and able to learn, not getting kind of not getting stuck in your ways is really, really important. Maybe that comes hand in hand with curiosity as well. Um, working well with others, um, that probably even what's working well with AI now, right? They're almost like other people these days. So I think that actually optimizing for that kind of skill set is going to probably be more important than ever than optimizing for, you know, I'm really good with, you know, JavaScript or .NET or I'm an expert in SQL Server. Um, those skills are probably going to become even less important than they were. Now, I would argue that for the last, you know, for for quite a while now, and all of the engineering teams that I've built, that's always how we've hired four people. Um, that whilst the technical skills are important, um, it's actually more the curiosity and the the attitude of the person that tends to tell us whether they're going to be a success or not. Um, but yeah, I I think that it that's even more going to be the case in this new kind of bright new world.

SPEAKER_00 52:44

Is there is there room for more junior entry-level software development engineer experts, whatever it's going to be called in the future? How is there room for that?

SPEAKER_01 52:56

You know what? Um, this is probably the hardest question to answer, and I probably one I don't have the clearest answer on, and it's probably the one that I'm most uncomfortable with is I don't know how we have like like it's one thing when we've got like you know, relatively experienced or senior level engineers working with these AIs and guiding them, but but there comes a point when that's gonna sort of work its way through the system. Um I don't think throwing a junior engineering with an AI is ever gonna develop the same skills as it would have done in sort of my generation of engineers, of people who actually had to write this, write the code and sit and learn it and see how it worked and and debug all those lines of code when actually you know a lot of the newer engineers are not gonna see any of that or very little of it. Um so I think there needs to be there needs to be junior engineers because I think we're still gonna have a demand for engineers in the future. Um, but I don't know how that looks in the world of AI because it kind of feels like it's gonna be very different from what it was in my day. Um and I I honestly don't have a a good view on where that's gonna go. I think it's probably the question the sort of technology industry should be asking itself more than anything at the minute is is is what does the talent of the future look like? Because we could end up in a position where the talent pool just drains itself out because there's no way for people to grow and learn all, or we come entirely dependent on AI's doing everything for us from an engineering perspective.

SPEAKER_00 54:20

Yeah. So if you're okay, so you're a mid-level engineer right now and you're maybe having you're dabbling at home, but your current business hasn't completely embraced it as a transformational move at this point. What what advice are you giving them in terms of what should they be looking at? How should they be developing themselves in their spare time?

SPEAKER_01 54:43

I mean, I I would definitely doing doing projects and working your own time is always like I I'm a massive advocate for that. Um I always have been, and and that isn't the case everywhere and with everybody, but I would always say, do your own projects. Um, I'm really supportive of my team doing their own projects. Um I think it's just a net benefit to any company to encourage people to do that. I think that, you know, as long as you know the right um boundaries are set up, so they're not doing that work in their work time and their job gets done properly and they act professionally, etc. Um, could you end up losing somebody because they're what they're working on in their own time ends up being becoming their main thing? It's probably happened to me one time that I remember, um, which was which was challenging, but you know, I was very happy for the person that that happened to. Um but actually the experience they gain from doing that stuff is is really positive. That'd be that's one sort of thing for the sort of people in leadership. I would say you should be encouraging people to do this stuff because it's it's a net benefit. Um, but yeah, if you are that person, definitely finding projects to do. Um I wouldn't just spend time like doing courses and learning things, definitely do a bit of that. But I think you actually need to get on and deliver a thing, build a thing, take it through and follow it through to the end. You need to kind of get it live and get it in front of people and get some feedback on it and then iterate on it a little bit. I think going through the full cycle using AI within that cycle will really help you learn more than anything else will. Um, I think that's what I've seen with. So actually, the interesting thing is when we started just before we took this big sort of forceful step at acquired, um, I'd kind of encouraged a couple of the team to do this with some of these kind of tools. And so I'd kind of tested the water, we've got some tools available to them. Um, I knew that they had like little projects they'd been thinking about working on or had been working on. Um, I'd done it myself as well, where I thought, right, I'm gonna, I spent my whole Christmas or uh, you know, a bunch of weeks just obsessed and doing nothing but playing with clawed code and and other tools around it. Um and then having lots of conversations with this small group, the small community of people that we had doing it. And actually the development they'll get they got from just doing that and going through the build cycle with it was so, so good, um, so quick. And actually, then that helped them then accelerate into our practices that we're now sort of adopting at acquired so um or acquired all of the quink group in general. It's broader than just just acquired that. Um, so yeah, I I would definitely say do projects, but do projects that you can take through to the end, don't just do um sort of like desktop, like not don't just follow a um a course that you might need it to get started, but actually build a thing um and then hit the problems and then go and start Googling or Clauding how to how to solve those problems. I think that's how you really come along um with this and how you'll really develop those skills. And I think once you've done that, you've you can then have a portfolio, something you can point to. Um the other thing is this, you know, there's still open source projects. So contributing to open source projects is also another good route to go down. I'd definitely be very pro people doing that as well. Um, that's another good opportunity to to exercise your AI skills, albeit in that kind of environment, in that world, you do need to somewhat um make sure that that project is welcoming of AI contributions because there is some resistance to that. And and also making sure that you're not just throwing AI slop at it, because there is like a little bit of that been happening where you know people are just like getting their AIs to throw tons and tons of stuff in when actually it might need to be a little bit more curated and have a little bit more time and effort put into it than just just getting the AI to do it and throwing a PR up.

SPEAKER_00 58:09

I guess that's everything you said, it's so useful. And thank you. I think um it's just making me think how much your role must have evolved because you're now almost like the uh the the ambassador for this and ensuring that it doesn't move into as you call AI slop, you know, and being the guardian of quality across your team must have been something maybe that you were doing before, but it's a it must have evolved in this new world.

SPEAKER_01 58:38

It definitely evolved, definitely changed a bit, but there was always um it's funny because there's so much of what we're doing now that is just the same as what we're doing before, but just with different, but but but with AI and not people. So like um without trying to treat all people like they are AI or robots, um a lot of the practices and things that I think you need to do with AI or with people using AI, that they actually don't change that much. It's like making sure people are clearly accountable and responsible. Um, I think we're still in a position where we do have individuals and humans accountable and responsible and making sure people are clear around that, um, making sure that you know we have the right check-in points and all that kind of stuff. But certainly the ambassadorship side of it is definitely newish, or at least new for this particular thing. Um, there would always have been things like this in the past where you would have said, Oh, you know, we we need to move to this framework, to this tool, or move this thing along. Um, but culturally, really a lot, I I guess I think as a CTO, a lot of what you're doing is is is like just trying to like develop the culture and keep the culture pointed in the right direction and making sure that it's somewhat curated or somewhat um aligned to what you and what the rest of the team want out of it. Um, and I don't think that's changed. I think it's just it's got a different set of problems in there. Um, I think if you're focused on evolving, adapting, which we should all be doing, then actually you in you you're best set to deal with any of these problems that AI or anything else can throw at you.

SPEAKER_00 1:00:05

Yeah, and it sounds like you've really done that and embraced that. And it sounds like a very exciting team to be part of that's learning and embracing change. And you know, thank you so, so much for joining me today. Um can people is there any way that people can follow and connect with you to keep listening to kind of your views and how this evolves?

SPEAKER_01 1:00:26

Um, yeah, sure. So um, I mean, LinkedIn is one of the probably best places to find me. I I'll normally post things onto LinkedIn on I also have a medium blog that I'll write some things to probably like every other week or every week. So that they're probably the best places to find me.

SPEAKER_00 1:00:39

Amazing. Matt, thank you so, so much for today. It's been a great talk to you.

SPEAKER_01 1:00:43

I don't know. Thank you for your time.