Panel – Engineering in Flux Skills, Teams, and Tech

This panel discussion delves into the evolving role of AI in engineering and development processes. The speakers, all CTOs from various tech companies, share their experiences with implementing AI, emphasizing its impact on productivity and decision-making. They highlight the importance of balancing innovative AI use with accountability and governance, noting that while AI can significantly expedite coding, it must be accompanied by human oversight. The talk also explores the culture within engineering teams regarding AI adoption, the importance of training, and how organizations can adapt their frameworks to leverage AI effectively. Ultimately, the discussion aims to uncover how AI is changing job roles and engineering practices while ensuring teams remain responsible for the quality of the code produced.

So, we've got a terrific panel coming up here. Tavier Taylor, board adviser and CTO at TFM Innovations. David Kavanaaugh, CTO at Tillow. Kaiser Mazar, CTO at IG Group. And moderating our panel today, Glenn Roberts, CTO at Fenion. Please join us on stage. All right, Glenn, I'll turn it over to you. All right. Hi everyone. Uh it's been a great two days so far. Um as you've noticed

a lot of AI has been talked about over the last two days. Uh today's no different. So uh today's Yeah. So rather than what's actually says up there, engineering flux, AI is actually rewriting our jobs, not just the code. So today we're discussing what has changed, what's broken, and what we're doing differently. So I'll allow the panelists to introduce themselves. So uh Kazir, please uh go ahead.

>> Yeah. So my name is Kais Mazar. Um, I run UK and Ireland technology for IG group, which is a trading platform. Um, and I've got people distributed around the world. Um, and have um been using AI in the or for for quite a while now. Uh, but it's still a learning journey, so still lots to learn. >> Great. David, >> thank you. David Kavanaaugh, CPTO at

Till as of recently uh a fintech um about 10 years old in uh in the gift card and reward space. Also I am an adviser to a series A company called Just Move In. Um between the two we're doing different things in AI but of course always always learning. >> Great. And Tavier. >> Hi Tavier Taylor and I am actually a fractional um CTO and board advisor.

Um I work supporting uh boards and execs around digital transformation and AI governance usually when the transformation has gone wrong. um and to make sure that there's governance and accountability and propping them up and setting them up for success when I leave to make sure that they have decision ownership um as well as transparency in the organization around whether it's um upgrading legacy systems or either accountability

and their day-to-day operations. >> Fantastic. All right, then. So um let's start off with probably most interesting question. Um start off with Kazir. Um so what yeah what what has AI actually changed in your day-to-day over the last year or two? >> I think um the interesting thing is it's always changing. There's there's extra stuff that's always uh you know something new that we're introducing. Um, but

I think one of the things that's been really quite exciting is the way that we've been able to force multiply our processes and uh force multiply the the output that teams do. Uh, but the real real kind of big changes around how we can change the outcomes. So doing a lot of work to kind of reorientate the way that teams think about uh progress and getting things

done. Um, and so yeah, there's there's lots of benefits that we can get, but if your processes and your you know, your ways of working are not set up correctly, you can just force for force multiply the bad stuff. So that's been a quite a interesting kind of journey that we've been going through. >> Sure. And you gave me an example previously of React Native being a

change for you. >> Yeah. So we are replatforming our technologies. So we moved from native apps uh and moving towards uh a React Native and and React uh websites. React Native on the apps. Um, and so we've got some native uh iOS and and Android engineers that are using um AI to generate the React Native version of the code. Uh, and that's been super super uh smooth

and easy for them to kind of translate between the two. They know the existing apps really really well. Um, and they've been able to get up to speed to create um a React Native version uh without necessarily being a super expert in React Native itself. uh but the transition has been way way faster than if uh they were expected to learn that from scratch and then uh

and then redevelop the platform. >> Yeah, that's definitely a big enabler. What about you for you David? >> Change in the last 12 months. Um I think we're at the stage where I can say that that's an AI enhanced photo of me for one. Um but let's get let's get real. I think um without getting too dark, I think there's a bit of a division opening up

that I see in in our organization, but when I speak to other leaders as well between um people who like to code and people who like to build and and people that are um hanging on to the craft of coding and resisting AI. Um and then there's some wonderful examples of people who who aren't doing that who who take it as an opportunity. um to really build

things very quickly, get things to market, split test. Um one engineer in our uh org, for example, for the last three months has um AI generated 95% of his code um and approximately doubled his output um for a low a low cost of credits as well. Uh and then then you have, you know, you have a spectrum, right? So, um, yeah, I really want to talk more

about that, you know, how how how do we how do we bring people on the journey? Um, both sides have have arguments and considerations. We should listen to both sides. But, you know, I know where I know where um where I where I sit. I I'm um energized um to have come from a traditional engineering background have naturally drifted away from that with leadership and now I

can uh now I can somewhat get back into it and and lead the way on that. So it's it's an exciting time to be alive. >> Sure. Would you say you're getting closer to engineering than you were before because you have to play around with claw code yourself? >> Yeah. Yeah. Yeah. 100%. Yeah. And I'm really scratching the surface and I'm a bit late to the game,

but you know, um, the reason I don't look like my AI photograph, like this weekend I was down a rabbit hole with Claude Code and my wife is like, "Where are you? You're not present." Um but yeah, it's it's it's yeah, it's um yeah, the Bob Dylan song, the times are changing, uh springs to mind just um yeah, it's you know, if you think about it, um

um we'll come back to another conversation, but in another question, but I have a lot to say on the subject. >> Great. Yeah. Uh and Tavier as a fractional um how's your world changed? >> Yeah. So my role I sit just above the engineering level and responsible for some of the teams but I have seen where you have the old school we're not using AI and then

you have the other extreme where people are using the AI but what surprised me the most about it is that those who are using AI um the level of dependency that they have on it without questioning it and without judgment and then trying to backtrack it and say hey look it's fine to I'm absolutely happy for you to use AI, but you need some accountability and ownership

like why has this failed? Like you can't just depend on it without questioning questioning it. But I found that some of them will just put in the code, not question it, and not reassess the risk once they before they put it into production. And then it's like this is why I'm here because we need to take ownership and have some responsibility that if you're going to use

AI, you have to be responsible and own what it is that you're saying you're going to put into the development before actually doing it. >> Sure. Yeah, definitely. Over the last couple years, I've seen the same where it's almost like using AI, I've passed the responsibility over to the AI and obviously we can't allow that from. So staying with you, um, so everyone has a productivity claim.

um what are you tracking you know how much of your code is AI generated David just gave a short >> yes so for me it's about the how many times do you have to change it and the failure rates um for AI when you put it in it's like oh yeah we're increasing in speed so that's fine the time it takes to go from you know um

testing and development into production but it's also the fact again it's like okay it's in production but we're failing something is broken. And again, going back to that governance layer, it's it's like come on guys, think about this. Like it's not just like looking at it from this narrow lens and then you put it out there and now you broke something over here and this is why

for in my case particularly as as a fractional CTO when I come in the transformation is delayed but the developers are working at a faster pace and they were like well why are we behind on the transformation? Again, it goes back to that accountability and actually assessing the risk and also I know this is coming up later is about teaching engineers about judgment and that layer when

you're interviewing and hiring engineers in and also setting them up for judgment and accountability skills as well. >> Great Kazir um essentially for you um yeah so how much of your code is AI generated performance improvements? So we have seen we've done like a pilot in one area of of the organization. That's a lot of like legacy code um and areas of code that takes a lot

of time to to develop and get out the door. Um we've seen massive improvements in that space. So we've seen maybe 4x maybe up to 8x in some of the engineers and some of the teams. Uh but going back to to to what Tavia was saying um there's a lot around how we measure that that success. So looking at dorometrics um also changing our ways of working

um so moving more towards accept acceptance test room development uh moving more towards XP uh so that we are delivering things iteratively uh getting things out to production with good metrics and monitoring and alerting and all that kind of stuff uh has enabled the team to move faster. So, you know, we could crank out loads and loads of code and and we saw uh there was a

talk earlier about, you know, some of these um some of these agents will generate, you know, a million lines of code versus, you know, far fewer in in other agents. We're not measuring how much code you get out. We're measuring the output uh from a from an outcome perspective. And we're seeing really great improvements there. >> So, like a 4 to 8x outcome in certain >> in

certain pockets. So that has like set the benchmark for the rest of the organization to try and meet. Um so yeah we are we are tracking metrics. Uh we've got a uh an AI boot camp that everyone goes on so everyone's got a level set. Um and then past that point people can really dance in the in you know in the moment and and see what they

kind of develop for their particular areas. We've got you know some platform teams, we've got some front-end teams, we've got uh teams that deal with very complex systems and some teams just that just deal with UIs. Um so we're not going to see the same productivity gain across the lot but we're trying to set the bar really high and see how far uh the teams can reach

>> 4x uh benchmark is very very challenging target so yeah I'm impressed by that uh David from your side >> from my side um yeah I'll come back to metrics question in a minute but um you know take Laravel upgrades um that happened recently traditionally that's been quite a painful process a lot of people involved um bugs that slip through when the when it hits production. We

we did it seamlessly in uh in days rather than weeks recently with the use of AI. And the engineers even admitted that some of the bugs that were caught they they wouldn't have caught them uh in in in the wild. Um going back to metrics, I think I'll be really honest. I think in product engineering, we've we've to different degrees, right? I'm generalizing but we've got away

with it to an extent about how we measure productivity. I don't like we've got door, we've got space, we've got many many frameworks um commercial and marketing and they're they're really tied to numbers. We we don't tend to get you know we have some quirky founders and stuff but we don't get tend to get um um anchored to those. You know, what I would argue is that

we need to really um re redefine metrics from the ground up, a different SDLC. You know, I I'm old enough to remember sort of com to decom to SOAP, mobile adoption, cloud adoption. And if you think about those um they were quite slow in pockets and they took off over over time. But AI, we're all doing it together. Um there's this thing that economists call the the

productivity paradox. And if you look at like electricity, which I don't remember when that came in, um but uh when that came in, they came into Victorian steam factories and the productivity gains weren't realized for about 20 years. Why? Because >> they had the same old pulley systems and steam in the middle of the of the factory. And uh they didn't redesign the factory around electricity. And

that's why in the 1920s you saw Ford and other companies just, you know, the uh productivity exploded. And I'd argue that, you know, we need that sort of a shakeup here because, you know, we're kind of trying to shoehorn AI into uh a craft that has, you know, been absent of AI for for the last 20 30 years. And it hasn't been long, right, since we've been

writing code. We we use punch cards. I don't remember that either, but I've heard I've heard tell. So yeah, a shakeup. Um, and quite honestly, we're, you know, to finish my point, we are we're trying to divine define um, an operating model um, not just for engineering but for product and design as well where we're we're more explicit around that because there's fear, trepidation, and people just

aren't aren't in in our teams aren't mind readers. So we have to we have to sort of set that direction and and let let people experiment and build build their own SDLC's and their own their own pockets of of of uh capabilities. >> If if I could add a bit to that. So the really interesting part around how the manufacturing um you know industry didn't change uh

much one I think one of the the big changes that organizations will need to go through is realizing that engineering is no longer the constraint it's no longer the bottleneck and so when you have got product road maps that look years in advance and uh they're making all these assumptions but they are large you know big chunks that they're trying to get out the door uh when

you can do those things much faster. what happens. Uh you know, you might be tempted to con like con can con constrict that uh roadmap into many things in parallel, but actually can your customers keep with pace with all of that going out the door and you might end up with uh the the paradox of choice? uh when there's too many uh things for customers to learn,

especially if they're public facing customers, um can you degrade customer experience by putting too much stuff out there uh and not necessarily having the um the muscle memory of testing and learning and actually, you know, having really good metrics that give you leaning indicators and lagging indicators that might come again compressed. uh if the organization is not set up that way to test and learn, you might

end up you know pushing out lots of engineering code uh but it not being as valuable as you might think it would be for customers and actually quite jarring for them. >> Great. And so for you Tavier um where do you draw the line on this? So what when you let AI actually touch? >> Well my thing is not about not letting letting AI touch something. I

for me as long as there's a human that stands behind it you can put what you like out there but you need to stand behind whatever you're coding. So for me it's like fine go ahead. I don't want to set a restriction on saying oh you absolutely cannot do that because then it kind of puts you on the back foot. So we want to be innovative we

want to keep producing and we want our engineers to feel like they have autonomy but with that comes accountability. And so for me it's like fine do it but if it fails you own it. So it's not really an absolute not well I say that if my client is in a regulated environment obviously there's risk around it but if we're willing to take that risk at the

end of it if it fails who owns that responsibility who's going to be accountable for the failure as well as being you know taking on board the success and that's the way I feel about it rather than saying let's be restrictive. >> Sure. I mean, as we just saw a talk about interview processes, would you advocate or discourage AI being part of your recruitment process for an

organization? >> I definitely would advocate for it >> as long as there's still the human oversight >> as soon as long as there's human oversight. >> Yes. >> Cool. Cool. Um, Kazir, where would you draw the line? >> So, I think my my view on this is changing on a daily basis. Um, so one of the things that we've done is we've left shifted a lot of

the kind of understanding of our customers. So we're moving towards acceptance test and development. We're moving towards XP processes and practices so that engineers really understand our customers and getting more in touch with them. Um so that's one aspect so that they know what they're producing is what's meant to be produced rather than in the old world of just getting a ticket you implement whatever's in the

ticket and you're done. They need really need to understand the wider context. Um I think the other aspect is really around um how do we uh how do we put some uh guard rails around our um code. So having agents that uh and MCPs that really uh ensure that we're not introducing vulnerabilities, we're not uh you know reducing our performance so on and so forth. Um but

the current conversation that we're having in our techt is you absolutely need to understand what code is going out the door. Uh but when we get better uh um better agents and better capabilities of producing even better code um does it become more about understanding and proving that the tests are correct and that it's following certain constraints and then the code you become less uh you know

intimate with because your constraints are telling you that the code is working correctly. So you kind of almost like how we don't know how to do assembly code anymore. Um you know you extract above and you set your constraints in place and as long as you can prove that the the code is operating within those constraints you can ship it without understanding the you know thousands and

thousands of lines of code underneath. We're not there yet. Um, but I think I would love to, you know, explore that a bit more and, uh, not only see what other industries are doing, uh, but see how we can apply some of those practices in in less risky areas of our business and see how we get >> Great. And David, any risk areas that you wouldn't let

AI go anywhere near? >> Um, I think, uh, I think my view is changing daily, hourly as well. uh even last night um went to dinner and we're talking about the the very subject and somebody said see I wouldn't let AI near my alt service for obvious reasons. Um but then you know I think we've all seen long pull requests that have had architects, staff engineers, you

name it that have reviewed it and they have went out and they've yeah they've caused havoc. So um I think uh the guard rails there are really important the iterative process around how we use AI so that it's um it's it could be you know it's built by AI but we we you have ownership um on that when it goes out into the into production um it's

it's it's it's tenuous but you know we all we all um uh you know we I use venion Uh and um you know we we we we pay for a service um those engineers are great by the way but uh we we you know they they come they go um for specific projects uh but I and the team own the output of that code and we wouldn't

let them just uh just just just do what they uh what they've done in different places because we all have different systems and ways of doing it. So, you know, somewhat like that is what I would treat AI. And to to finish on that, uh, I think, yeah, I think I'm more and more liberal every day with what I would let AI at. But guard rails, guardrails,

guardrails. >> And just to add to that, just not just the guardrails in my experience, um, especially around legacy systems where where I tend to operate is that you have engineers, there's no documentation. Whereas if you let them have AI, you have the documentation, someone else can just step in. But I've been in a lot of situations where we've come in, you have this engineer, everything is

in this one engineer's head around this legacy system that has been built into a Frankenstein and nobody knows because you had this engineer working on it, that engineer working on it, and the code is a mess. And so you can't bring in someone in to kind of sort it out. It's like, okay, we just burn it down and start again. So I think by being a little

bit more relaxed and more li liberal with it, you do have like you you build this this agent and then you the next person comes along and can just kind of take it over. But again having the guard rails and that ownership so that if that person leaves or whatever reason they're no longer with the company, you don't have to then come back and say, "Oh my

gosh, we don't know where we are with this and now we have to now recode something else and bolt on to this." And so I think having that makes it more um simplified in terms of the tech ecosystem. >> Just just to add a bit more onto that actually. So we've got some green field, we've got some legacy systems um and with our legacy systems, we're going

through a process of modernization using um AI and some specific squads that are uplifting those services. And one of the kind of the debates was do we kind of take a really unloved service and completely modernize it so that it's got brand new everything um or do we do it iteratively um and so there is still some understanding of what the service is doing as we kind

of iterate. Uh but I think the key thing that you you touched upon is you know getting the stuff out of people's brains getting it into tests or getting into an agent so it can reason about whether the right thing is happening. Uh we did a really cool bit of work where we um we created we used AI to basically find all the touch points of services

with other services and stuff and and inspected the logs and basically figured out how the web of all our services and how they they stuck together. Um and these things are eye opening. Yeah. Right. And you don't realize just how much sprawl you've got. You don't realize that there's like extra connections in all these different places. So I think iteratively kind of massaging these things into the

right place is definitely a way that we're going and not trying to move towards a big bang. It's just the pace of the iterations are much faster these days. >> Yeah. Yeah. If I could add to that as well, you know, the uh we've all seen monoliths that uh fear and trepidation and loading to to go in and uh find out how it actually works. And the

bigger it gets, the kind of harder the the problem is and the bigger the elephant in the room. And you know, we we've acquired some businesses and um some code bases that have been used by an external agency is no longer there. And we've had some really good success in just what you've you've just spoken about. Um where uh it's like where do we start? Okay. And

let's get the cursor going. Takes a few few attempts to it times out, but it runs through the monolith and it it gives you some starting points. And sometimes that's what you need. The first step can be the hardest. And sometimes AI can just take you on that journey in in those examples which is which is great. >> Great. I've got loads of questions but I've seen

several come through on the board. So let's start cracking on through few of those. Um how do the panel find the balance between focusing on the best tools now versus in six months where everything will almost certainly change. Obviously we've already seen that with like rag being the latest thing then agentic or orchestrated AI and then I was using cursor last year. I'm using claw code now.

Um so yeah, anyone wants to tackle that question first? >> So I think one of the things that we're doing is um we're not marrying uh everything to a particular um LLM or a particular agent. Uh we're doing things in a way that are agnostic so we can replay onto the latest and greatest of of wherever anything else is. So we're trying to stay as as agnostic

as we can. Um but obviously using what we feel is the the you know the the tool of the the day. uh but not being super tied into uh you know the implementations of how it's done there. We're trying to use um standards and um and protocols that could be applied in lots of different >> Yeah. I Yeah. I mean I think there's no loyalty to any

of these AI companies right now. If there's anyone that's bad, we're willing to switch very easily and anything we build uh we always make with the mind of we can switch the model, we can switch what we're going to. >> So yeah. So the commitment and loyalty aspect of the industry is I think is not here at this point. Um so moving into the next one uh

quite relevant because we saw a great attack uh was it this week or last week. Uh do you think your teams have a proper understanding of prompt injection? Are we sleepwalking into a wave of dramatic tech disaster and as you know the one I mentioned with it as an npm package where they put prompt injection into the title, wasn't it? I managed to get some bad code

which was live for about six hours with people pulling these packages down. Yeah, I speaking from myself and my teams maybe leaving just um just move in uh who who are a smaller team um and are able to move more quickly. I think uh it's uh again a bit of a spectrum around um prompting and um understanding um some of the security concerns around that. Um we

have got you know we have got SAS tools that can kind of help us to see sock and tools like Aikido. Um but I think it is uh yeah it's an area of improvement for sure. >> Sure. I mean would you say that's a training piece or is it a tech technical challenge where we're putting guardrails in? >> Yeah I I think it's both. Um just back

to that uh sort of AI operating model which we're yeah we're um due to release across till um which will be a living document sort of principles and um practicalities on on ways of working and yeah we really want to iterate on that um as we do on our our skills and our our AI estate as well. >> Great. Cool. We we we have a um a

four-week boot camp that all brand new engineers go through. Um and existing engineers will go through that as well. It's a just a slightly more condensed version. Um and as you said, you know, continuously iterating on it as we learn more from a security perspective or various different aspects. We're continuously updating our agents as well. So the we've got agents that run in our code um that

look at things from a security perspective, performance perspective, etc. Um so I think part of it is teaching the engineers themselves and part of it is um you know developing our agents and developing our um you know the the ability for us to kind of force multiply our devs as well. So it's I think it's a bit of both. >> Yes. Same here. It's training absolutely. Um

I gave the example that you have some who are you refusing AI but those who are very eager also without the judgment and so we said fine you can use it but you have to be trained on it and that is like you don't get to use AI unless you've gone through the proper channels of of training which I think helps but even with the training I

found that sometimes there's a lack of judgment so >> sure but you still allow experimentation I assume from the early stages you just mean you can't use these tools for production use without the training. >> Exactly. >> In those guardrails being in place. >> Great. And it's great to hear boot like boot camps and those type of training stuff as well. Sorry. >> Yeah. Yeah. No, just

a boot camp inspired me to talk about our um Intel. We started we've got about five under our belt now. So quarterly what we called in the beginning we called uh engineering AI community days and what we're calling now is community days. Um, and that that's a place where we we sort of eased into AI, started to experiment, started to use tools in a in a test

environment together and um, a hackathon in in many ways, but more than that, a learning journey together and playing back that to the business. Um, and then, you know, where we are now, we're actually solving real problems. We're shipping code. um we're leaving a little bit of time in our in our sprints as well. You know, if we don't ship something in a in a complete day,

we have time afterwards. So, there's real tangible uh results for for for for the business, but that the learning and the community uh aspect is is really really powerful. I can't can't talk about that enough. >> Yeah. And our place hackathons, we do one every three months. Um I like to try and challenge them by giving them something like beat the CTO. So, I'll do something and

they've got to do something better than me using these tools. It's a great motivator to try and knock me down a few pegs. Um, and you know, we're looking at more advanced engineering stuff now, like being able to convert a cobalt application into Rust where neither the engineers don't know either language. See if it's possible. Obviously, it's nothing for production, but just to really push their capabilities

and get them to understand what is possible. Um, moving on to the next question. Uh, do your engineers really want to spend all their time reviewing AI output? How do you leverage their creativity and wider skills uh than just coding in that world? I think that's a common challenge. I think we found definitely when you first embed these tools into the system and suddenly the PRs are

massive as has been mentioned. Um yeah, your thoughts. >> Um I think for me at least I talked a bit about XP. Um, I think if we think about prompt engineering where you just prompt it once, whatever generates you ship it, then you're probably doing the wrong thing. Um, and if you're just reviewing exactly what it puts out in one go, probably also maybe need to adjust

the way of thinking about how you use it. Um, we pair with it. Um, and so we're continuously generating iterative code as we go along. um using um using that approach that engineer can can ship that code. Um but if it's something a bit more complex or a bit more in a risky space, we do do some code reviews as well. But the intent that you know

you don't understand your your code at all that's being generated and then you have to review it all in one go. Uh we're not really doing that. We're we're doing things iteratively. We've got ways for us to ship stuff in a dark way. uh so it's in production without uh anyone else seeing it. So we can run smoke tests, we can run things in prod uh to

check that things are working as well. Uh so it's just about changing your mindset with how you're delivering software uh and doing things in a smaller way and doing it more iteratively rather than it being a big bang getting all the stuff out the door in one go and and there being this big review where everyone has to sit together and make sure that the code is

all right. >> Yeah, I like that a lot. I think for me um three things um it's about taste um systems thinking and orchestration um taste is subjective but we're human um we have senses and uh we have feelings and you know we know the design language know the org um the systems thinking piece is just I simply think will'll never go away we've you know we

we've got foundations in computer science we've got experience experience. We understand uh or we should understand our business, how it moves, how it's structured. Um and an orchestration uh is is you know is a is a new a new capability right in an agentic world where you know we we use a lot of tools and we may use them together in a in a in a symphony

of of of uh solutions. Um, and I think, you know, that's uh that's an emerging um skill that everybody needs to needs to hone in on and understand and how can we pull those things together um so that they're part of the solution rather than looking at them as problematic. >> Uh moving on to the next question, Tevia probably be good for this one. So, what are

the bottlenecks in the new world with increased code and feature generation? If it's not QA, what else? Obviously, we just touched on the pull request piece. what are you seeing and how are you advising about the extra challenges by having AI in these processes? >> So for me the the bottleneck it's not so much the the code because we're moving at a faster um velocity but I

find that decision ownership is not keeping up. So what I mean by that is when we're producing things that are now going into production at a faster rate and then the accountability and saying well who owns this and the bottleneck comes when people are like well I'm not sure and then there's a bunch of fingerpointing going on. So I'm finding like the engineers are doing their jobs

and it's like oh we're producing but it's like okay but who owns this in terms of the business on that side and so I just kind of find like it's more about the decision owner neck decision um decision ownerships becomes the bottleneck now that's what I'm finding in in my current environment. >> Cool. Um so in our world um as I mentioned before uh if you are

no longer constrained by engineering then your problem moves somewhere else and it becomes the ideas that have been generated and whether you thought those things through you know what your leading indicators are that these are the right things that customers actually want and you got lagging indicators to tell you that you've you know you've achieved your goal. Um one of the other bottlenecks uh now is things

like compliance and finance and and all that kind of stuff. So uh one of the changes that I'm making in UK and Ireland for IG is to move towards them uh the initiatives not being product and tech initiatives but being the organizational initiatives. So everyone has got skin in the game. Um and people are brought on as part of the discovery phase. Um and so we are

moving as an organization to deliver uh a new feature rather than than it being concentrated in technology and and uh and product. uh and that way we can kind of unlock um compliance being part of the journey uh finance being part of the journey uh security and so on these other organiz uh other uh divisions in in the organization not being a barrier to release but actually

being part of what we're trying to do as an initiative. Uh so that's an ongoing journey but um that's a key thing that we're trying to to move towards and that means we get better acceptance criteria, better acceptance test criteria, we automate that through through coding uh and then we can fly out the door uh without any uh major worries. >> Great. Cool. Um so just skipping

to the second one actually because this lines up with one of my questions. So um are you still hiring junior engineers? How do you see the career path changing or how have you seen it change over like the last 12 months? Uh how do you set up juniors for success? Uh David, >> yeah, I I am not hiring junior engineers, but I do want to change that

narrative. Look, I would hire a junior engineer over a senior engineer in the following circumstances. If um yeah, one of my interview questions now is do you like code or do you like building things? So I really want to look for that builder mindset. Um and I'm being divisive of by saying there's two types of engineers. There's many types of engine and you can be both types

of engineers but um if I speak to a senior engineer today and they have skepticism or aren't using it. Um but by the way last year you know my views were different and and next year they'll be different again. Um I I wonder you know why aren't you using it? If if you're not using AI, what else are you not using? Um why is that a limitation

for you? Is that the sort of you know a fixed mindset that you're not going to come on a journey with with us and what we want to do? So you know I I would uh my heart bleeds for graduates um these memes going around about computer graduates, computer science graduates, you know, working at McDonald's. Um you know, certainly wasn't a lot of people in in the

rooms experience. So I really want to lean into that because as as as we all know like these token costs will go up. Uh people will age. Um the knowledge will you know dwindle from our industry and there's got to be a there'll be a correction at some point. So we need to nurture um uh new talent and um bring in engineers who have got that that

mindset. you know, not vibe coders, but they are um uh AI engineers in the truest sense, in the in the holistic sense, >> without the bad habits of being a traditional coder. >> Yeah. Yeah. I I was I was a poor uh poor computer science graduate, you know, Stack Overflow and code project, stuff like that. Uh you don't want you don't want me at that age, but

yeah. >> And I agree with that. I think um how do we set them up for success is about teaching them judgment skills. I find with seniors they have a certain mindset and they're like set in their ways whereas juniors come in they're more eager but it's about coaching them as well and saying here's where you use judgment here's where you teach them accountability whereas seniors are

like I know everything. So there it is a different mindset and they're a little bit easier not to mold to as to say but they don't come in with these preconceived notions and judgments around how things should be done and and they're more flexible I find from that >> I I think like in a year's time we'll be probably doing the opposite. We'll be hiring loads of

juniors and saying we don't need all these seniors because everything's so great >> uh and the things that get generated are really great. So I think the the real level setter here is can people solve problems and are they able to take a very complex problem and decompose it into smaller parts. Um I think that's the the the thing that I'd be looking for in junior engineers

is uh how do they approach problems rather than how much code can they crank out. Um so yeah I think we'll have a very different conversation in about a year's time. >> Okay great with only a very short couple of minutes left. Uh just one of my questions to finish off then. Um, everyone's invested in AI tooling, training, and process change. What do you expect to see

as a benefit to the business in 12 months time? >> I'll go first. I think um in 12 months time, I think we should have better accountability and ownership. So again, it's always been from my experience is like we always can point at it and say, "Oh, you're not the reason this is behind is because you're not producing fast enough." Well, we've taken that out of the

equation now with AI. So for me it's about making faster judgment but better judgment as well about what you said earlier about do our customers want this and now that we can give them a lot more is and about how we approach what we're producing um for our customers and and how we think about that process even if we do it iteratively it's like should we be

doing it and how do we do it >> yeah I think the it really the answer is a classical engineering answer which is it depends. Um, and I think the real deterministic factor of whether you're going to get the ROI or not is how customercentric the business is. The business doesn't really understand their customers and never really had to because they were operating at such a slow

pace that everything that they were releasing was going to be uh, you know, a home run because they're they're behind their competitors. if they are not constrained by that anymore. It just really depends on how much they understand their customers and how much uh they can kind of relinquish to using metrics to tell them what to do rather than you know what they dreamed up themselves without

uh you know asking their customers. >> Great. David finishes off. >> Oh, I don't want to have the last word because uh the the the talk here has been fantastic. Um but but I I I just simplify it. Um I was just thinking about that as you asked re revenue and reliability really. Um can we increase the the the value of our for our shareholders and for

our business and and and obviously can we can we do that reliably and consistently and um um without without falling off the edge of a cliff and uh creating catastrophe for uh for our production systems. But yeah, >> brilliant. Well, I think that's all we've got time for. So, thank you very much to our panelists and they're around this afternoon if you want to catch up with

any of them later on. So, thank