# Building Trustworthy AI Systems for Enterprise Scale

**Podcast:** Tech Lead Journal
**Published:** 2026-03-16

## Transcript

Design the system, not the hero.
If success depends on your personal heroics, it will never scale.
Today's guest is Andrew Stevens, serial tech entrepreneur with 30 years of building, scaling, and selling companies.
Now CTO of Sakura Sky.
His framework for building trustworthy AI agents is redefining how enterprises deploy AI safely at scale.
I was in a motorcycle accident in 2006.
I ended up in intensive care.
I was so much pointed at me and so much dependent on me showing up every day.
Scale is really about building a system that makes good decisions without you.
And that was a really tough lesson for me, but I thought I had to be hands-on everything.
Resilience is built, not wished for.
Design for perfection is where I started, but today I designed for resilience.
Uh leaders kind of like drag back into being hands-on.
So what advice leaders should do?
Trust comes from observability.
If you can't see it, you can't improve it.
You need to have those guardrails.
Being able to scale your company is really about trust.
It's about data, it's about trust.
And so that's about leaning into the people around you.
The other thing in the executive's mind is actually building an AI ready organization, right?
Oh, AI is a great amplifier.
If you're really good at what you do, AI is going to make it better.
If you're not so good at what you do, AI is really going to expose that to your audience.
AI is just a new software pattern, and an LLM is just an user interface.
We need to become familiar with this new identical software architecture.
The fastest team are the people that can make decisions safely.
It's not the people without rules, it's the people with the rules that can be applied the fastest.
Governance isn't a gayest guardrail that lets you get there faster.
The reason why you put brakes on your Ferrari is so you can drive fast.
If you didn't have brakes on that Ferrari, it's not going to go very fast.
Hey, quick boss.
My goal with Tech Legional is simple.
Learn from the best in tech so we can all grow together.
If this resonates with you, hit subscribe to follow the channel.
It's the biggest way for you to support the show and help us keep bringing great guests and insights to you.
Thanks for being here and let's get back to it.
Hello, welcome back to another new episode of Techly Journal Podcast.
Today I'm very excited to have someone who has decades of experience building companies, scaling companies, selling companies as well.
So his name is Andrew Stevens.
Really looking forward for this conversation.
Yeah, thank you, Henry.
Great to be here, and I appreciate the opportunity to um speak with you.
Yeah, look, my background goes back a long way now.
So uh hopefully uh we can find something interesting to chat about today.
And I'm looking forward to um uh yeah seeing there we go.
Yeah, so when I look at your profile, I mean it says like you have 30 plus uh years of experience, you know.
You have um, you know, a lot of experience building companies, scaling companies, selling companies, and not just you know, as a tech practitioner, but also at the leadership position, you know, like CTO, you know, uh contractors, consultants, and all that.
So I think the first theme that I'd like to probably learn from you, uh, you have gone through this journey, you know, building startups from zero to one, one to ten, and and you know, going um, you know, up to selling the companies.
So I think uh maybe you can start like bring up some topics that you think uh could be you know a good learning points from you to teach us.
Yeah, absolutely.
Um yeah, look, um I I started off luckily, I guess, in in the early 90s is really when my IT career started, so it's been a long time now.
So yeah, I I came through working in university, uh I've gone through uh working at software companies, I've worked for manufacturing companies, I've sat on a on on the train to and from work every day when I had a long commute and I was coding on the train uh to drop.
Really, really believed in.
Uh so you know, it's been a a great journey.
And sometimes I look back at these things and think, oh my god, my laptop out now in some of the places I've lived in.
Uh, you know, where I've lived in New York City, I've I've lived in San Francisco, I'd never put my laptop out in those places.
But you know, back in the 90s, it it was so exciting and new to get caught up in this internet thing.
And uh, you know, I I started in the early days and I really wanted to learn about how dial-up internet worked.
And I heard about this new thing called Linux, and I got really involved in that, and that's so exciting.
And and built, you know, uh just a couple of friends and I, we we built a dial-up internet company and we sold that.
And that was really just three guys sitting around eating pizza and um coding on a weekend or after work.
And that was so much fun, right?
That was the opportunity to explore new ideas and and it was a safe place to uh build something, fail, and fail terribly because you know, I I remember my first um order off Amazon.com, right?
Um, I I bought a Pearl book and I think it was a camel book way back then, and I looked at it and I couldn't buy it in in Australia for less than like a couple of hundred dollars but I could buy it off Amazon uh in the US for like sixty Australian dollars but it took six months to come via uh sea freight and it was a long time and when it finally arrived it was amazing to get it but then I went out immediately and cancelled my credit cards I thought oh my god I've given my credit card away to this unknown company nowadays people look at that and laugh and think you know Amazon's a household name and I think that journey is amazing to see that the trust that's built with the internet and you know companies that such as Amazon whatever you may think of things now but they've they they spend a lot of time to build up trust they built those systems and I think that really talks about what we need to be thinking about as engineers and and founders as well.
And you know being able to scale your company is really about trust.
It's about data it's about trust and that's about um leaning into the people around you and their expertise and and really discovering what others around you can add.
And you know in the early days it was really for me about um being the most knowledgeable Pearl programmer, the PHP programmer, Cold Fusion, you know, what whatever I wrote and and nowadays, you know, I love Rust and Golang.
But um back then it was Pearl, and and that's what I did, and that's why I suck my notes down.
And I really thought I added value strictly through my ability to commit code, and it wasn't git back then.
Um, you know, uh committing code and uh uh pushing the needle more.
And as as time grew, you know you you you find out other values in yourself and those other values of of people around you, and really success is built through you know, trusting, um, and trust is a lot, you know.
It's not only you trusting your business partner or your team, it's uh also your customer trusting you, and you need to build those systems and and methods for them to build you.
So, really going from nothing, like I'm I'm sitting by myself, I want to build something, you know, the founder as an engineer sort of paradigm, right?
It's really about speed and innovation and and getting something out.
And nowadays people talk about product market fit, and I'm not seeing the conversations about uh MVP as much anymore, but it's all about PMF and uh you know how do you get there.
You know, back then, how do I get there?
And it's easy when you're a team of one, but you'll never reach scale, and scale is not just about people, it's about your customers, it's about your reach, it's about more than that.
When how do you scale from zero to one and one to many is another thing as well, and and you really find things that break.
You know, one of my early companies I I built, we went from two of us, and we hit over a hundred people.
And I had people in Malaysia, I had people in the Philippines, I had people in Australia, and um just scaling that was difficult, you know, decision systems break, you know, staying centralized and making everything founder-led is great to a degree, but when you've got people in different time zones and different skill sets, you you you're not gonna be the expert in the room every time.
So you need to build a way to trust those people.
You know, teams sitting around waiting for your approval is not good either.
You know, context gets lost, speed drops.
And you know, if you're the founder and you're in every single meeting, in the early days that's okay.
But once you're at a certain size and speed, it it's difficult.
So I think there's a lot.
So it's all about communication.
You know, scale isn't about adding people, scale is really about building a system that makes good decisions without you.
Uh and that was a really tough lesson for me to learn in the early days where I thought I had to be hands-on on everything, and only I knew the product, only I knew that line of code.
But you know, there's a lot more to it than that.
So, yeah, I think some of those things that breaks at scale, uh, I think you'll find it fairly quickly.
Sorry, Henry, I'm back, I've been chatting too much.
Yeah.
Yeah, so thank you for sharing some of the interesting uh stuff that you you have gone through you throughout your journey, right?
I want to pick one thing that you mentioned earlier, which I find really interesting, especially in this era, right?
So we can validate it.
So you mentioned that uh these days people less talking about um you know, MVP, building MVP, but more towards uh product market fit, PMF, some people call it, and now also with the advent of AI, right?
So I think building MVP is arguably simpler, you know.
You know, there are so many vibe coding tools this these days, like Rapplit, uh Level Bolt and all that.
So I think building MVP might not be a challenge anymore uh these days.
Um so tell us um maybe this shift, uh, what you see for people who are starting up startups, you know, like building new products, right?
Uh, what about PMF that you want to tell uh those people uh so that they can actually shift their focus instead of just building MVP, but also also think about the PMF aspect.
Yeah, I I think um scale and trust everything AI is a great amplifier.
You know, if you're really good at what you do, AI is gonna make it better.
If you're not so good at what you do, AI is really gonna expose that to your audience.
So then I know PMF or product market fit within the age of AI is less about novelty and building something new, I guess.
Um it's more about uh repeatability.
You know, can you deliver the same outcome?
Can you deliver it safely?
Will it happen every time?
I've been in demos with AI models where it literally worked 15 minutes before the demo, come in, turned it on, and you know, the prompt was slightly different or something, and and suddenly I got a very unexpected response.
And it's been a terrible experience for myself, being a terrible experience for the product, being a terrible experience for the user, the customer.
You know, guardrails and um repeatable outcomes are really what AI nowadays is about.
So, you know, it it's great to scaffold an idea with um you know, Claude or or something, or you know, I'll I'll have my ID open with uh sorry, my cats decided to join me, so um apologies.
Um so you know, it's about um uh you know, cord can help you build code really quickly or Gemini or or or codecs or whatever.
But you know, I use that for scaffolding, I use that to demo demonstrate value quickly, I use that to demonstrate or or explore an idea but for me I I don't take that code to production that that's great for um uh understanding what I can achieve but it's not great for scaling necessarily right it's it's learnt from Stack Overflow it's learned from Reddit and while it might have some great it's learned from open source on GitHub whatever apologies to open source people uh um you know it it's learned from those things and it's not necessarily picked up the right habits and it's learnt at scale on some bad patterns and the difference between a good product and an AI product is going to become more and more amplified we're gonna see what a good engineer brings to uh a product developed by AI it's going to be probably more secure you know it's going to be scalable differently because you know an AI tool is only as good as its prompt and its training material right and it's still random you know still probabilistic in terms of what it outputs and uh and this is why I don't feel necessarily at threat from my my role in technology today because the day that all my customers or all of my users can express what they want succinctly or to in totality to an AI to get what they want is a day that I probably am under it's can we all know the reality uh is that business requirements change, market conditions change, customers will see something and realize new value, or when you produce a bit of code, you'll actually spin it up, look at it, and go, oh, if I did that, I can make it better, right?
And AI can't necessarily do that.
And sure, you can instruct it to do a little bit more, but it's like drip feeding, and you're not going to have that um push of quality or whatever into production.
So there is a definitely a great gap between what AI is producing and what you can produce as a skilled engineer.
What I think the the risk is for people at the moment, and I'm seeing it a lot, is people are employing less juniors, and that I think is a real risk for the industry, because those juniors aren't being trained, and in five years' time, who's going to be the seniors?
Yeah, and and that I think is a risk for the IT industry in in general.
You know, I I used to worry that the hyperscalers and that uh uh or even Microsoft or anyone producing operating system is gobbling up the people that are capable of producing good operating systems.
How how hard is it today to actually produce uh a startup that scales without going to a hyperscaler?
Yeah, we we end up by paying the people that we'll eventually end up by keeping competing with to deliver our products, and you know, that there's a certain amount of um work we need to do as engineers and and professionals in our field to really um understand our technology, and that's always on us.
But we also need to understand the realities of the business that if I'm going out there and I'm scaling my product, how am I going to get that?
And what's uh the the payout point, right?
I mean, there's a reason why Meta, for example, are not in Google Cloud or in Amazon, because there's obviously a point in time where you know the the cost of using uh hyperscaler cloud is is less cost effective than doing yourself, and understanding those points of inflection for you as an engineer or somebody building a product is really essential.
You need to know those points in your time frame.
And sometimes working with AI is not gonna help you, it might give you some ideas, but uh, you know, you need to be really hands-on at the wheel and understand.
So, what I my ID, I have Codex on one side, I have Gemini Enterprise on the other.
I'll get one to help me plan a product or you know, plan a brief or plan it, then I'll have the other one review it, then I'll have one scaffold it for me, and then I'll have the other one check my scaffolding versus my brief, you know.
So I'll I'll I'll duel my AIs to try and get the best out of it.
And I've tried a lot, and you know, there's a lot of AIs I haven't tried yet, but uh I'll continue to use them.
So I I love AI as a productivity tool, but it's not a production tool.
Um, you know, code that goes into production, it'll help me get there, but uh, you know, I would never push my code blanket in into production.
Yeah, again, I've gone off on a big tangent, but um, you know, around the product magic fit, why are startups dying in that space?
You know, a lot of them are building what what I consider a demo and not a product, right?
Some people are building just a simple wrapper around uh an LLM, and an LLM is not an AI system, you know.
You know, an LLM to me, a gentic AI is just a new software partner, right?
And an LLM is just a new user interface.
We as architects who are engineers need to become familiar with this new agentic AI software architecture, like microservices, like you know uh client server going back further, it's just a new software architecture that we need to understand, and we need to understand this new way of users interacting with software and LLM uh chat interface is a new way to do it.
You know, I'm seeing some great outcomes in the data data space where people have been spending you know months trying to get reports pixel perfect, getting the right bar chart or something, and um in a deterministic agency AI space, you should be able to query your data sort sets in natural language and get the results in the format that I want through agentic AI rather than doing a necessarily complex dashboard.
Uh but the trick is is most people don't know how to do the deterministic agentic AI at the moment, and they're all stuck in probabilistic AI, getting changed answers every time and getting some terrible outcomes.
So taking that step up is where you know, we all need to be focused.
It is possible and it is happening, and I'm seeing it.
So uh in fact, one of the products I've worked on recently, it's in a uh highly regulated financial industry in European Union.
Uh, it's past order, it is um uh compliant with the GDPR, it is deterministic, uh, it's in banking, so people can get the exact specific data in a repeatable fashion.
It's explainable, so you get the exact SQL query executed on your data, and you get the exact outcome.
So those are things.
So don't ship a demo, you know, ship a product when you're thinking about PMF.
Yeah, and and another thing people thinking about too often oh, sorry, I mean co.
I was just gonna say people too is on the next model and not about better workflows and better channels.
Yeah, sorry uh to disrupt so so one thing that I I find really interesting these days, right?
So people are so easy to build something, you know, like think thinking about what you're saying, right?
Building demos and all that.
And and in fact, many of uh those things are just rappers on top of LLM because you know the LLM models are still improving by a lot, I guess, although it's kind of like slowing down a bit lately.
Um, but arguably, I mean, these uh LM models are so powerful, uh, and then people are building on top of it.
And there are so many competitions, like for example, if you innovate one type of product today, I think I'm sure uh tomorrow or next week or so, other people can replicate such similar product in a fast manner, right?
So tell us how do you how do you actually advise startup lead startup or leaders, right, to actually build some kind of moat uh when they build you know their PMF.
Yeah, um I've seen a lot of discussion lately about um this moat, and it's becoming more and more discussed.
I see it going through Reddit, I see it going through LinkedIn, and uh people I don't think people on two sides of the discussion.
I do believe data is a moat, and the trust.
So with good data comes good trust.
If I can trust I'm getting the right data from my system, I'm always going to go back to the system and try it again.
Right.
But if I get one single query goes wrong, people don't trust your system anymore.
And and that's where uh it gets down to, and that's the kind of trust I'm talking about.
Can people trust your software to come up with a good response?
And for me, it's about finding the right data that really makes your platform or your offering unique.
You know, I'm working with one person at the moment where they've got a very unique audience and they've got excellent data.
No one else on the planet has it.
And rather than focusing on that, which they should be doing, they're focusing more on competing with people that have less focus or or less generic, uh sorry, more generic um adoption in in in the industry, and they've got a very strong market position, and they should be out there telling their upstream suppliers or their upstream partners that uh you know, they own the audience, and this is the data that we can get.
I think uh Tim Bernard's lead uh said something along the lines of you know, software comes and goes, but it's data that persists uh between systems, and you can Google that.
I can't remember the exact quote right at the top of my head right now, but um uh, you know, data is what comes and what stays.
Uh software comes and goes, and that was actually I think um another moment for me in my career.
Yeah, I'd write a system, I'd write it what I thought was perfect, and then I realized like four years later, it's not perfect anymore, it's terrible, it's old, it's slow, uh, doesn't follow the the nearest frameworks, you know, it's not deployed properly anymore.
So everything I do is transient.
But my um software trends the the something I bought five years ago can still help drive AI today as to my behaviors.
So, you know, data is there and that's the mode to focus on.
What is a unique offering around the the data space that you've got?
What is a unique interface that you can offer?
People are saying SaaS is dead as well.
So I do see a lot of competition and and tacking SaaS, I guess.
Uh is it?
I don't know.
Can I build uh such SAS-like software?
I can build stuff very quickly now.
But can I scale it?
Maybe not.
Can I pick up my odd data?
Um I've got to work and sit down and go through that.
So yeah, it's all about data that in the moat for me still today.
Yeah.
Thanks for pointing that out, right?
Because in these days, right, where you in fact building LLM itself is not particularly a moat anymore, right?
Because you think it it is such a novel thing that only smart people can build, but actually there are thousands of models available if you just see in the hugging phase.
So people are building open source version, people are building, you know, like big models and all that.
So I guess like uh LM itself is not uh necessarily a moat these days.
So I think what you're mentioning, uh building on top of data, you know, and trust, right?
So building applications that people trust, people want to use, I think is still the key.
So maybe let's switch channel a little bit.
I want to talk about your leadership journey because I think it's very, very interesting, right?
So one in particular thing, I think, especially uh in those early days you mentioned earlier as well, that you tend to be hands-on, you want to be involved um, you know, in your leadership, right?
You you want to know everything, but obviously throughout you know your journey you realize that that doesn't scale, right?
And typically this is something that is a major bottleneck in any kind of startup that is growing, especially rapidly growing.
So tell us um why it's such an important thing for leaders to be slightly more hands-off.
Uh and in this AI era, especially, some leaders are kind of like enticed back to be more hands-on simply because AI can help them more to be hands-on.
So what's your take about this?
Yeah, look, uh, I I think I can think of three things in there.
One, you know, I I'm working with um one organization today that the CEO is in every meeting.
And they've become real bottleneck that they can't um scale, right?
No one feels empowered to make a decision.
The CEO doesn't trust the people that they work with to make a decision.
I feel that nobody else can do it but them.
So why have senior people?
Um, you know, you might as well cut the senior team and get like juniors and AI to do that task, right?
There's there's no need.
And you probably have um great outcomes that way as well.
But you know, if you if you have people you work with, you need to enable them.
They need to feel empowered to make decisions.
And that's often a very tough thing to let go of as a fan, right?
Because it it's your baby and you know you've worked on it and you know it's such a moment of trust and you know I struggle with that trust every day you know I I and I love it now because every moment I feel I need to focus on the trust between myself and other people I go well what's the real risk here and I constantly analyze my risk and you know I can I work very hard to make sure that the people that I'm with are empowered to make decisions and you know if I can't enable that for them I'll be disappointed myself so it's something I I try and aim for um some of the things that really changed for me I was in a motorcycle accident you know uh 2006 and uh you know I was on my way home from work someone else ran a stop sign it took me out I ended up in intensive care all that kind of stuff long time and my business partners had a tough time picking up from where I was you know I lost value in my investments I lost value in my companies and a whole bunch of things happened in 2006 because of of this exact moment and that was for me quite an inflection point because I realized then that was so much pointed at me and so much dependent on me showing up every day that I could never have a holiday, I could never you know take a moment out, and which was fine, you know.
I was in my early 30s and I was enjoying you know the center of center of attention.
I hate to think of it like that, but I loved being I loved the high intensity, I loved getting on the whiteboard, I loved drawing up that diagram, I loved hearing that problem.
And you know what, I can still do that today, but I can also enable the people around me to to be involved and take ownership of that and scale.
Because the moment, and and you know, saying is you know, if someone gets hit by a bus, it it happens, and uh that inflection point is important.
So for for me, what changed for me was uh my relationship with risk, right?
So I'm a risk.
How do I de-risk my business and how do I de-risk my idea?
It's my idea, if it's great, is only going to succeed if other people can get involved, right?
And that's the only way I can scale it, and it's the only way that um I can de-risk the adoption, I can de-risk the Hamming.
You know, what did I learn?
Resilience is built, not wished for.
So, you know, the business was only resilient as I am.
And if I'm taking out the business folded, so that for me uh definitely changed.
So nowadays I try and design environments for people to fail safely in.
You know, if you can't feel like you can push the envelope and have an outcome, whether that be a good or a bad outcome in a in a in an environment, you can never really find the boundaries of where you can push.
Right?
You've that's why scientists, the scientific method, you know, people push experiments fail.
And that is allows them to find out the boundaries of the scientific knowledge, and I think that's true for engineering as well.
So, you know, when you're pushing for that, you really got to push forward and um change things.
So and I had another idea, I've completely slipped my mind now, but uh uh, you know, that those are the sorts of things that you need to need to be thinking of for sure.
Yeah I love uh the your quote right resilience is built not something that you wish for not something that it could happen you know as you go through tough time but you actually need to practice train build a system guard rails uh to build the the resilience within your company not just individually right so I think building fail safe environment also quite important uh because um you know no matter where you are uh if you are not feeling safe I think people are not thriving as well because they're just fearing of their you know maybe job their career and all that I think is really important.
So uh what one question that you haven't uh actually answered is about um you know with these AI tools these days uh leaders maybe kind of like drag back into being hands-on so what advice that you you think leaders uh should do in order to balance you know the trade off being hands on and also trusting other people to actually do uh the things my my secret on this is and I'm still hands-on every day I still code right um I can't relate to my engineering team, if I can't understand the latest tool, I can't understand the code, you know, and I do that not to pry on them, you know.
I do it in a way that I can have a conversation I can contribute to.
So recently, you know, some of my hands-on work in for one customer or one thing I'm involved in is declining.
So I've started up, I founded a new uh startup in January this year, so like four weeks ago.
And for me, it's a high security environment.
It's all about workflows to handle inbound security research reach outs.
So, you know, if somebody finds a vulnerability in your your software system, how do they report that?
How do they prove that and make that easy?
And a lot of people get these emails and they panic and they go, Oh my god, they found a flaw.
And you know, is it real?
Is it not real?
Is this person trying to rip me off?
They're asking for a bounty, you know, and how do you manage that?
So, you know, I've looked at how Hacker One do it, I've looked at how all these other tools look do it, and I thought, well, I could probably do something different.
And I'm not aiming for the big end of town, I'm aiming aiming for the small to medium enterprise, mostly mid-market, and looking at that.
And for me, that's my way to 2026.
I'm going to apply my knowledge, my hands-on, and I'm going to use that as a way for me to understand my teams.
And I will always do that.
So uh my recommendation for someone who has been a technical person now in leadership, maintain your code.
You don't necessarily need to do it in things that are related to the role directly, but you need to be in technology, you need to be hands-on.
You need to be going to that startup.
Um, sorry, that meetup.
You need to be um uh thinking of ways of how your engineering team works, right?
And that is really a way to de-risk the conversation.
You can have the conversation with your engineering team, but if you have no basis in reality, then they're not going to respect you.
They you know, you're just gonna say something and they're just go, Oh, this guy doesn't know what he's talking about.
And for me, that's actually uh a moment of inflection again.
You know, when I started to get larger teams, you know, I've had teams of 8,000 engineers report to me.
And how do I scale that, right?
I've had teams of two, I've had teams of um hundred, you know, and you go, how do I scale?
And when you start getting up on those numbers, you're a people manager, or eventually you're just managing a spreadsheet of budget, and you need to be able to let go in a way that uh enables those people around you to grow, and um you need to be able to trust, and the only way for me to do that is I trusted my own skills and continue to do that, so that's how I build it.
So I do a startup, I love to find a new problem.
And most of my businesses I've built over the years, um, you know, I mentioned learning Linux, and the very first one I wanted to learn Linux.
I did a startup, I built and sold it.
Another day um I was sitting at a pub with a couple of mates, and I wanted to learn a particular tech, and we saw an opportunity popped up, or in the pub, we actually saw it in real time.
We thought we could do that online, and I wanted to learn tech, and I just said, right, I'm just gonna write it in that.
So I I would often select a new technical model to learn.
And today, for me, that technical model is I want to see how agentic AI can be pushed um in new ways.
And for me, rolling my sleeves up, getting hands-on, and um contributing to not only my knowledge of my team, but those around me is the way that I do it.
So stay hands-on, you know, it's our our duty as uh professionals in our field to continually educate and learn, but also focus on the human element, and you know, technology is great, but ultimately everything we do is for people.
Companies only exist to make sales, and people only use software to get an outcome.
It's all about people, and we need to focus on that and keep that going.
Like I said again, you know, back in the day I used to think it was all about being the best technologist in the room, but today for me it's all about getting the best outcome, and that's enabling the people around me.
And I I'll try to do that, and if I fail, I'll try again.
So planning safely.
Yeah.
Staying hands on definitely is uh quite key these days, especially when you are faced with you know an advancement in technology that is so so fast.
Uh, because if you really cannot catch up with all these uh advancements, you lose touch and you probably just you know follow from the news and all that.
I think it's kind of misleading.
Uh but staying hands-on, not necessarily becoming a bottleneck uh for your company, right?
So you still need to trust people and build some kind of systems so that they can thrive as well.
So one point you mentioned about resilience, I think also very important.
Um you mentioned to me before our recording today is that you tend um want to look for people that has resilience, you know, in their attributes.
So why tell us why this is important and how do you actually assess resilience in a candidate?
Yeah.
Look, uh some some of the values I I I have in myself or what I like to think I have myself is curiosity right so for me I I'm always curious about what's happening next I really value uh collaboration so how we can collaborate together and autonomy right so you know you need to be able to know when you can work by yourself or you need to know when you need to work as a team right and you know I used to work towards per perfection that in the system must be exactly that or it's a fail right and and it must be exactly two pixels to the left otherwise it's ugly and it's ruined and being that hard task master on myself and because that was all I could my head nobody else ever had an opportunity or the chance to know what those KPIs were so design for perfection is where I started but today I I designed for resilience and that's understanding how people can come up with systems and enabling systems right and and it's about contributing it's about collaborating it's about curiosity like understanding what can go wrong and and planning for it and and or even having the capability to do that right and that's resilience and and I'm not necessarily um going to define it from a software architect's um resilience perspective but it's the ability to deal with change it's it's the ability to deal with um the unknown right because sometimes we don't know especially today in the age of AI.
You know I've worked with frameworks or ADR software development kits where a dot point difference means success or failure of a product that is unbelievable that um you know you look at the documentation says it can do it but because I'm using 17.1 not 17.2 it doesn't work so the ability to work through that and deal with that is is part of the resilience right working with others looking for points of failure and for me that's how do I recruit for that you know looking for people that are curious looking for people that want to collaborate looking for people that can work anonymously I think that'll add up to resilience because a network of those people um really helps um build resilience in your product and your business and your teams so that that's certainly an aspect of that and I think after a while you kind of understand who you you want to work with.
I like to define how I work with people or you know outcomes by things I don't want in the environment.
So you know you've got to pick those attributes that will add value right you know I don't necessarily want the the strongest engineer I want um the best engineer in the team because I can teach skills, but I can't teach attitude.
And um that's really important is the good attitude and working with people because your product is only as good as your team, it's only as good as your market you can define and and your total addressable market, right?
Uh and if you limit your product so much you can't address that market.
So again, that's all all all elements.
So many things that there's a lot of answers in there but um a lot of things to talk through.
Yeah.
So if I can pick a little bit more, right?
So because this days, again, with the introduction of AI, I think many people are also kind of like rethinking how they hire people.
Some people say the team size will be shrinking, right, to a smaller team.
Uh, some people say that um every individual now is expected to be more generalist, uh T shape, M shape, whatever that is, right?
Um so apart from resilience, uh, what do you think are some attributes that people should uh maybe focus a lot more?
Uh especially with this uh, you know, uh introduction of AI.
A are we looking for uh different types of people, maybe critical thinking, maybe curiosity definitely is gonna still be top of the attribute.
But are there some things that uh you think you apply as well within your you know company's scaling?
There is definitely a different approach to engineering today, like once upon a time, you know, you can give like when I first started engineering, I worked with this fantastic engineer who you could give, you know, specs like this, you know, you there's waterfall.
You'd write like a thousand page spec or something, you'd hand it to the engineer in the corner, they would work on it for six months and produce a perfect re you know, data capture form, perfect database design, the perfect report, um, or whatever, and it was to that spec to a T, right?
And that as a model back then worked really well, and you'd get exactly what you designed.
And you see that now in some of the the big big global names in IT.
They know that you as a customer are not going to be able to spec that form properly, and they they'll charge you what you asked for, and then you get stung for all these fees because you don't you can't possibly think of everything to you see it, right?
And and these are the sorts of things that um these companies make their money out of.
And for me, I much prefer more at agility.
You know, it's really frustrating as an engineer to have you don't want changed priorities, but you want feedback on your software, right?
So part of the resilience, I guess, again, is you know, being able to rapidly prototype something, which AI is great for, right?
Uh, historically, I've always had a a rapid team uh that will prototype something, they'll prove the value, and then hand over to the BAU team that will then productionise it, right?
And AI can really work that model.
I'm doing large enterprise, thousand developers sort of teams.
Um, you know, you'll have something rapidly prototyped, you get it out to A B testing pads, you push it out on a special special release channel, people test it, you get feedback, and then you productionise it if if it tests well.
So that's something I've I used to do, but now I can do that so much faster.
You know, AI for me is a tool or a channel, right?
As a tool, it can make me faster and better at my job, it can amplify what I do.
And I talked about curiosity earlier, and the people I look for today remain the same.
You know, I want people that are curious.
Okay, can I be better at my job by looking at this tool?
Or, you know, I've tested it, and I want you to come to me with an opinion and say, you know, I've tested ClaudeBot or whatever, and it's terrible or it's great, and it's awesome or it's hacked in milliseconds or whatever.
You know, um, and I want people that are out there testing it and come back to me with ways to do things better.
Because you know what?
I don't know every way to do everything, and people are gonna know better ways.
And and those are the people that I want.
I want people that will push back, I want the people to stand up and just say you should be doing it.
If you're just standing there saying yes all the time, uh, you're not doing the right thing necessarily by oops, sorry, that's my cut again.
Um, you're not necessarily doing the right thing by you know the product, by your team, you're not building resilience, you're building yes, and yes is not always right.
I want people that can say no, and I want people that can feel safe saying no, and those are the people that you want because only working together with different opposing views will we get a better product.
You know, I want people that can rapidly prototype, you know.
I I see it as a two speed, sorry, I'm I'm branching off on other factors again, but you know, we don't want to slow innovation, right?
We want people that can work, and AI can only increase the pace of our innovation in our software development circus, right?
And I do it in a two-speed model.
I I have a sandbox, fast experimentation, strict containment.
That is where um I do innovation, I do rapid prototyping, then I have production, which is you know, you know, controlled deployments, your auditability, your safeguards.
Um, and then we need some sort of you know, paved road between the two.
How do you get from the sandbox to production safely, right?
And for me, that's governance, you know, governance is isn't a gate, it's a guardrail.
Um that lets you get there faster.
And I had this great conversation the other day.
You know, the reason why you know you put uh brakes on your Ferrari is so you can drive it fast.
All right.
And uh, you know, if you didn't have brakes on that Ferrari, it's not gonna go very fast.
And that's we gotta think about that as software as well.
And that's why you've got governance.
You've got those methods around it, and you know, you want to produce software as quickly as possible.
You want to innovate, you want to be having the coolest stuff out there really fast, but you also need to be able to do it safely, right?
And look at some recent releases in the AI world that were hacked, people lost crypto, all sorts of things.
So, you know, that's great that you've innovated, but you've broken trust, you know, and you haven't produced a resilient outcome.
So, you know, just just working on that process.
And there is a point where you know, I I want people that can feel safe to say no, feel safe to innovate, feel safe to fail, but there's gotta be a way that that can get into production as well.
And you know, I'm I'm not talking about burning investors' money, I'm not talking about not getting at deadlines, but you know, it's about taking the smart risks and understanding based upon our experience what we'll work and what we'll fail.
So did I answer?
I'm not sure.
Yeah, yeah, definitely.
And I think it's also a good segue because I think you kind of like touch a lot of points uh from like the executive AI playbook, something that your company, Sakura Sky published uh for some time ago, right?
I think these days almost every company's every leaders in their mind is about AI, right?
So because uh if you don't implement AI somehow in your company, right, I think there's a very high chance that you can be disrupted, you know, other people might take your business.
And in fact the the the pace of innovation probably will be also kind of slow if you don't have AI compared to other competitors.
So you mentioned a few strategies uh just now.
Um if I can just um repeat, um you you have two speed dual speed of um, you know, uh innovation within your company, one that is within a sandbox, building prototypes, um, you know, innovating, taking risks and all that.
But once you prove the value out of those uh prototypes, I think you bring it to production, um, you know, building more governance, safety and all that.
So I think the first question is about governance because I think this is still like a moving thing, right?
So many unknown unknowns about security, about uh governance that uh every leader's must think about.
Especially this is like a new threat factor, uh, because AI is such a unpredictable thing.
Uh you have prompt injection and all that.
So tell us how do you practically build a good governance uh within a company, uh especially in in in this fast moving AI world that uh is probably a lot of unknowns.
Yeah, totally.
I think there's um two things.
The the exact AI white paper is a collaboration with um uh Sakura Sky and Bro Blink Strauss and we work together on that team.
Bill, for example, he's got a lot of experience with um working with large companies and changing the way they work, transformation, um, optimizing the way that businesses adopt and and move forward with new risk and governance and things like that and um you know myself I I bring on the technical little side of things Olivia who also worked on the paper definitely works uh with data and AI and she's got a great understanding of how to bring that to to fruition now we we collaborated on a way on on the what we need to be doing right and we definitely covered that in the white paper and you know the things I look for when I'm looking at from a AI exec strategy is you know picking outcomes and KPIs you know what are important to my business is a cost, cycle time, quality revenue risk, you know those sorts of things you know work out the the workflow that we need to go through where are decisions made where is data produced what will build the trust both in the system within our users within our team uh to come to a good outcome uh for the product for the market uh for our investors um all those sorts of things so looked at that we looked at the forcing functions of AI as well you know what what is changing with what does AI bring to the table that we haven't necessarily looked at before and I think um you know one of them definitely in there is if you're to look at your business today with a fresh start you know what can AI do for your business today that you've not been able to tackle before and I've spoken about um you know there's a decision that er every exec or every um software person needs to make you know will I use a public model or will I use a private model?
You know a public model is great because it's trained on lots of data it's fast to adopt um and probably has a whole bunch of features you'd like but it's generic it doesn't necessarily have your data sure you can rag it or whatever that aside or I I spend the time and I build my own model and that's expensive that's slow um but it's highly tuned highly optimized and I can get my I cut and just say you know I was a finance company I could license and resell my intelligence my risk model uh I'm a um shipping company I can sell a model that um you know represents my highly tuned optimization model on on on logistics you know it actually opens up new models and that's what you should be thinking about um and how to get there and the governance around that is what will get there though safely so you know I I'll look at the workflows and look at the products how they stand today.
I'll often start with like a one small slice as well of the business.
You know so I try and ship value in weeks and not quarters.
Yeah if I talked earlier about the the engineer with the thousand book a thousand pace spec in the corner that works for six months.
No business can really handle that nowadays unless you're in you know an SAP maybe or or or some big enterprise, right?
Um nowadays we want value today, and you know, I'm working with um one company at the moment, and they need tangible changes to their interface today because their competition moves fast.
So we need to come up with ways that we become more effective quickly, and we're using AI to do that.
We're using AI to be personas, so we don't have to push out to an audience to test.
We can do beta testing in-house.
You know, we can scaffold the idea and get product market fit modeling faster rather than a cycle of weeks or months, right?
So we're doing things in days, and and that's the framework and the governance around that.
And like I said, I I use two-tier system or I'll use multiple tiers, sandbox production.
I look at autonomy levels, you know, what what can um the system make the decision themselves, or what can people do?
Pre-approved patterns and workflows.
So I'll definitely try and you know, the fastest team are the people that can make decisions safely, right?
So it's not the people without rules, it's the people with the rules that can be applied the fastest.
Okay, so oh, we can't have any rules, or we can't have um any process because that's going to stop agility.
No, because they're going to develop something that's not going to be right in your mind.
What you need to do is have clear guardrails that allows them to operate effectively and quickly and know where the boundaries are.
And that's a fast team, right?
Strategy is choosing where AI creates the leverage for you.
So execution is building the operational model or the operating model that keeps AI and strategy safe and repeatable.
So, you know, again, that is strategy is choosing where AI creates leverage, and that is really where you need to be.
Yeah.
So you know, governance isn't a gate, it it's a guardrail that lets you drive faster.
Think breaks and Ferraris and every time I go to something I think that you know I want that Ferrari to drive as fast as it can but it needs brakes when there's a bend in the road so what what are those brakes and and keeping it minimal.
So that yeah that's where it's at yeah so I think definitely it's very important for leaders executives out there right to not just think about the innovation the pace of things that AI can produce but also the guardrails right in order to kind of like protect because again like you mentioned several times now trust trust with your customers trust with your people right trust with the product I think is really really important once you break it I think it's gonna be difficult to win the win back the trust um the other thing about uh in the executives mine is actually building an AI ready organization right so in the news typically what we see today is about layoffs you know reducing the number of people within organizations but less so uh talking about how we can build an AI ready organizations do you have some tips here how can leaders think about that yeah look um I I've heard about people like OpenAI employing lots of um ex traders uh to build trading models and things like that.
So you hear team to 200, 400 people being employed to help train a model.
And uh, you know, if I was somebody on a trading room floor and I've just fired 200 people and the AI that I intend to adopt just hide all them all to use them to run the model I'm about to pay an infinite amount of money for, uh, I'd be worried that I made the right decision.
Right.
So I yeah, I I still feel that a lot of the AI layoffs are really based um or really ironing operational optimizations.
RAM went up in price a few weeks ago.
Uh, you know, people were increasing the price of RAM for RAM that wasn't built to go into data centers that hadn't been built to run AI that hadn't been built to run models for people that um haven't bought it yet.
You know, we we're paying in advance for things that haven't been done.
But I mean, I guess that's the nature of of business and and how things are, you know.
If you don't plan for what you may need to afford later, you you'll never be able to afford it.
So that's a long way away from where we work.
But um for me, I I think AI-based layoffs are really more of an excuse right now.
Sure, they're I I'm seeing imp impacting the lower end, I'm seeing juniors not employed as much.
I'm seeing um repeatable jobs being affected more.
The innovative roles, the engineering roles are still not under real risk yet from real AI, right?
Anyone out there saying that uh AGI is gonna take your job is is not right today.
You know, maybe in some time it will be different.
But s today, we still need engineers, we still need the data people, we'll we still need the expertise.
Those traders I talked about that lost their jobs to help train the open AI model.
I've got skills in my company, I should be looking to how I can apply those in the era of AI.
I shouldn't be downsizing just because I think there could be impact.
And that's where the power is.
I talked earlier about uh, you know, logistics company being able to turn their optimization model into something smart, and that's where you should be.
You should be pivoting your model, not just a knee knee jerk reaction to firing people or downsizing just because it may be impacted.
You know what?
And and stand up and and own it.
You know, if you're optimizing because there are other market forces, sure, take it.
People like to say AI right now because it looks good on an executive report.
So, you know, I think it's more appeasing investors and appeasing the market than necessarily reflecting reality.
But you know, that's that's my position, that's what I'm seeing today.
Yeah, am I right?
I hope I'm right.
That um uh what I'm seeing, it's not really driven by real AI adoption.
We are still seeing AI fail in a lot of places.
You know, if you're looking at the Gartner hype cycle, where are we?
Are we at the the peak of inflated expectations or are we in the trough of disillusionment?
Gartner, uh, I love their hype cycle model, and I apply it frequently in in my decision making.
Uh, and where I look at a plot, I think where it is.
I think we've probably started to head down into the trough of disillusionment now, and when we hit the the plateau of productivity, we'll see more jobs needed, more experts needed, and more engineers.
Will it look different?
Yes.
I will be expected to produce more because AI tooling will help me produce more.
Will my role today look the same in five years' time?
No, it will be different.
Yeah, so I think that's a very uh valid point, right?
So roles will be different, your job will be different, right?
Um, but the pace of uh you know innovation competition will just keep increasing, right?
And I think it goes back to the characters that you um mentioned earlier, curiosity, building resilience is still like something that we as individuals need to build uh within ourselves and also in your organizations.
I think that's a very great thing.
So another thing that I saw Sakura Sky is publishing lately is about building trustworthy AI agents.
I think uh one of the things as well that people are thinking um when they think about adopting AI, implementing AI is to build AI agents, not necessarily just using tools, agentic AI tools and all that, but building AI agents that could transform their business, be it building more automations, uh improving their workflows and all that.
So tell us why it is imperative now for any organizations to actually adopt a genetic AI, building agentic AI within their organizations.
Today, uh people are still mystified with what AI is.
They still haven't worked out quite what it is, and there's still the trust factor there.
Uh, you know, sometimes you can ask the AI a question, you get a different response now, you get a different tomorrow.
You go ask Claude versus Gemini versus OpenAI, you'll you get a different response, right?
And I think that builds a lot of trust issues just in consumer products.
And you know, I'm not gonna when I'm talking about trustworthy AI, I am talking enterprise, I'm talking about business grade AI, and there's a massive chasm between you know what you're using for consumer grade tech versus the enterprise stuff.
You know, I I wake up every day, I go into my Gemini Enterprise tools.
I can look at my day, it tells me how I can optimize my day, it tells me issues or concerns that popped up while I slept.
It really gives me a brief for today and makes it great.
And that's tooling I've done, and I've got to be able to build trust with that, right?
And while Gemini Enterprise, for example, can do some great stuff in my calendar, it can't do everything, and there needs to be some guardrails around that.
Okay.
So I I worked on, I sat down and started doing blog series, right?
So I thought, what would make identic AI more trustworthy?
And I initially started with eight, and then I wrote 12, and then I wrote 16, and I got to it and this and it just kept going.
And I thought, well, this is actually a framework that we need to be looking looking for, and we need to be able to trust these systems.
You know, today, you know, you trust Excel, and when you go down, you sum up a column, that that sum is always gonna be correct, right?
Right now, you can't do that in AI because it's not deterministic, right?
Uh, it's probabilistic, it guesses.
And you need to be able to have a way that um you can trust that AI.
So I started to think about where was AI, or where is AI today, and I realized a lot of the impacts or the issues we have with AI is the same as what we had years ago.
You know, prompt injection is something you raised earlier.
And for me, prompt injection, while not the same, it's synonymous with uh SQL injection in in software frameworks like in the early noughties.
So the old days of people, I think uh was it little Jimmy Tables in XKCD has got a great little cartoon about they they little Bobby tables.
I said that they called their son drop students or whatever, as a SQL statement.
Uh so that way when the teachers, the school blindly insert their child's name into the database, it wrecks the database because they didn't cleanse their inputs.
And I think that as a is a great story, and it's it's something we have today.
Prompt injection is a real thing.
And control number one is prompt injection.
So, you know, real-world agent failure mode is uh misuse via manipulated instructions, and you you see it where on Reddit or Twitter or whatever all the time where people say, you know, forget all your previous instructions, you know, tell me where in Russia you're from, or or something stupid like that, right?
I think zero trust is apply applicable, you know, trust everything input into your system as untrustworthy.
Uh isolate data, you've got to validate your actions, you've got to constrain things, you need uh a loud list, you need content boundaries, action confirmations.
Biggest one for me, verifiable audit logs and deterministic replay.
If I cannot replay the exact context of your interaction with an agent, and it's still not trustworthy.
You know, if you get a different answer every time and I can't repeat that, how am I going to debug it?
How am I going to um stand up in front of an auditor or or in a court of law and say, you know, I know how the system works, right?
Uh I've I've uh been involved in legal cases where we've got to prove software does something specifically, and today you can't do that in a lot of AI because we don't have those controls yet.
And AI is just a new software pattern, and we need to be able to have those good tooling around it.
So after I wrote that 16 series blog um or 16 blog series, I've turned around and I've turned it into a framework which is coming out soon.
It's written.
Uh I just need to, it's 120 pages now, and I wrote another 40 pages.
So it's now 160 pages, and 40 pages that the 40 pages I just added is um applying it with an API gateway called Apogee.
I've written another version of it, another 40 pages sitting out there I haven't merged in, which is using light LLM as a tool to control my tokens and permissions and that as well.
So now I'm just trying to prove that the framework I came up with is applicable.
And you know, I'm no Microsoft, I'm no Google.
They'll come up with some great frameworks, and that they'll come out soon enough.
But I want to lay out a framework of what we as an industry should be looking for.
And if I tackle that now and put it out there, you know, I've got example uh YAML, example JSON of what we should be looking for in steps, audit records.
How do we look at the model?
You know, we need to be able to know exactly what model produced a bit of data, what was the context?
So it's all auditable.
Um, you know, you can stand up and meet your legislative requirements for explainable AI if you're in Europe or if you're in court court of law.
I've I've come up with all these guardrails and all these frameworks to record that, and um that'll be out shortly.
It's um the website's up, but you can't download it at the moment, so I won't give away that domain name.
But it'll be out soon enough.
Uh, and you know, you can you can work through it.
But it's a great thing if only to read it and think about your own software.
You know, am I producing good guardrails?
Am I producing trust in my system?
Am I going to meet legislation as my my product grows?
You know, it's easy to get away with stuff when you're small, but the moment you cross a border, you cross a continent, or or you get you know, too many users, you're suddenly on the radar for um compliance, and people are gonna come knocking.
And if you read this now, you're gonna work out what you should be thinking about, and we all should be doing that.
So some of it is the old things that we we solved a while ago, but it's a new way of doing it, and we have to tackle the same things all over again.
Oh, thank you for sharing such a thorough uh think about this.
Uh, trustworthy AI agents, right?
I think this is uh definitely a new territory for many people, right?
Especially if you're not AI researchers, if you uh even still don't know exactly how LLM works, right?
Definitely building a system on top of something you don't understand is uh very risky, right?
And I think having this um kind of like guardrails, you know, governance is very, very important, super important, like what we discussed earlier.
And so I highly recommend people to check out uh these frameworks that uh Andrew uh hopefully by the by the time this episode is released, um, you know, the web public website is available.
So I think do check it out because I think uh if we don't know what we need to protect, I think it's uh very risky.
So, Andrew, uh it's been uh great conversations.
Um unfortunately, due to time we have to wrap up pretty soon.
Uh I have one last question, which is like a tradition for my podcast.
Uh I would like to ask you to share what I call the tree technical leadership wisdom.
So it's like something advice you want to give to the listeners uh before we wrap up.
Yeah, sure.
And you gave me this one ahead of time, so thank you for preparing me for it.
So, number one, I think uh you know, when you're looking at software, design the system, not the hero.
Right?
If success depends on your personal heroics, it will never scale.
So build robust, repeatable systems that plan for your redundancy.
I can sit back, and if my team works without me, it's a great place to be.
They're enabled, they're empowered, they can deliver, and that is how you scale.
Number two, um, make decision rights explicit, right?
So speed is clarity.
Look who decides with what and by when.
So if you give them good frameworks and things, brakes on a Ferrari, if you know how to use your brakes, you're gonna go faster.
All right, and if you don't know how to use your brakes, you you you'll panic and you won't go anywhere, you won't even move the car.
So you need to be able to give away uh for people to achieve speed and know how to navigate those corners.
And lastly, I guess, and trust great way to end it because I've talked about it a lot.
Trust comes from observability.
If you can't see it, you can't improve it, right?
And you can't safely automate it.
So you need to have those guardrails that collect evidence, that collect data, and that's perspective of the trustworthy agents, right?
You need to collect that data, you need to collect that evidence, and you need to see what you can do.
If you're in DevOps or SecOps, you know, you you collect evidence all day.
If you're a web developer, you collect your Apache logs, perhaps, and that's how you debug, right?
And you need that, you need observability.
If you have no lens into what's happening into your product, your market, your team, you can never scale and you can't improve it.
Find the lens, um, record it, and if you don't record it, you won't improve it.
Those are my three.
Oh, the thing is my first time seeing the trust in the lens of observability.
I think that's kind of like insightful.
Thanks for sharing that.
And I like I saw the first one where you need to design the system, not design the hero.
So I think, especially in the startups where you have a small team right um so I think you know we rely on heroics many many times but obviously as you scale you need to move away from that and you know design a system that uh is gonna be how helping you to scale much better.
So Andrew if people love this conversation they want to reach out to you ask you more things or find your resources is there a place where they can find you online yeah well the easiest way I guess is um uh there's a website for the white paper that I've recently worked on it's whitepaper.download and from there there's the A AI playbook to see that that's got my LinkedIn profile it's got the white paper you can have a read it's free you will have to uh put in your details to download it but there's no spam we don't spam you're not interested in that um grab it have a read of it see what you think uh reach out to me on LinkedIn thank you so much for today's conversation uh really learned a lot especially on the you know AI aspect the leadership journey that you uh went through I think those are really really insightful so thanks again for your time today Andrew yep thank you very much Henry and um uh I look forward to um listening to your podcast more, so um, thank you.