Panel: Case Studies

So we've just heard from our three lovely speakers who have shared some of their experience and stories, and they're very different in terms of, the types of industries they're working in, the, the particular scenarios that they're kind of playing in. We've got, you know, AI inside regulated financial workflows.

We've got, live transport marketplaces, and then we've got startups where founders are moving faster than the technical teams can keep up with them. It's all these different domains, but it's the same pressure point. Once we start to get AI in the hands of people who are using it, we need real data.

We have deal with real accountability. And the question moves from can we build it to what do we need to do so that it can actually work. So I think one of the first kind of questions that I had for the group really sits around the idea of constraints. And I want to understand from I might start with Barrow and give you a chance to kind of like collect your thoughts in here as you've just come off talking.

You know, we've got constraints around regulatory from the kind of, you know, Theo's perspective. We've got marketplace and operations, for Barham. And then from Inger, it's around, you know, team and founder capabilities. So how does this change your approach to how you think about using AI within these scenarios?

So, Baram, I might start with you, if that's alright.

Yep. So I think, can you you hear me okay? Yep. So as Inga mentioned that now anybody can start building anything. Coding was never difficult thing, and it is easier than ever. And the only thing we, senior leaders, have to do is set up guardrails so that what we give flexibility to everyone, whether it is designers, they love play moving the buttons.

So, yeah, set up proper guardrails so that everybody has opportunity to build the product they want to build.

Great. Theo, what about from your side where I expect there's a lot of constraints that you have to operate within?

Well, deep down, I'm an engineer. So, you know, we love constraints. Once we understand the constraints, we can build towards it. And early on because I worked for Telstra. You know, at that stage, we're the largest network in the Southern Hemisphere, private network. So like Ingo was saying, it was like 90% was getting ready for the change.

The coding was the easy bit. But it was also easier because I was trained a lot by IBM, a lot of education by IBM. It's all about large systems management. So, you know, I grew up through that and that became a big advantage for me because, you know, there's no cowboy stuff. You know what all the constraints are.

But my recommendation, I'm not sure if it came through, is encompass the constraints. Love the constraints. Because once you understand what the constraints are, then you're doing something hard that others haven't and then you can build towards it. My constraint to my first fintech was, you know, money. So I leveraged everything in there where I could.

I used my negotiation skills to work with the big vendors to give me their software really cheap for the small banks because I saw it as a an amalgamated opportunity. And just to get a front end working cost me, like, $30,000 out of my pocket. This is a proof of concept. The minute I so when I got got on to chat GPT, suddenly, I could see things happening quickly, but heaps of constraints because it wasn't understanding. It didn't even read its own output.

When I started using cursor, I go, fantastic. So I could put an enhancement here in twenty minutes. So suddenly, that constraint was gone. I've moved now from development to getting my architecture ironed out, aligning the compliance part of it and coming up with intelligent ways to solve problems. This is one person.

And how much does it cost me? Like, you know, it hasn't even gone past a thousand dollars yet. So I could focus on what I'm brilliant at, which is, you know, understanding the end to end complexity, the customer side, how can I use AI, And then all my connections with the funders, suddenly those constraints are gone? But that's all operating within a really constrained environment.

And in my case, I'm not sure whether it's a head case or not. I've made the constraints harder for me in my space because I know the constraints are coming. So the way I see it is I understand it all. I've got an approach here and if I'm building for something that's more constrained than what it is now, then I'll be ahead of the game but more importantly, my brokers, my consultants will be ahead of the game. Everyone else out there, they're whinging and carrying on and crying about how their world's gonna become more regulated.

It's inevitable.

And what about you, Inger, where you're thinking about the constraints of, you know, capability largely and what does that mean for you?

I want to look at this with a very different lens because there is a business need. There's also people need. Right? Like what do they want to do? Because we talk about regulatory constraints. We talk about compliance. And they want to move buttons. How much compliance do you need to move buttons?

I encourage you to think about it not just in terms of like, here are all the complexities that we have in our very complex system. How do I protect my little designer who want to move a button from all of it? Start with just allowing them moving buttons. Like I obviously, I mentioned business need before.

Because maybe your need is not for them to move buttons. You have to align those two things. But I think it can be more people driven process in terms of what the value that I want to get from this person. If I want them to experiment on my UI, if I want them to move buttons, if I want them to at some point go and get approval from legal on can I move this, Empower them to do this?

You don't have to build the full house if they're going to use one room in it. But you can start with one room and then build more and more of your house. Like, I think people tend to I'm trying not to say overthink. But people immediately think, if I get them access, they're going to build me 75 unprotected endpoints.

And this can happen. But why are they building those endpoints? What are they trying to achieve? Why do they need new endpoints to move buttons? That that's the good question. So I think there is there should be more analyzing requirements before you jump into, I'm going to build all of those protection layers.

It doesn't mean that you don't need them. You probably need them. But you don't need all of them to allow one of your designers to experiment on front end UI.

Yeah. It's it's kind of an interesting perspective in terms of scaling kind of like where the constraints sit for the type of change or the type of activity that you are actually looking to do within, you know, the context of the business. And I think there's this this element of it's almost like we need to technology in particular has been in this kind of push mode for a long time.

It's like we will tell you organization what you're allowed to do and kinda like, you know, the the structures in which you're allowed to operate. And what we're witnessing now is this flip to a pull mode for the business to kinda turn around and say, no, tech, like, I wanna do this. You make it work.

In fact, if you'd like, take a look at these environments that I've been working in, highly constrained. They're so constrained, like, over ten, fifteen, twenty years ago, it all started with the saying, I'm pissed off with you. You you never deliver anything on time. You the time you deliver things is too late. My competitors are so they've created their own internal IT systems.

So, you know, this business unit here, for example, mortgage mortgage funding. This one over here, HR. They've all got their own disparate IT systems. Still need the same people, probably more now, but they're embedded and they never really solved their problem. At the end of the day, you look at Google, you know, from years ago, they put micro changes in multiple times per minute.

And any other day, we need to empower these business people, founders, representatives to to do what they need to do. But I love your idea which is you give them the guide rails through the skills. And that's something that I've, you know, since I mean, over thirty years ago, you know, the idea was a self learning entity just based on some building blocks but you need to teach it.

So by teaching it using your skills, then suddenly people got all these people got access to your skills, which are built in guardrails, and then they can accelerate the development. Because at end of the day, you know, we we work for businesses, we work for nonprofits to do something.

We want them to do it faster, quicker, cheaper and that's the opportunity of AI. And if you have a look at where AI is going and what's the push behind AI which is, you know, AGI and everyone's putting trillions into it, that's the opposite of what we're talking about which is the ethics, empowerment.

Because my experience is accelerate your capability or your plans through AI, not putting people out of jobs. I was never gonna pay five engineers to do something. I was doing it myself. But now I can do it myself, faster, better, and I do talk to my LLM.

His name is Jaime, the robot from Maxwell Smart, you know. So I give it everything and the more because it's learned how I think over the last six and nine months, now when I ask her the question, it says, I won't go back to just textbook stuff. I'll I'll know how you think Theo, that's what it said. Now, I approached it from that angle.

Suddenly, I'm just the empowerment is huge.

I think one of the things that we we as an organization should a flexibility for where people can make mistakes. I was in my first meeting for one of the client. They had multiple SaaS products. They were planning to redesign everything, and they did not have technology team. They had just one designer.

That designer, he himself built everything, the entire product with the help of cursor. And when we went there, he just said that, okay. This is totally ready. You just need to plug in the APIs and make it work. And we just wanted to make it live in the in a in a week time. And then I said, okay.

This is looking really great. I said, okay. Can you show me by doing something? He said, okay. Let me create a page. He just tried one business use case, and with just one command, one entire page was there. I was happy. Okay. The you you are doing really great job. And then I thought, can I have a look at the code?

Mhmm. And when we looked into the code, it was completely missed because there was no guardrails. It was not his mistake. Good that he learned the stuff. He he he made reusable codes. He he built entire website, entire SaaS product by himself, but because there were no guardrails, there were no tech guidance.

But the good thing is now because he had the other organization have guardrail setup. Now the basic architecture is set up. Basic system design is set up. Now that designer has full flexibility to build pages, he does not need any developer, any technology guy.

Sometimes, just add something. I talk to people and they're like, what's your main skill? And I'm like, know when AI bullshits me. And that's the skill. That's skill that all of you have and that's the people who are non technical don't. And that's how I prefer to think about it. Like, how do I help them to know that AI bullshits them right now? Because that's where my skill is.

Because I talked to Claude and it's like, this is how we implement this. I'm like, not that is not how event driven architecture But like, I know this and they don't. And it's unfair to expect them to know this. It is a lot more logical to expect me to help them.

And that that's that's the main difference. Like, the main difference and I know it sounds very simple, but that's it. I know when it's hallucinating. I know when it's doing the bad job.

What's gonna happen like, you know, I'm a tad older than you. You know, a lot of my mates, you know, they're all retiring and a lot of although it was the young one in the team, they were all, you know, ten years older. All that knowledge is gone. And what's gonna happen when you move on You know, I've moved out of that consulting field just to focus on AI and my product. But those skills that I had over twenty, thirty years, they're now now available to anybody.

They're not available to anybody.

Yeah. I mean, I think this is a that experience level Mhmm. Is definitely something that I think a lot of organizations need to watch out for a little bit is kinda, you know, there's a there's a real potential risk of brain drain. You know, there was some research that I'm pretty sure it was Anthropic. It could have been OpenAI but I think it was Anthropic, did earlier this year where they were looking at the types of questions that people were asking but it was based on their role type and their education level.

And they're kind of The upshot of it was essentially, if you had had, you know, like particularly things like post graduate degrees and stuff like that, the types of questions that you are asking the team The AI assistant were far deeper. You had a lot more turns with it and you know, they were a lot more difficult in terms of the question response style that was going on.

And I suspect if they had extended that down into other professions and they weren't just looking at kind of, you know, educational level, you'd probably see the same sorts of things. You know, the sorts of things, Inge, that you are kind of like having a conversation with versus one of your juniors, I suspect it will be very different.

And your kind of point about, I can tell when it's bullshitting me, that's really where this starts to kind of come, to the fore. And so I guess, you know, how, and I'll start with you Inga because you sort of raised this. But it's how are you building those kind of checks and safeguards to kinda, you know, really, almost build that knowledge into this next generation of developers who are coming in and you know, maybe they don't have that experience that you know, that they would have got by just implementing a system 50 times to kinda understand.

It's like, this is this is what it looks like when it goes wrong.

I have a lot of interesting conversations with my juniors. And what I constantly tell them because if you talk to juniors recently, they're all very anxious about their jobs. They're all very anxious about the AI replacing them. And it's a valid concern, let's be very honest. Because they cannot ask all of those important questions.

They don't know that they should. What I always tell them is that from my perspective, software engineering is situational. You're never developing an abstract product, an abstract environment, or an abstract tools. If you have all the money in the world, maybe you do. But you're always limited.

And how well you give those limitations to your agent affects the output of your of your coding process, affects the product. So I'm trying to teach them to think more about all the limits that they have and start there instead of like, I can do whatever I want.

I'm like, we have a deal with Netlify. We don't have a deal with Versal. You cannot do anything you want. So there are a lot of situational knowledge that you, as a senior engineer, you're immediately zooming on it. You read the documentation. You're like, oh, external KYC provider, blah, blah, blah, all of those things, because you trained.

And they're not. But they can be trained in this. You can just have a conversation and ask them, look for those things. And AI is like, you can learn with AI. You can describe the problem and ask, what do I don't know? How do I make it better?

And yes, sometimes it will lie. That's when you come to Inge, then Inge tells me that AI is wrong. But still, the tools are there. It is much harder for them now. That's why I have so much compassion for juniors now. Because I strongly disagree with some business ideas around what's happening right now in terms of like everyone is 10x engineer.

No, not everyone is a 10x engineer. A junior that given all the tools is not a senior. No. Junior with AI is not a senior. And we all need to be aware of this. I businesses need to be aware of this. The junior with AI is junior with AI. They're not a senior.

But if you pair a junior with senior, even for a bit, if you give your junior AI and access to a senior, situation changes dramatically because now they have human in the middle. That's what you need. So I think as an industry, we haven't figured out the right way of doing this. But I just want to encourage everyone to have more people centric process around this. Because we're getting older.

At some point, we won't be here to mentor everyone. What are they going to do? Are they going to ask what for everything because they still don't know anything? No. It is our industry. We're all responsible for its state. And that's why I really want to encourage everyone, work with business. Make sure that it's clearly understood that you still need to teach your juniors. Because your seniors will buy a farm in New Zealand.

After, I don't know, start building paper planes, whatever. People change careers. People leave the industry. We all as managers or leaders, we always talked about redundancy risks. Like, what if you don't have any redundancy? What if you what if you have this one key person? Another person with AI does not replace your one key person. And I think that's something that we all need to talk to our businesses about.

That's a great point because I sort of left the consulting thing because the society had changed too. Like, you know, we used to respect seniors where when I when I was starting doing some of these engagements, you know, I'll be like one of the first people they parachuted in to fix an enterprise issue because I had that end to end view and everyone in this organization had that.

And we're all neurodiverse as well, by the way. So you sort of you're very good in some yeah. You can focus on some things very well. But the people that were the managers who were hiring us had no idea. And once we gave them enough benefit, they go, we're gonna cut your contract now because of this. I pushed back and said, no, you're not.

But I got sick of it. So then I started doing and that's when I did my first fintech and now I'm doing what I'm doing. Thank God my career was around data and forecasting and performance and capacity which is now which went into machine learning, now it's all about AI. But because I'm still a practitioner, I was able to do it. Now, how can I take my knowledge and then give it pass it down?

We've got skills and so forth but I think at some point, the business has to have that realization. They haven't. They have no idea. They just, you know, it's If you're a CEO or a CIO, CTO, especially a CEO, you know, these big massive organizations, they're making $1,015,000,000. Their target is to cut costs or it is a brain drain or offshoring. But when I first started in this career at Telstra where you might have one engineer, now you would have had three or four and we did have the mentors and you had time to sit and talk and that's when I was most creative.

You know, I you know, in three years, I had so much experience and I created a legacy without knowing it by the stuff that I developed. You know, ten, fifteen years later, they're still maintaining my stuff. I'm going, what the hell are you doing? It was more of a proof of concept and now all of Australia uses it. But you know, as time goes on, think we're gonna lose we are we have lost a lot of the experience.

Maybe AI is a way of taking some of our experience and and creating something whether it's guardrails or a skill or something. But you can't replace one senior. You can't replace five seniors with five juniors with AI. That's what everyone's trying to do.

I think whenever we think about AI, there are two main factors. One is human and second is data. So if we have, let's say, junior engineers or product owners or designers, if they have one human in the loop, which is our technology person to have proper guardrails for them, they can start building their stuff. So one is human in the loop the most important stuff. Second is data, which is based on my recent learning.

So in my current client, this is second year with the same client. Last year, we had accessibility review with them. So based on that accessibility audit of the entire year's code base, we created guard layers. So now when you push the code, those got we will make sure that those same accessibility issues won't appear.

Similarly, what we did, we made data of all the bugs from our Jira for entire one year, and then based on that, identified certain patterns where people make mistakes and then improved our process. So whether it is defining guardrails or wherever AI is needed, only two things are needed, human and the data.

Utilize the data with the right human in the room.

Yeah. I'm gonna pivot it slightly off the back of that. I think that was a that was a good little flow of discussion. And I wanna think about the the topic that we were just sort of touching up against which is really the shape of engineering organizations. Baram, I'm gonna start with you. But I think what we were just sort of circling around is that, you know, there's obviously a lot of change.

We've got this kind of issue of knowledge and and whatnot. And we've got these commercial pressures that are kind of sitting there to kind of think about, you know, stripping cost out of our organizations, you know, whether through number of people or the types of roles that they kind of sit in. And I'm curious, you know, I'll start with Bahram because you sort of exist in this world where you've one, you're building an engineering organisation from scratch but you're also embedded into them via your clients.

So you'd be able to get a bit of a sense of where that's transiting already. How do you think the kind of, you know, the new look modern engineering organisation starts to look as a result of some of the stuff that the three of you have been talking about this afternoon?

I think now we because with a smaller team, we can deliver more, which means we need to start building more ideas. So with the same team, we can deliver more. And rather than thinking in terms of redundancy or losing job, we should think in the direction of getting more ideas developed and executing more ideas.

As a how the organizations are reshaping, I think we need lesser people. We and we anyone in the industry, we do not need to restrict ourself with any boundary, whether it is bound and and those boundaries are in our mind only. Whether it is the boundary of that I am front end or back end or full stack engineer or I am a technology only, I cannot think much in terms of from product side of the things. For example, personally, I feel like that I I want to find something exciting where I get an opportunity to learn.

And if that is not in the technology, not in the coding, not in the system design, then let's get a level up, think in terms of business. Right? So that's how I feel that, now we you you don't need to limit yourself in just technology because it has it is simpler than ever. Then let's just move one step up and see what else you can utilize with this knowledge base.

Inga, what about you?

This is hard. Look, I'm what I say is might be a bit controversial, but bear with me. I think if you don't think your people are brilliant, fire them. I know it sounds controversial, but, like, if you if you come into a room with your team, and as a leader, you are the smartest person in the room, you are in the wrong room.

Leave the room. And I think that's I love this framing even though it's controversial because it's actually people centric. Are people around me brilliant? If they're not brilliant, why? Did I suck the living soul out of them?

Is that the reason why they're not brilliant?

For long enough.

Can happen. Do they need tools? Do they want to switch to something else? Do their passion lies in some of those? Because as a leader, your main goal and again, controversial opinion here to know your people. When you know your people, you can figure out how they fit in your organization. I know it's very hard to know your people when you have like 6,000 people organization.

But that's where you have the structure with the leaders. Right? And if you don't have brilliant leaders, fire them. Like, you want to have the best people. And if deep inside you don't believe your people are best, you're doing them disservice. It is not it doesn't tell you much about them. Like, they're not brilliant.

Because I believe that people come to the industry with passion. People come to the industry wanting to do things. And if they're not thriving in the environment that you're creating, that's on you. That's on you for not creating the environment. And maybe they will be more successful in another environment. Or maybe you're happy to experiment and move them to a different environment with your organization.

But you need to be, as a leader, you need to be very confident that you have the best people working on the most interesting, hardest problems. If you have doubts around this, you need to sit and think about it very, very hard because it's a very bad symptom. If you're sitting there and you're thinking, I can make thousands of people redundant.

Why do you have them?

Like Good point.

It's it's very important for all of us to think about people. Think about their skills. Thinking about their brilliance. That's what excites me about AI because people bring more brilliance into all the things. And if your people are not successful, you as a leader fucked up. Do better. And I hope as an industry at some point we start working on this shift a bit more.

That your value is in your people. If you just like pushed your business out, it had grown just because you were hiring for a headcount, that's on you. If you hired people that you didn't need, that's on you. If you hire people that are not succeeding because you're not giving them tools, you're not giving them mentors, you're not putting them on the right teams, that's on you.

Like, there's you cannot blame the headcount for the business issues. You hired them. And I think that's that's on the leaders. That's on us. Like, how do you reshuffle organization? You think about all the people that you have. You think about what you're getting out of them and what you're not getting out of them and why. But it's it's a it's a very hard job to, think about it and then have the conversation about it.