Craig [00:00] What if code gets out there? I'm like, so what if code gets out there? It's like, that's not our differentiator. Our differentiator is our data and what we can do with our data. Are you going to grow? Are you going to cut? Before you start playing with AI, actually bolster the quality of your checks. Because AI is going to produce volumes that maybe you can't quite control. It sounds bad when you say it, but his mantra was, engineers need to be taken for granted. You get to the house, you put your software on, you push the button for this light, nothing works.

Francois [00:37] Hello and welcome to the Nexus of Next innovation podcast. Today, you are in for a treat, I can tell you that. I am joined by Craig Risi.

Francois [00:48] He speaks at international tech conferences, designs published board games, and runs ultra distances for fun. You know, it's the breadth that matters. The same instincts that help you design a great board game is the same things that you'd require to build a resilient CI/CD pipelines. And that same discipline gets you through an ultra marathon, long work, modernising the engineering of 181 year old business. Craig, welcome. Such a pleasure. Yeah. So, Craig, you're someone with such a wealth of experience in so many different areas. And one of the things that I always find interesting about polymaths like yourself is that you have well-rounded opinions about many, many things, just purely because you're curiosity driven, right?

Craig [01:39] I think absolutely. I think it's just that natural curiosity of how do we do this? How do we build that? I think that's probably why I got into computer science in the first place. I was just playing a video game and I was like, this is so cool, but how does it work? Yeah. And then you start to unpack, well, these images on the screen, they've got to come from somewhere. And then you start to just unpack the layers and that just opens up this whole thing for you. But I'm also at the same point in time, I feel like I can't just be in computers and just code. Yeah. I have a lot of other interests too as well. And I find that it actually helps me to focus better because if all I did was code, I would probably get very bored and lose my engagement.

Craig [02:24] But because I'm into other things as well, I feel like I'm always engaged.

Francois [02:27] Yeah, that's so true, hey.

Francois [02:30] So, Craig, today's a jam-packed episode, hey? We've got three stories that we are sharing. If you're listening, this is what we may actually get out of today's episode. Craig, what do you think is going to be the key take-homes for the people listening today?

Craig [02:45] Yeah, I think one of the key take-homes that people can take from today is that, you know, really your career is shaped from very early. I think too often, too many young people want to come into this industry and you almost want to just feel like they know it all. People want to rush from junior to senior very quickly, but reality is your career is a long career and those lessons that you learn early on really do play a founding role and you need to be able to allow yourself space to grow. You need to allow yourself space to learn those lessons because it's not going to just come naturally and overnight. You have to allow yourself to grow. And I think that's something which I really hope people understand is that if you want to become a really super sharp engineer and you want to be able to really push your career forward, allow it some time to build.

Craig [03:38] Don't rush the process because at the end of the day, it's where you are towards the end of your career. If you're going to get to a senior position in two years time, what's left for the rest of your 40 odd working years? I mean, what are you working towards? And I feel like we're just not allowing ourselves to learn those lessons. There's too much pressure to want to grow, grow. For one, I think you actually learn a lot from some of those early failures and those early lessons. Yeah, yeah.

Francois [04:07] I think that's so true. And especially like most people listening here, you're senior exec at a large company and you're thinking back at those old days, maybe it is thinking fondly of the ISDN era of copper cables and data and unstable connections that's subject to rain and all of these things.

Francois [04:33] It happened.

Craig [04:34] I remember in my early days, because you just save things on floppy disks. And so that became this thing of making your programs fit on a floppy disk so you could move them around.

Francois [04:46] Yeah. Yeah, that's crazy. And today, what do you mean there's a physical thing that you ship for a file?

Craig [04:52] And space is never an issue. You can make it as big as what you want.

Francois [04:55] I think there's a lot of things that drove ingenuity and innovation in that space because of those constraints, right?

Francois [05:02] And so when I'm thinking about how this new world is transforming completely, senior leaders are sitting with these two questions. You don't necessarily want to be the new kid on the block when this new technology comes out.

Francois [05:17] And there's this standard discomfort if you're senior to be a little bit averse to this purely because you'll be a novice at it. And then the other thing is now you're a senior leader, you're supposed to shape people. What's your view around that paradigm?

Craig [05:35] Yeah. I think it's an interesting one. I think particularly with this current era of AI, at the end of the day, we're all learning. There's very few people that can come and say, oh no, I'm an expert in AI. It's just been around for a couple of years. I'm not so sure of that. We're all learning how this is going to go.

Craig [05:52] I do think your experience helps. What I found is it just shapes the way you use it and it shapes the way you think. But I think a key thing for me is just always going back to those core problem-solving abilities. I've worked with quite a few juniors, you know, and we've had some of them come up to us and they're like, I've got this code, it's just not working. And so you start going through it, and then you start to ask them questions of why did you do this? Why did, oh no, no, but AI wrote that. I'm like, well, why? Why did you think that that was gonna work? I mean, because AI wrote it doesn't mean it's correct. And it's almost like you can get lazy.

Craig [06:29] And then starting to unpack the questions and well, what does this do? What does it actually do? Then they start to realise, oh, okay, actually, this is the wrong thing. Because AI doesn't understand the context. I think in a lot of companies that context is key. So, yeah, I think that is a real challenge because we are all learning. One of the things I like about the industry is you feel like you're an expert, but there's always new things coming out, and you've just got to be on the forefront of trying to adapt. But at the same point in time, I also feel like that experience does make a difference. That's those things that have got you there in your career.

Craig [07:04] Yes, you're learning a new skill for the first time. Yes, you're learning a new technology, but you're not learning from scratch, learning with experience. And that experience I find generally helps you to adapt the new technology a little bit better, which I think a lot of people maybe earlier in their career, maybe jumping fully into that technology without that. And then they're possibly uncovering a lot more things.

Craig [07:27] I mean, we found at work, we've given AI to a lot of the senior people and into the junior people. And it's infinitely more powerful in the hands of a very capable person.

Francois [07:39] It's like a vitamin almost, right? It makes really capable people exceptional and juniors, very, very capable, but also dangerous. Exactly.

Craig [07:49] But they need to learn through that as well. Of course. And that's the only way to do it is to put them in there and then to figure out these things when it goes wrong. Well, why? Why did it go wrong?

Francois [07:58] You know, one of the things that always makes me, A, very happy, but also makes you be a little bit more careful in how you engage with people, especially early on in their careers, is that as a senior leader, you actually have a very strong ability to influence their career, the way they think, the way they develop. And I think especially today, shaping how people think and how they develop is such a key capability of a senior leader. Be that in a town hall, be that at the coffee station, be that in a quick one-on-one, it's so important.

Craig [08:38] It's very important. And I think that's where the big thing in the industry is. And the nice thing is, this is something which I think AI can't replace, it's mentoring. So that sort of mentoring, those conversations you're in, they're helping a person through their career. I mean, you can ask ChatGPT or an AI agent, what do I do in this situation?

Craig [08:56] But the reality is by talking through it with someone who's been down this road, you're going to learn so much more. And you can bounce so many ideas and questions off and they can help shape that narrative. But I also think that's where senior tech leads need to also step up, because I've also experienced these people who are like, I'm a senior, but I don't like people. So just leave me alone.

Craig [09:20] And I get that because sometimes you want to focus. You feel like you want to get your best out. And having youngsters come and ask you questions all the time throws you off your game. You just got in the zone and now they're going to throw you off. But it's the only way to really help people.

Craig [09:34] And I think we've always got to be thinking of what's the next generation doing? What's the next generation doing? And we've got to make time for that. I feel like if we're going to ignore that, we're going to lose out on growing these people. And at some point in time, they're going to be the seniors of tomorrow.

Craig [09:51] And if we don't shape them, I mean, they'll learn the lessons and probably shape themselves. But we can certainly, I think, fast track that and help them more.

Francois [10:00] Yeah, I think there's going to be a definite pipeline problem in the talent space in technology soon. Yeah.

Francois [10:06] But before we head into that, I think there's one story that you shared with me specifically around a lesson you've learned early in your career that stuck with you.

Craig [10:17] Yeah, absolutely. And the funny thing is this is not a lesson which happened to me. This was something where in one of my first jobs, one of the managers pulled me around. He just wanted to give me some advice, and he gave me some advice through the lens of the story and he called it the story of the belter. But essentially how the story goes is there is this young person who goes up to his boss and says, you know, I want to raise. I feel like I do the same job as the person next to me but he's getting paid more. And I just don't feel like it's fair. And he was like, okay great, I understand what you're saying, but I'll tell you what, there's a new belt store that opened up to us, you know, downstairs. Why don't you go and, you know, tell me about it. So he goes, okay great, so he runs down, goes, sees, okay well there's a bunch of belts. He goes up and says, okay well, they're selling lots of different types of belts. There's leather belts, there's, you know, these type of belts. And it's like, okay great, do they have a purple belt? I don't know, let me go up. Yeah. And then he goes downstairs and then comes back and then he goes, yeah, they have a, I'm looking for a particular type of buckle. Do they have that type of buckle?

Craig [11:32] I don't know, they'll go ask. And this goes on four or five times before he eventually comes and says, okay, well, I now know that they've got exactly what you're looking for. But he had to make that journey four or five times. He says, okay, great. Then he calls the other guy and says, there's a new belt store that's opened up downstairs. I'm looking for a new belt. Can you go downstairs and start finding it? It's like, okay great, but what type of belt are you looking for? What colour do you want? What type of buckle do you want? What size belt are you looking for? He starts to ask all the questions up front and then he goes down once and can come back with the belt. And I think what struck me, I think the reason why this is such an important lesson and what my manager at that point in time was trying to convey, was ask questions. Don't assume that you know what you need to do. The difference between these two individuals wasn't their skills. Just one happened to ask questions and got it. Got the job done once. The other person had to go down the stairs five, six times. And that's the difference between the two. The one was a lot more efficient than the other, not because they were better skilled, just because they asked questions and understood what needed to get done.

Francois [12:41] Yeah, that's super. It's quite interesting because that story happens today, probably in your organisation every single day. And when we think about it, that ability to ask questions and get clarity yourself, that's not something that GPT or any other large language model will teach you.

Craig [13:07] No, it's not. And we've even picked it up in our organisation where we look at what's been developed. And a lot of times you go into what's been developed, why did we do it this way? And you start to ask the questions and you start to realise that maybe there were some gaps in terms of some of the questions.

Craig [13:23] Someone didn't maybe understand what they're doing, why they're doing it. Yes, you just get given a spec. I need you to build this, build this, but why? What does it do? How does it get built? What problem am I trying to solve by doing this? What's the customer need? What sort of data do I need to get the desired outputs?

Craig [13:40] Does this need to be something that services an API or on the front end? And I think if you're just going to build something very verbose and high level, you're going to get some very vague stuff. And we found that a lot of the issues that then get picked up in production, a lot of the times, if we had asked better questions and understood the customer reference and what needs to do to get that output, I think we would have not made that mistake.

Craig [14:05] I think it all just comes down from asking questions, really trying to understand the problem. And if there's anything that you don't know, rather ask the question. So before you write a line of code, you should be very clear what it is you're trying, even stuff like what tests do I need to pass?

Craig [14:20] What does it look like? What does the test look like for this thing? Have you thought about that? You know, is there performance constraints? I need to deploy this into the cloud. Am I familiar with what type of cloud environment I need to go in? I think too often people are just quick to take the task and go with it and then start asking the questions later.

Craig [14:36] I think if you ask the questions upfront, you get it done faster.

Francois [14:39] Yeah.

Francois [14:40] And it's so full circle to the curiosity element. And I think it's that lack of curiosity about what we're actually doing and why it actually matters. And it always makes me think of Simon Sinek, the good old why. I think he says, people don't buy what you do, they buy why you do it.

Francois [15:02] And I think that holds so true within today's individual contributor landscape where you're a software developer or I think even all the way to senior executives, having the ability to fundamentally understand and explain the why is such a challenging thing to get right.

Craig [15:22] It's very important. And I think people need to also understand, especially in the software development space. I think you go into the software development space because you want to build software, you want to be able to solve problems, but you also need to make money. And that's, I think, something which large companies can certainly teach you that have been around for a long time. But you've got to understand that. Why do you exist? Why does your customer want to use your service? What problem you're trying to solve? Those are the key things that you want to draw closer to and if you're not invested in that, I think you're inevitably going to build substandard services because you're just writing a service for the sake of writing a service rather than really trying to grasp for what is it that we're going to, where are we going with this, what are we trying to build, and asking those questions because sometimes you can do it better or differently when you understand those things.

Francois [16:13] Yeah, I think especially in today's day and age, I fundamentally believe that we're going to head into what I call a purposelessness pandemic. Yeah. And the reason why I'm saying this is as we progress down this rabbit hole of artificial intelligence and heading into AGI, if that's a thing, we'll have that conversation then. What we'll notice is that people will just not have that purpose. And I think purpose actually comes from that curiosity. And so when we look at very large businesses, one of the big headaches that you'll have is if you have a workforce that doesn't have purpose and they don't have the ability to ask questions or a Kindle curiosity, then what's going to happen is the business is going to lose its way.

Francois [17:09] And so it's so cool how that story of yours of asking questions and understanding the why really speaks towards a much bigger problem that is probably going to happen in our industry across the board.

Craig [17:24] Absolutely. And I think it's a simple story, but yeah, it's universal and it transcends a lot of different industries and a lot of different thoughts, but we need to be asking those questions, getting that reflection right.

Francois [17:37] Yeah. It's like Ray Dalio says, life is about asking higher quality questions.

Francois [17:42] I'm still trying to figure out what the question should be. I know.

Craig [17:47] Asking questions is a skill.

Francois [17:49] It is, yeah.

Craig [17:49] It's also something, I think, like with all skills, you've got to practice it. And I think a lot of people are sometimes afraid to ask because they're like, oh, I'm in the stand up. I've been told I need to do some work. I don't want to ask any questions. So I'm going to just go in and try to figure it out. And then maybe a little bit later on, if I can't come right, tapping someone on the side and say, this is what I was thinking of.

Craig [18:10] And then inevitably it's not exactly what they want. And then you've got to go back and forth and figure these things out. But we really do need to be building on that, wherever you are, even if you're a junior. You shouldn't need to feel awkward about asking a question, like you're just trying to understand, you're trying to seek that. And you know, the more you ask the questions, often it forces everyone else around you to also start evaluating, actually, are we doing this the right way? Because sometimes we just go down this approach, particularly if you're in an organisation which is hierarchical or has someone who's very senior and knows the application well, and when he says, here's what you need to build and do it this way, you tend to just get into the mode of, let's just get it done. Yeah. But the reality is they themselves might not have realised that there's other ways of doing things. And when you ask the questions, it helps them to be able to think, actually, you know what, you're right, we should actually do this a little differently. And we've got to practice that skill, and we're going to practice that skill from the beginning. And even though it's difficult and you might feel like, I'm a youngster and I don't want to ask the questions in front of a more senior person, but that's the only way that you're going to figure this out. And the more questions you ask, the better you get at asking questions.

Francois [19:20] I think it's also quite an interesting knock-on effect, right? Because, especially in the tech track within a business, right, there's many tracks. There's a marketing and sales track, there's the operational track and there's the tech track, right? What we've noticed is a lot of people see asking questions and not being in the know or not having that capability as weakness.

Francois [19:45] And so then they hide that by saying, no, I do understand. Exactly. And the thing is, when you're a junior, the blast radius is quite small. But as you get more and more and more senior in a business and eventually you're responsible for an entire continent or a region, then that blast radius is quite big.

Francois [20:05] Yes. And if you don't understand the why there, it might be a very, very big problem. Yeah.

Craig [20:11] And yeah, I think that's a lesson that people need to do. Start early on. I've worked many, many juniors who explain the problem and they'll be like, okay, great. I understand. They actually don't understand. And you might only figure that out later when you're reviewing the work, like you actually didn't understand what we were asking. That was your time to get that clarification. If you didn't understand what we meant, if you didn't understand how it was gonna work, you should have asked. And there's no shame in that.

Francois [20:43] I will say, you can tell an expert by the way they answer a question. The question usually is answered with a little preface called, it depends. That's when you know that person's been around the block. They've seen a few movies before. There's really no one answer for things.

Francois [21:02] Exactly. There's always trade-offs. Something interesting from Elon Musk that stuck with me. He said, make the requirements less dumb, especially if they come from a smart and capable person. Agreed. Because that aura of competence pushes people not to question it.

Francois [21:21] Then a lot of the times, smart people do make a lot of mistakes, just like everyone else. All the time.

Craig [21:27] I think that's the thing. You're also going to be comfortable with the fact that you're going to make mistakes. This age of thinking, oh, we're gonna be able to, as I get better, just be good at what I do. You might get better at what you do, but we're always gonna be making mistakes. Yeah. And I believe that mistakes are inevitable, but that's what you do. It's how you handle them and what you do to try and prevent from making mistakes the next time. I feel like too often we make mistakes and then we try and brush it under, or like, I made this mistake, let me quickly fix it, and we don't spend enough time trying to figure out, well, why did I make this mistake?

Craig [22:01] Why did we as a team make this mistake? And I think if you spend more time there, you also then learn a lot more and be able to go, okay, well, by doing that, we're actually now in a better position to not make that mistake again, because we actually understood what led to that mistake.

Francois [22:14] Yeah. I always say, don't let a good mistake go to waste. Absolutely. But it's so interesting how software design and technology design really mimics human design at the end of the day. And it comes down to asking why.

Francois [22:31] So we've all had those projects, right? These projects where things just go sideways. And in large enterprise, especially one that's been around for 181 years, I mean, there's legacy, there's systems, there's complexity, and most importantly, there's scale. And so large enterprises want to do things large.

Francois [22:58] Tell me a little bit about a story where you had a project maybe early on and that project just didn't do what it's supposed to be doing. Yeah.

Craig [23:07] Again, I think there's always the stories early in your career that you learn the most. I was a software developer working for a home automation company or home office automation, before home automation became this very ubiquitous thing nowadays. It's a lot easier to set up a home by a bunch of smart devices and they just speak together and everything is seamless. This isn't the day where everything had to be wired and spoken to, and if you wanted to automate your lights you need to get specific lights and everything wired through a server. So going back 20 years when everything had to be wired and the whole house had to be designed around an automation system to make it work, and we'd inevitably get the specs of how things should look. And then I used to pride myself on being able to, I'm going to build this in an object-oriented way that's going to allow it to be able to work and to scale and to modify better, and building everything through, looking at the spec and trying to get everything to work.

Craig [24:07] And I was always very proud of my approach to how I'm going to try and get this. But then you take your code and you get to the house, you put your software on, you push the button for this light, nothing works. Just like nothing works, trying to push things, just nothing worked. And this was sound, this was the lighting, nothing worked. I was like, what's going on? And I was freaking out going, I don't know what to do. It's like, things aren't working, but my code looks like it's okay. But then coming through from a testing perspective, I was going to a room and going, this room's not working, this room's not working, this room's not working. One guy I was working with, he had again been in the industry for a bit of a while, said, your code looks fine. Put one of these lights on. So I said, okay, great. He went through the house and said, you know what? There is actually a light on. It's this one. Switch it off. It switched off. So the code was working.

Craig [25:08] Not perfectly. There were some refinements that we needed to make along the way. But from a testing perspective, I'm trying to deploy this entire system. Whereas how the house had been wired was maybe not according to spec. We had made the assumption that this is going to be for light one, light two, light three.

Craig [25:26] And the guys when they were wiring the house had maybe done a little bit differently. And he said this happens all the time. It's normal.

Francois [25:32] The map's not the territory.

Craig [25:35] But what you're trying to do is you're trying to solve for this big problem of my code not working and freaking out, when actually just try and find that one light, get the one light working and then take it from there and get another light working and then map it. And then all of a sudden you realise, okay, well, that light that's working there is not where you say it is. So now you've got to just go to your code and remap it. But it was just breaking that problem down globe by globe and speaker by speaker by speaker, to be able to really understand what's going wrong with the thing. And yeah, sometimes you want to just deploy everything, and I'd written all this code, I was anticipating, I'm going to show them, get this code, deploy it, and this whole house is gonna just work, because I did everything according to spec and I designed it well.

Francois [26:18] Like two fist bumps later and all of that scene.

Craig [26:21] And really showcase, I'm good at this, you guys must give me a promotion. And it didn't work that way, nothing worked. And nothing worked because I was maybe too presumptuous, trying to solve the bigger problem rather than what I should have just done and gone in and said, okay, well, here's a light. Let's actually find this light, let's source this light. Now I do it, let's source this light and do that. And methodically working back would have probably got me there a little bit better and sort of freaking myself out.

Francois [26:46] Yeah, and like way less pain probably as well, right? You know, it reminds me so much of like large enterprise and this like massive AI augmented automation sprint that businesses are going into right now. And I mean, we're seeing this at like startup level and we're seeing this at like bank level and multinational level as well, right? And I'm thinking about your house and the first problem being the map isn't the territory. So people think this is the way the business works. And I mean, when you're building the technology system, you almost always have a lot better visibility in what actually is happening on the ground to begin with because you're touching all of the systems, right? And so that's the problem. And then there's this big bang approach that people just want to apply. Maybe it's FOMO driven, maybe it's survivability driven, maybe it's short-sighted, returns driven, whatever it may be. But it's quite interesting how just starting with that single light is actually the most important thing.

Francois [27:51] How would you say that single light looks like in a large enterprise?

Craig [27:56] One of the biggest things I've been trying to shape in Old Mutual's mind, and I don't think we're there yet, but we're trying, is they have this notion of big deployments. They want a feature, so they want to pack all these type of things, and then we're going to deploy this entire feature, and the customer's going to get it.

Craig [28:14] So they build themselves up to, we're going to deploy this next big feature, we're going to do this next big thing.

Francois [28:18] And it's well-intentioned, right?

Craig [28:19] Well-intentioned. It's very much for the customer.

Craig [28:21] Exactly. And I understand why they want to do that, but there's inevitably, I think, a lack of understanding, again, around the notion of risk.

Craig [28:33] And it's almost like they feel like if we do just 12 or 15 deployments a year, it's better because it's less risk because we don't want to make noise. We don't want IT to go down because in a company like Old Mutual, the reality is being a financial company, IT is there to make things happen, but it's not your key driver.

Craig [28:52] So if things go down, that's what you don't want. That's when they really hound IT. The good old

Francois [29:00] DevOps paradigm, right?

Craig [29:02] Why didn't this work?

Craig [29:05] And what I'm trying to shape in is just get something small working and deploy that. You will get to this point where you'll have all these features ready for the customer. But why don't you deploy, instead of this big release, 15, 20 deployments to get there and then working on the small thing and getting that right. And then working on the small thing, getting that right, inevitably is a lot easier to be able to do. And I think also just from a testing perspective, I think that's also one of the bottlenecks, is they want to test everything. But now if you've got this big project and you've got to test everything, that just takes a long time. And now you're going from wanting to deploy quickly, but now you've got to have like these, in some parts of the business, they want to have like a month long testing cycle to make sure everything's working.

Craig [29:57] And yes, there's automation and it helps speed up the process. But the point is, you wouldn't have to do any of this if you just focused on small releases, small releases, small releases. And so break the problem down into small chunks. What can you deploy in small ways?

Craig [30:13] Inevitably, I think you're going to get to the outcome faster and better quality because you're solving less problems. The other big thing in an organisation like us, and if they go down these big deployment routes, some teams still go down these big deployment routes. So then also say, well, let's do it on a weekend.

Craig [30:29] Now this team's deploying, this team's deploying, this team's deploying. So firstly, no weekend, everyone's now got to be available for this. But then what if something goes wrong? Whose deployment broke what? And now the amount of effort spent just trying to debug the problem drastically grows.

Craig [30:46] Whereas if I made the slight change and I deploy this like change or something breaks, I know exactly what went wrong because I'm deploying all the time. So if I'm all of a sudden push something through and something falls over, it's a lot easier to roll back. It's a lot harder to roll back big pieces of code.

Francois [31:02] It's just that one speaker that you added in the house. Exactly. So it must be that speaker.

Craig [31:06] It's gotta be that speaker.

Francois [31:07] It's just that one thing. I think that's how you gotta work back.

Craig [31:10] I always tell people, so something went wrong, what's the last thing I did? Just quickly roll that back and then see does that solve the problem. And sometimes it does, sometimes it doesn't, sometimes it's something else, but figure that out. But when we're working with these big deployments and trying to solve these big problems, we actually end up spending so much more time trying to solve really complicated problems that we shouldn't need to.

Francois [31:34] Yeah. I always say like one of the big problems that smart people have is they think they know what's going to happen. And the really smart people know they actually know nothing. And the only thing that matters is what actually happens in the real world, right?

Craig [31:48] Absolutely.

Francois [31:49] And so when I think about these major release cycles, we've got this massive update. The intent for the customer is great, right? The intent is to increase the user experience subjectively for every single user. It is designed to make the business fundamentally better.

Francois [32:08] But because there's so many assumptions, you're bound to actually stack your risk because there are things that you're going to assume that's not going to work, right? And when we think about these big bang releases, humans are notoriously bad at major changes. There's people still rocking Windows XP and ATMs, right? Absolutely. So let's, and that's a...

Craig [32:34] That's a big problem to solve. It's a problem, right?

Craig [32:37] But again, it's that risk because you haven't kept up to date with it. And that's another thing as well, where I also say we've had some teams which were using really old versions of Java, Java 7 or Java 8. Wow. Where the effort to move from there to a newer version of Java is so extreme, it becomes a massive project.

Craig [32:58] So now we need to migrate this version of Java to this version of Java. It's now become like a year-long effort to modernise because we haven't kept up to doing the small things. Whereas if we actually just kept up to date, oh, there's a new version, to quickly update, new version, just quickly update.

Francois [33:13] And deal with the problem there.

Craig [33:15] Deal with the problem the moment it comes out and always be up to date with these things and always keeping your maintenance in check. I think you solve so many more problems that way, and you're also just always then on the modern side of technology and you don't have these big problems. Now with the ATM still running really old versions of Windows, but no one wants to do anything about it because they're working and it's just so much effort to get it right.

Francois [33:41] Yeah. Tech debt is paid in BAU, not in a massive strategic investment. Yeah.

Francois [33:48] I think it's so interesting also how these big bang AI implementation projects fall into that same category, right? Where if you think about the best user experience you may have had, I can certainly tell you my best personal user experience is where I'm using a tool and every single time I get to the tool, there's like some new problem.

Francois [34:12] Some of them I were aware of and others that I weren't aware of that just magically is solved every single week. And I use the tool and, oh, this problem that was there is now gone. Or, oh, there's a nifty little button that now saves me three to five minutes every day. And when you think about that customer delight that people will experience when they see these incremental changes, that makes them feel like, A, this tool is moving in a direction fast.

Francois [34:41] And secondly, the feedback cycle is so quick that if you deploy any feature of that magnitude and you see initially that people aren't using it, then you're not spending millions of dollars or rands going down that rabbit hole when that was never even a thing to begin with. Exactly.

Craig [35:01] Yeah, we learned so much more from that. And I think it's this whole nature of this way of working from, I know in Agile, they say you've got to deploy and you get that customer feedback quickly. And I think that's the thing. How do we get that feedback as fast as possible and reduce that feedback loop?

Craig [35:19] But I mean, what you said there, I think just around AI, and I think where AI is coming through, I think AI has changed the game in that it's so easy to write stuff. I've also seen, and I made the mistake myself, trying to do too much. AI can do this and this and this. And so rather than working on the one API, AI has gone and built an entire ecosystem.

Craig [35:40] Whereas actually, if I just focused on building the system in small components, I would have probably landed up with a better system. But AI makes it so easy to build out this entire thing. But then you land with this problem of now you've got a lot.

Francois [35:53] Yeah, and there's a lot of problems as well.

Craig [35:55] And there's a lot of problems now to debug what's going on and to test it. Again, we've just returned ourselves to these big releases and big problems, whereas if we had actually just focused on iterative work. So if you're doing something with AI, actually focus on small iterative changes.

Craig [36:11] People are going out of their way to try and make big, massive changes with AI, and it helps, but you're going to land into a lot of problems now when you're trying to deploy your test stack because it's just too big.

Francois [36:20] A lot of people must misconstrue the fact that a giant stride sometimes is made up of many, many small steps for humans. I've stepped into that trap, lock, stock, and barrel, proper.

Francois [36:37] But what I think also is quite an interesting angle to that is we're seeing a lot of these very large tech companies who's laid off the staff because AI is doing all of the coding work, now rehiring quietly a lot of the people that was laid off, usually at a 20% premium. Absolutely. And the interesting thing is that what wasn't super obvious when that was done is that yes, you can ship 10x more code but your technical debt and the problems actually scales non-linearly. Meaning if you had a one out of 10 error rate, now that is scaling in an exponential rate because there's no human eyes that can really do QA.

Francois [37:22] And yes, we'll get to a stage where AI would be able to do that, right? We're not there yet.

Craig [37:28] No, we're not there yet. And I think we're sometimes too presumptuous of what the technology can do. And again, I always feel like it's really, to me, AI is more of a tool. And the tool in the hands of a really skilled person. And what you should do rather, you know, to these big organisations, rather than think of how do we lay off people, it's how do I allow them to use AI to unlock more and get the best value out of themselves, because they should all be now becoming more efficient. You should be able to see hyper productivity. But I think to your point, if you're not trying to write more code and do more things, you're dealing with just more problems.

Francois [38:03] Yeah, but also I think there's like a value paradigm shift that's required in this world at the moment. Because if you think about it, if you're a CFO that's responsible for a P&L, there's two levers you can pull, make more money or do things more cheaply. Those are the two levers pretty much that you can pull. And so a lot of people are knee-jerk seeing AI as this cost optimisation exercise where you can and effectively go and say, okay, we're going to make a bunch of roles redundant.

Francois [38:36] But the reality is that if everyone in the market is slowly but surely adopting this technology, and yes, there's different levels of maturity. I mean, we work with organisations from like maturity level one all the way to like maturity level seven. We haven't seen anyone transcend that. And yes, Google and the big tech companies aren't even there, right? And what's quite interesting is if everyone's using this technology, the beneficiary of this tech is actually the end user, if you think about it. And so if you're not gonna cut your staff, your competitor who's not doing that, by the way, not cutting staff and actually seeing it as a value creation capability, is now growing a workforce that's staying the exact same, but they're doing 10X more. And the other companies may be cutting by 75%. And are you sitting with a quarter of a workforce that's also doing 10X more, but you're actually at a distinct disadvantage due to that.

Craig [39:41] It's that you got to decide, are you gonna grow? Are you gonna cut? I think just kind of like you said, and I think too often, it's actually easier to cut costs. It's easier to, well, why don't we just try

Francois [39:52] And it's obvious.

Craig [39:53] It's the obvious thing. Like we need to make more profit. The obvious thing is, well, let's find ways of laying off people and let's see if we can use AI to solve some of these problems. But again, you just you can often then shoot yourself.

Craig [40:08] But I think the other thing that AI is bringing into industry that's very, that's going to be very interesting, because I do a lot of open source development, but now with AI, a lot of the open source projects are

Francois [40:20] Like, oh, good day.

Craig [40:21] AI can reproduce a problem quite quickly. So do I really need this open source solution if AI can do it for me myself? But where that's leading us towards within the industry is your code is almost now ubiquitous. You know, AI can help build solutions and build things for you that it couldn't have in the past.

Craig [40:43] So it opens us up firstly to a lot of companies going, well, actually, do we need this tool? Maybe we can build the tool ourselves. Maybe there's other sort of ways. But then that differentiation, again, what's differentiating you? I still believe that it's data that is the key differentiator for a lot of large organisations.

Craig [41:00] It's not the code. And I've often had that. Like some people say like, Craig, are you worried about code getting out there? And I mean, obviously we're very secure with that code and what we do with it, but like, you know, what if code gets out there? I'm like, so what if code gets out there? It's like, that's not our differentiator. Our differentiator is our data and what we can do with our data. And I think that's the importance of what we have, like what brings your company's purpose for existing tying that, because that's going to be the thing that's going to differentiate you. AI is going to make it easier for teams to reproduce what someone else is doing, quite quickly.

Francois [41:39] Yeah, I fundamentally believe the same thing. I think your data, look, when we look at data and the intelligence and value that you can derive from it, the code to data is actually your weights in your models. That's actually the crown jewels in my view at the moment, because that's where the insights value concentration lies. But when we think about this, I think there's going to be a massive shift towards results and outcomes, and how well, how reliably, and how cost-effectively you can create those results and outcomes for your consumer. Agreed.

Francois [42:17] And I think that's going to, A, look, we are already living a fantastic life compared to 200 years ago. And I think that that paradigm is just going to perpetuate it. And so if we fast forward maybe 20 years or so, I think there's going to be major shifts in the world. But objectively healthcare is going to be substantially better than it was today because of AI and how you can actually create that value at scale, right? Yeah.

Craig [42:47] But the technology certainly helps and, like, I see so much potential just in terms of meeting the customer needs. Exactly. Yeah. You know, we have large call centres designed to be able to engage with the customer. Now you can leverage AI to a degree, not to get rid of the people in the call centre, but get the people in the call centre doing more value-added work. And then AI can help with a lot of the things where it's not just about, and we'll probably always want to keep a human being on the phone. I think it's nice to have a human on the phone to be able to interact with, but then they've now got to go here and do the system and do the system. Now you can use AI to do a lot of that admin work for you, and it just speeds up that process and being able to just get more efficient. I think those are the things that we want to see AI growing. But I mean, I think in 20 years time, we're going to be in a significantly different space. I've been asked this question before by people at work.

Craig [43:42] Do you think AI is going to come steal your jobs? And I always think about the motor vehicle industry. There was this time where I think it was around the 70s, 60s, where they moved from these production lines with lots of people working to robotics. Mechanised,

Francois [44:03] Yeah. Mechanised.

Craig [44:04] things where it's no longer just people working and building the cars. It's now a bunch of robots building this assembly line. And did people lose their jobs? Yes. I think there was an initial period where a lot of people lost their jobs through this approach. But if you look at the industry now, more people are employed in the motor vehicle industry than ever before in history.

Craig [44:24] Human beings have got a knack of finding ways of, through innovation and technology, of finding relevance in different ways. A hundred percent. The jobs will change. The way that we think about it will change. We just got to be open to that idea of what skills do I need to learn to be able to adapt? Yeah. Because it's going to change.

Craig [44:41] And from a software development perspective, my skills are going to have to adapt with it. And I need to rather be at the forefront so that wherever the industry goes, I can still contribute and add a lot of value to it rather than feel like, hey, I was going to just get my job. Because I'm not doing anything to better myself.

Francois [44:57] And that's also the thing, right? I think one of the paradigms that I'm seeing a lot of leaders dealing with at the moment is, how do you lead for the future? You're going to need to live in the future. Yeah. And you need to get your hands dirty. We've got group CEOs of very, very large enterprises, like writing software today.

Francois [45:21] Going back, I mean, the Turbo Pascal days, and they're like, okay, well, now I'm going to do it, but at a plus-plus level. Yeah. But the one thing that struck me about you, Craig, besides the fact that you're just like such an interesting person to speak with, your background and knowledge around all of these different fields creates this nexus point where you've got insights that's not necessarily always accessible to everyone.

Francois [45:46] You maybe call it experience. In my view, that's the outsider effect compounded, right? Yeah. And I think one of the things that's quite interesting about how you look at businesses in general and how technology works is that you are so customer value focused. And for a technologist that's worried about the ones and zeros and the object orientatedness, feeling proud about how well that software is architected, focusing so much on customer value tells you actually something about the industry, right? And I fundamentally agree with that because in my view if you think that technology and business is separate, A, you're delusional, and B, good luck. Yeah, right. And so when we think about this challenge that has happened today, we don't work with plumbers today that don't have a website or a WhatsApp chat.

Francois [46:50] And 20 years, 30 years ago, it was perfectly fine for them to have a phone and give you a handwritten invoice. You'd be perfectly happy with that, right? Today, that's almost like unacceptable. And so what we're seeing here is that technology and business is so intertwined that one cannot exist without the other.

Francois [47:12] And so this is why your book is so, so, so interesting to me because it's really about confidence in engineering and enabling business to do what they should. But taking the approach from an engineering standpoint to actually say, well, how do I engineer with confidence so that we can create the value for the outcome?

Francois [47:37] And I'd love to just get your perspective on, A, how you've been inspired to actually write the book. What are some of the key practices that people may be getting out of the book when it drops? I'd love just to hear a little bit more because this is so interesting.

Craig [47:54] Sure. I think for me, I've always been quality minded in my career. I mean, like you mentioned, I started out as a software developer. I went into actual testing and QE work, worked as an architect. I've led teams. I've been in large parts of the different roles.

Craig [48:13] I haven't just always fulfilled one role, which I think has partly helped me have a different sort of viewpoint when it comes to building software because I understand the other parts of the value chain of how we get there. So quality has always been something that's very important to me. How do we produce software that's of a high quality?

Craig [48:32] Maybe it's a personal pride thing. I want to make sure that when we deploy something, it's working. And I know it's not going to happen all the time, but I'd like to try and mitigate as much of those mistakes as possible before. And I think that's really what the book's about.

Craig [48:45] It's this notion of quality gates and how do we build systems within our CI/CD pipelines to be able to allow us to have a lot more confidence. In an organisation like Old Mutual, like I said, it can be very much, if software deployments go rocky, they question the value of what is our IT teams doing because they don't understand, partly.

Craig [49:08] And they see these things of like, you're supposed to just keep things working and this thing doesn't work. Why not? Confidence in what you can achieve is a big thing. They need to take confidence in you.

Craig [49:20] And I once worked for a company, it sounds bad when you say it, but his mantra was, engineers need to be taken for granted.

Craig [49:28] Now, he didn't mean that in that you shouldn't care about the engineers. What he was just trying to say is that if you're doing your job and your software works, the business should never know. Yeah. It just works. Because the business only notices when something stops working. 100%. They just see these things and yes, there's systems and we've got a multitude of different systems that all speak together. At the end of the day, I think all companies are tech companies, like you said. But you need to be able to have some sort of confidence or the business needs to have confidence in what the tech teams can do. And I think a lot of that then boils down to, well, how do we produce quality in the process?

Craig [50:08] And so in the book, I'm really just trying to break down, well, what are the quality gates that you can do and build into your pipeline to help you along the way? Have you checked your code? What measures have you put in place? What guidelines have you put in place to ensure that the code is working to some degree? When are you doing your performance checks? When are you doing things? What are you, you know, a common thing that, like, organisations struggle with is their test environments. Their test environments are so different from production that inevitably it's like, what's the point? Because then you go to production and you're finding all these issues because your test environment is so completely different. So how do we bridge that gap and how do we build the quality gates as well to be able to build a bit confidence in our test environments. And part of the problem is companies have these test environments and the test environments are down half the time. I've worked for organisations where the testing team got frustrated all the time because code would be deployed and their test environment was down half the time. But there's ways of preventing that from happening.

Craig [51:06] And again, it's this whole sort of systems where you can build quality gates to check the code, but you can also build quality gates to check the environment before you deploy and then after you deploy and then roll back. All these things are sort of part of a process of, and it can all be automated to be able to help produce better quality code. Because at the end of the day, if we deploy software, we should be comfortable that you should be able to deploy.

Craig [51:28] I'm someone that says, don't wait for the weekend to deploy. You should be able to deploy comfortably at one o'clock in the afternoon.

Francois [51:35] Yeah. Which strikes fear in most people.

Craig [51:38] And I know that it works. And if you tell that to people at Old Mutual, they'll be like, oh, no. No, no, no, no, no, no. Don't do that. But that's how it should be. If we have full confidence in the work that we're doing, you should be able to drop the deployment at any point in time and no one notices. And I mean, to a degree, you have an organisation like Old Mutual which maybe operates in sometimes different hours, so you maybe have windows. But like, I mean, I worked for AWS for a period of time in my career and that's a 24/7 business. No matter when you deploy something, someone's going to be awake in your software and awake online. So you have to just get to the thing. And not that they actually did a good job all the time. They also had a lot of problems and there's a lot of bugs. But you've got to build that trust in the system. When I'm deploying something, it's got to work. You can't wait for the perfect window. And I think it's just that mindset shift around, well, how do we actually take what we're doing and enforce quality in the process? And I think particularly at scale, I think one of the reasons why this is so important is if you're working in a small sort of startup, sometimes it can be a little bit quite easy to try and do it for one small application.

Craig [52:42] When you've got like 200 different teams, building different types of software across an organisation, that can be chaos. And you need to try and put some level of confidence in it and build some level of confidence so that the business can trust what you're building.

Francois [52:59] Absolutely, yeah. Especially in today's day and age, right? And everyone says, well, you can use AI to do this, right? The answer is absolutely, you should. But it's not going to make the problem go away.

Craig [53:11] Yeah. One of the things I've told people is, and sometimes before you start playing with AI, actually bolster the quality of your checks, because AI is going to produce volumes that maybe you can't quite control. It's going to produce a lot of stuff and you need to be able to catch when it's going wrong. Now you need to be able to then ensure, okay, well, we've got all these checks and we've built all these checks into our process to catch them, whether it be security scans, whether it be unit tests. And I find a lot of developers are lazy. Like, I'll just get AI to write the unit test for you. But it doesn't understand the context, because AI is going to write your unit test based on the code.

Francois [53:48] Oh, yeah.

Craig [53:49] But what if the code is wrong? What if the problem you're solving is wrong? And does it understand the context of the data and what your customers are doing with it? So you always need that level of human sort of...

Francois [54:00] Supervision.

Craig [54:01] Supervision to be able to say, well, this is what we need to do. And then you work with your teams to be able to pull that out. And so I really feel like putting the effort upfront, understand what it is, build these checks in place. Because once you have them all there, then you can play with AI a little bit more freely and go, you can use it because you know what? If something goes wrong, we'll catch it.

Francois [54:22] Absolutely, yeah. And I think also, like my view is that AI at the moment is the world's best software engineer locked in a box, and it can only send and receive messages or edit files. And so you need to engineer that context, but also you need to help it understand, like, what are we trying to achieve here? And by virtue of being the world's best software engineer, it can still make loads of mistakes.

Francois [54:53] And so there's loads of these challenges that organisations need to go through. But it's a fun journey, hey?

Craig [55:00] It is a fun journey.

Craig [55:01] And it's multiple different things. I mean, a lot of the problems are because we're all solving different problems. A lot of the issues are necessarily code. There could be something coming through from a requirement level or something, but it is. It's a fun journey. I love the fact that it's actually moving as fast as what it is because I think that just, to me, just keeps things fresh.

Francois [55:22] Curiosity.

Craig [55:22] That curiosity is great. I think it's going to really just ramp up what we can do from a technology perspective, what we can achieve, but it's just doing it in a way that is safe, got the right guardrails in place, particularly in a large organisation where it's very regulated. That's critical. And but that we take everyone along with the journey because there are multiple different people involved in building software.

Craig [55:52] And someone wants because we were devising what should the future engineer look like, and would the future engineer just be one super engineer with an army of agents just going and building? And I was very hesitant to say, I don't think so, because by yourself you become an echo chamber. Yeah, you need to still have a team of people working together to be able to bounce ideas off, to challenge one another, and someone's able to check your work. I don't think we're going to go away. Maybe teams will get smaller and their output will just get better, so you maybe don't need seven people in a team, you can get by with just three. But you still need to have some level of team interaction, because I think it's dangerous to assume that one person with his army of agents is going to just go out and absolutely produce great software. Because they might produce great software, but there's going to be mistakes along the way, and how do you hold that person accountable? How do you help that person? And again, that echo chamber effect of they're starting to go down this thing and they're not actually maybe questioning things enough and asking those questions. Someone needs to go and actually ask the questions of, actually, why are you doing it? What's going on there? I don't understand that. We need that. So, can I go back?

Francois [56:54] So wholesome, coming back to high quality questions again, right?

Craig [56:58] Exactly.

Francois [56:59] Craig, I'm super curious if there's something that you could impart on non-technical leaders, maybe a mental model, a concept that they should be considering, maybe something completely left field. What would be the message that you'd leave them with, especially given your multi-decade career in a very, very large enterprise, dealing with very complicated challenges across an organisation that is federated, that's got many different, 200 different products. What are some of the things that you'd like to share with a non-technical leader to update their perspectives?

Craig [57:37] I think it's always challenging because everyone sort of comes from different angles and different lenses. Like your CFO will be focused on the money, your CEOs will be focused on the strategic direction. I think fundamentally, every business has now become a tech business.

Craig [57:52] And I think this is the mistake that I think many large companies still make today, is they're still trying to shape their organisations around the old view of customer interactions and talk most. And we've seen this at Old Mutual where they're structuring against, they're structuring the company around how do we engage with our customers and how we do this, which is not necessarily wrong and a bad approach. But in a tech-oriented company, you start to ask yourself more platform-specific questions. What are actually my products and my platforms that I need to build? And you start to shape it differently.

Francois [58:29] What is that tech layer that transcends?

Craig [58:31] So that tech layer becomes more important. And I would say just ensure that you give them a big enough voice. I think in a lot, in the small tech startups or some of these smaller tech firms, that's not a problem. But I've seen a lot of South African organisations, these larger organisations, again, IT is this thing on the side. And yes, you will have a CTO come in and be a part of the board or sometimes be a part of the ExCo to be able to try and shape things.

Craig [59:02] But I think they're often not empowered enough to be able to make those things. And I think it's just like, we need to shift and understand that technology is that critical to everything that we're doing. And if you're not going to embrace technology, you're going to be obsolete in 20, 30 years time, even if you're like Old Mutual that's been around for 181 years. That doesn't mean that you can't become obsolete if you don't modernise, because that 181 year old business carries us. But if we're not getting youngsters to utilise our platform because they don't like the tech and it's just too old fashioned for them, what's the point?

Francois [59:36] Exactly.

Craig [59:36] So we've got to do those things and we've got to shape ourselves.

Craig [59:39] But I think the other thing as well that I just leave them with is just, again, just don't be afraid to shake things up and try different things. I think disruption is going to come and we see a lot of organisations come, or startups come, and disrupt ideas. How do you bring that innovation within your organisation? Focus on that innovation, spend more on innovating and R&D. I've seen it even in our organisation, they were brilliant bright minds, and I think every organisation's got them. There's brilliant bright minds, you've hired them for a reason. And then they've got innovative ideas and it goes to die somewhere. We've had that problem, you know, where you have hackathons and some great ideas come attack the songs, but most of them just tend to die because we couldn't find enough business leverage, because it wasn't considered a part of someone's P&L or someone's sort of product roadmap. But there's a lot going on, but like, how do we disrupt the market and allow for that to happen? Really invest in those things.

Craig [60:41] I was at a leaders forum a couple of weeks ago where we're discussing things with a bunch of leaders, and one of the things came up about how much time do you spend in training, and there were some people saying that with AI training needs to increase.

Francois [60:54] Absolutely, because the velocity is so high.

Craig [60:56] Because it's changing so fast, it's almost like instead of saying 10% of the time now it's going to training, it's almost like 20, 25, 30% of a person's time actually to be devoted to training. And I think that's still something which a lot of the big organisations aren't doing.

Francois [61:11] I can tell you, I spent a very big amount of time personally on just training myself. And I think that's the key.

Craig [61:19] And I've had the privilege of being able to do that. I think because in my role, I'm not 100% delivery focused. I have the ability to be able to say, oh, something new has come out. Let's play with it. There's a new technology. I'm going to install it and see what it's like. I mean, security doesn't always like you because you just installed something that they didn't.

Craig [61:36] Maybe you shouldn't have. But the point is we tried it. We try and do it in a safe way that doesn't cause any problems. But we've got to do that. We've got to do it like if there's new models. I'm like, let's get the new AI models out there. Let's constantly play and learn. I mean, we've already said we're going to handbrake Mythos, that new one from...

Francois [61:56] Anthropic, yeah.

Craig [61:57] Yeah, from Anthropic. That's supposedly very dangerous, but we'll probably handbrake that one if it's that dangerous. But I think for the rest of them, we're definitely going to try and continue to just keep things fresh, keep things innovative. There's new technology that's coming out. Start now.

Francois [62:09] Absolutely.

Craig [62:10] Don't wait for your competitors to do it.

Francois [62:12] Start now. Because they will.

Craig [62:13] Oh, they will. Absolutely. And these people are going to come and disrupt the market. And I mean, we've seen it. I mean, Old Mutual is a large organisation. But we know that there are insurers that can do more for less.

Francois [62:24] And that's going to be the pattern, right?

Francois [62:26] Craig, this has been such an interesting conversation, like just going full circle from early career development to some valuable lessons that transcends the bounds of an automated house and how those mental models can be applied, starting with that one light in the Big Bang project, and then really talking about how businesses transitioned into technology companies and how technology teams needs to have that confidence and your book really delving deep into that topic of equipping technologists with the ability to give business confidence. Craig, it's been such a pleasure. Thank you. Yeah, I think full circle all the way. Absolutely.

Craig [63:13] Thanks for having me. It's been great talking, and I think it's really exciting topics.

Francois [63:17] Very, very cool. Well, there you have it. If you've been staying to the very end of this episode, I'd like to say thank you. And clearly you enjoy this content, so consider subscribing. Thank you. Have a great day.