What Enterprise AI Looks Like When It's Real - with Lawrence Whittle of HTEC Group
The AI in Business Podcast · 11 May 2026
Source: https://podcast.emerj.com/fixing-the-pilottoproduction-gap-in-enterprise-ai-with-lawrence-whittle-of-htec-group
Transcript: https://podcasts.opennash.com/shows/ai-in-business/what-enterprise-ai-looks-like-when-its-real-with-lawrence-whittle-of-htec-group-c844a3/ (via OpenNash Podcasts, machine-generated)

Welcome everyone to the Emerj AI in Business podcast. Today's guest is Lawrence Whittle, Chief Strategy Officer at HTEC. HTEC is a global engineering firm focused on A I centric software and hardware development. It works across financial services, med tech, automotive, telecom and enterprise software, helping large companies solve complex engineering problems. The team is distributed across more than twenty engineering centers. Lawrence joins us on today's show to confront a problem many enterprises now face.

Pilots that look promising in the lab, but fail to deliver when scaled. It draws a clear line between individual users, isolated use cases, and the end-to-end sequences that actually create business impact. It also surfaces the shift in culture and cadence required for a I to work in the real world, from smaller real deployments to tighter cycles and a bolder mindset that replaces long planning horizons with continuous delivery. Today's episode is sponsored by HTEC.

For our solutions partners, position your brand alongside the Fortune 500 leaders defining the enterprise A I roadmap for the opportunity to showcase your solution to the executives currently funding and scaling global initiatives. Partner with Emerj, secure your partnership at go dot Emerj dot com slash partner. That's G o dot E M E R J dot com slash P A R T N E R. Now the conversation with Lawrence. Lawrence, welcome to the show.

Thank you very much. I'm looking forward to this discussion.

Yeah, so I want to start at something that's been bothering me for a while. Every time I open my inbox lately, you've probably seen the M I T. N uh. Nanda number still doing the rounds. 95% of enterprises. Gen I pilots delivering zero measurable R O I. There's really credibility. Wob wobble happening in the boardrooms. Everybody's saying A I, A I, A I, and in pilots in the lab, they're working perfectly. And in when they try to scale them and deploy them within the enterprise, that's where they start seeing that.

All the work done in the lab is just not returning the way they were hoping and expecting to. So, uh, especially across financial services, when you get to regulated industries, there's just another bunch of, um, add-ons that makes it more difficult. What's the gap between companies, what they expect and then what actually happens when they start deploying?

Yeah, I think it's a great question, and um, I sort of like to give a little bit of a modern history lesson. So if you sort of step back to 2024, which I think was the first time when the A I word came into everyone's vernacular. I think it was obviously established. A I is not late breaking news. It's actually the technology that I've been involved in is. I was doing A I before it was called A I twenty years ago.

The early branches of A I being machine learning, uh, were established a long time ago. But if you sort of go to 2024, you started to hear a lot about A I. You started to hear about Open A I, Chat G P T. Um. And so there started to be a lot of sort of interest. And I would say not so much pilots yet, but sort of maybe discussions and, you know, sort of evaluations around tools.

Um, as you got into late twenty four and early twenty five, that sort of momentum around pilot started to pick up. And then sometime around Q one of 2025, we started to hear this term agentic. Yes, and everybody So

added on their lips, that's all we heard about.

that's right. So if you think about what was happening, natural, it's the natural adoption of new technologies. I've been around Silicon Valley for twenty five years. There's sort of the early adopters, then there's the early majority, then there's the majority. And they go through various, uh, cycles. There's this, uh, well understood term, the the Gartner hype cycle. So I think what happened is that 2024 people were starting to do evaluations, very early pilots, and then Q one, agentic came in and people said, Oh, I need to have the agentic version.

So then we, to some extent, started that pilot process again with agentic, um, and that started to pervade, I think in, you know, Q two of last year and and Q three. There's been a number of surveys that have been published, whether it's M I T, whether it's Gartner, and it's almost, um, confusing because whenever the survey is published, you have to look at when was the actual survey taken.

Because it moves so quickly.

Because it's moved so quickly. So what I think I like to describe is what I call the anthropic effect, which if you look at anthropic Claude, a year ago, only experts had really heard about Claude or Anthropic. But if you look at their growth from the middle of last year, where they middle of 2025, where they crossed $1 billion, which is huge, they started the year at 100 million. By the end of twenty twi 2025, they were 15 billion, of which the vast majority of that was in the enterprise.

So what I think happened is there was a lot of pilots in 2025 that were focused on use cases where it wasn't necessarily easy to identify value. So the pilots were ticking technically, but not necessarily focused on value. Then what you saw is late 2025 and early 2026. I think executives started to say, I want people to adopt A I at scale, but not necessarily at use case scale, more at user scale, because they saw enough early signs, but not enough pure value.

So I think the reality is the timeline is a little bit confusing. I think what happened in the majority of 2020, where there's a lot of pilots to prove out the concept of A I versus proving out the value. And then towards the end of 2025 and into 2026, people started to move towards adoption. And now I think there's a lot more focus on value. So it's really about a time series and depends on when you actually interview people and when you published.

And then everybody's in a different part of the race. Some people are still not at agentic, they're still trying to get there. And especially when it comes to regulated industries, because it lags behind. I'm saying lag behind, but really, it's that's not, that's not completely true, because sometimes regulation actually drives the, uh, technology, which means, especially in banks, sometimes they can be further ahead. And then you've got health sciences, because it's life and death, that that obviously, lags slightly behind.

So what was interesting to me, what you just said was use case versus user, and we still h hear a lot of executives talking about use cases. Can you explain to me even deeper what that means on on the executive level? How do you look at this differently, this use case versus user, uh, scenario?

Yeah, so I think there's, there's actually a third dimension, which is end to end use cases. So users is someone that has a license to Claude Code or, you know, GitHub or Chat GPT. Um, and, you know, they are using it from a personal perspective. So maybe they're using it as a most people sort of an advanced query or an advanced search. I think a lot of advanced users are using it for deep research. So once you understand as an individual how to prompt, but it's basically for my own use.

A use case is where there is a specific business process where there may be multiple users that are going to utilize the particular A I. For example, it could be a next generation, uh, chatbot that is going to support incoming support requests. When I think about the end to end use cases, which I think is where people aren't yet, that's where you've got a sequence of use cases, a sequence of workflows that is driving an end to end value.

Where you can actually start to see, you know, I spend X dollars, pounds, euros, I got y return, and the return is based on either, you know, increased sales, reduced costs, or increased productivity. So

The the the business, uh, the the bottom line, that's, that's

yeah, either top line or bottom line. I think there's certain use cases that can really drive increased conversions, hopefully at a lower cost, but not necessarily always at a lower cost. It may just be a higher velocity. And I think that's where, in financial services and regulated industries, they have an interesting challenge and and also an interesting opportunity. Because, yes, you have the regulatory framework, but they have a lot of data. So they have a good advantage.

Historically is.

And they can delineate elements of the data and associate it with use cases that aren't necessarily regulated use cases, particularly like customer support use cases or, you know, top of the funnel customer acquisition, where that process, whilst it's regulated, is not regulated to the same extent as, you know, a loan application or a credit card or an underwriting process. So I think you sort of need to break down the subjects and to summarise the question, there were a lot of early sort of proof of concepts, some early pilots, then grab mass usage.

Now think people are back to use cases and the early signs of end to end workflows.

And where do you think they're getting stuck? Is it a matter of they just don't have the T teams to? They've got the ideas and they've got the use cases, they've got the users, but now bringing that all together and getting a solution. Is it that they're stuck in that process they need? I don't want to say assistance, but they need somebody coming in in and actually helping them work through getting that value. Because you said concept to value, do they already have the concept?

They need the help to get to the value.

So it's an interesting question that I ask a lot of my clients on a global basis, on a frequent basis. I don't see any patterns yet regarding, um, the why. What I do see is two categories. When I say I don't see any patterns, I don't see sort of financial services having issues here versus retail not having issues here. I think the challenge very much is understanding where you are up to in that sort of maturity curve.

So I think that, you know, high-tech companies are duty-bound to cannibalize themselves with A I. So they have a clear view of the what I should build and the how I should build. So what is the what is the use case, what is the business case? So it's a use case and the business case. What is it I wanna achieve? How much would it cost? What do I expect to get out of it? And what tool should I use?

When you get into the more, what I would call just non-tech, you could say traditional, but I think just maybe say tech versus non-tech. I think that the majority of companies have some hypothesis on maybe where they should apply A I, but are not yet at the point of really understanding what they should build. And so I think there's sort of a categorization of hypothesis, but the actual and the challenge for this is that whatever people think about how powerful A I is, when you're thinking about at the enterprise level, this is not plug and play because you.

You've now got the need to understand both the subject matter, banking, the use case, a particular domain use case, as well as the technology. And so there are very few people in the world that have a volume of people that can actually do all three of those, you know? And and I think even the technology market historically has delivered, you know, product management separate from product build and product implementation, whereas now you have to have this really integrated.

And I think one of the reasons why my company HTEC has actually really accelerated during this period is that we never got into the business of building products for long term implementations. We very much have this agile approach, whereas most enterprises have this M, sort of momentum where you spend, you know, six months deciding what to build. And then one to two to three years to deploy, and then you see what.

And everything has changed by that time. It's it's all changed.

And it's a change, and it's a D N A issue, it's a skill set and a D N A issue. Even large enterprise software companies are struggling because of the cycle times and the fact it's way more of an integrated process. So I think it's tech and non-tech have different challenges, but I think in the enterprise, you've got this D N A and skill set gap that is new. And I think people are starting to discover that, whilst this can be really rocket fuel, these A I solutions, you still need an expertise which is not that visible in most companies.

I think, and we, we hear it across industries, the skills gap that is really becoming a problem. The skills gap is, uh, it's widening, and it's it's already been big for a while, and it's definitely widening, which is great for people that want to come in and fill those gaps. Uh. But the enterprise is struggling with that. If I want to play a bit of a devil's advocate, it obviously, we've, we've heard it so many times, like pilots are just not scaling.

But then we, we do have a quite a big part of the audience that's saying, but we have to fail forward and and failing is a way of of learning. So how do you balance that between learning internally and failing, but also getting to the value? To me, it seems that we've sort of bridged that gap and and though you can, let's say, on the back end, still have sandboxes where you're learning, you do still still need those projects that are driving value.

Otherwise, the company's going to lose their appetite for technology and A I, and they'll just fall behind when it comes to their competitors.

Yeah, so I think it's, it's, it's sometimes a semantic discussion, but I think we need to sort of put an X through the the term pilot, because the problem with pilots is that people aren't necessarily committed. They're investing a relatively small amount of money with not necessarily an expectation of an outcome. I think what you need to do is to look at more smaller deployments where it is a real deployment where maybe the value, the cost and the value is not significant, but it is really

It's the momentum.

momentum. Because what I think you need to get is momentum. So once you start to see, actually, I invested X dollars for Y time period and I saw X return. Even though the absolute return may not be massive, it's clearly cause and effect. And then you say to people, well, do we have any other analogous areas where we could deploy in this? And then you start to get momentum, and that momentum then really accelerates. So think about that again.

It's a, it's a different approach from the past, where you would have a, you know, a multi-year program with work streams that literally go forever. Whereas now you need to sort of iterate through in like, it's what's technically called sprints, but you need sort of sprints in a literal sense in terms of business.

And I think that ties back to what you said to concept and value. It's, uh, the concept must be tight enough to clearly see what the value could be, because that's where you will get the momentum. And and I like the fact that you say that ratio needs to be very tight between your investment versus what the value can be. And even if it's small, it's the the ratio that matters. It's that you can get a quick, quick return on it and then, uh, start building that momentum.

And I think learning that way, uh, sort of it, it feels itself within the company because when you see what has worked. And it's probably more the approach than the the actual solution that's important, it's it's approaching it in the same way, no matter what the concept or what, what the idea, what this, what you're trying to solve. So if if we're discussing this in a sense of practicality, what are companies, what are enterprises having to look at, um, investing in at the moment?

Is it taking the time to really, uh, define those cases where you can get that quick ratio, that the return on investment? Or how would you approach that? And where in the company should that be sitting? Is it on a department level that everybody in the company should be trying something small, um, tasting the success and then taking it further? Or is it more a top-down situation where it's one deciding on one within the enterprise?

Yeah, so if you think about again, the, uh, the term I used earlier on, the anthropic effect, the growth of anthropic was somewhat organic, it was bottoms up. And what I encourage C E O's, I was actually talking to one this morning and I asked him, are you personally using A I, as in personally using A I? And he said, I'm embarrassed to say no, and I said, well, you shouldn't be embarrassed, but if the C E O is not embracing it personally, then maybe that's gonna be a bad for the whole organization.

So I think you need to sort of establish internally a baseline understanding that you don't wanna leave anyone behind, whether it's the janitor or the C E O. There should be some base level understanding. So I think enabling the organization to understand what is A I, to get everyone to a baseline, or maybe baseline plus one is super important. So that's sort of a top down initiative. Everyone to be familiar. I want to have a strategy where there's a framework of what tools can be used and how they can be used so that you don't leave anyone behind.

I think that's super important as a top down. But then maybe not bottoms up in terms of individuals, but certainly at the department level, you you need to sort of set some top down objectives that I want each department to spend a significant amount of their time to identify, maybe with external help from companies like HTEC around. You've got a hypothesis, now validate those hypothesis, come up with a roadmap of deployments and communicate that systematically from an organization perspective, so you don't have duplications of effort.

But also you actually have a forum for shared experience. So top down from a, uh, encouraging people, janitor to the C E O, to adopt A I in their own life, obviously within the framework of what's approved. A top down sort of strategy to say, at a department level or a region level, encourage people to validate hypothesis, use cases and set objectives around. I want you to deploy X number of use cases over Y period, but have a framework where they're not rogue, out doing stuff themselves.

So it's a little bit complex, it's multi-dimensional. I think it's partly top down, it's encouraging bottoms up, and then having a reconciliation in the middle.

And this is actually extremely practical. A as business leaders, you really, this this is a strategy. This is a mind shift. And looking at this, um, very intentionally and strategically to a sense. And if you say motivating, let's look at the top down, that motivation, does it look like K P I s? Are you telling people that there's a certain level of A I usage you need to get to? That could, uh, become difficult to manage, I guess, as well.

You've, you've been sitting with companies where it does work, we, we've spoken about where it doesn't work, where it does work. What is that difference that you've seen?

You know, it's a sort of carrot versus stick, um, discussion. Um, if you, if you lay out very strict K P I s and monitor those very religiously, depending on the size of the organization, you're likely to get very indifferent adoption levels. Because on average, people work better to be motivated with a carrot versus a stick. So I think if I'm sort of telling people, you know, don't over rotate towards you must do this, but do create a framework where you are setting a vision for the company that by a date, we need everyone to be adopting at scale.

And the reason I said it is that we as a company made a. I mean, we've been doing A I, you know, we're, we're not a huge enterprise, still pretty big, you know, with two and two and a half thousand people. And, you know, we recognized that we've been doing A I for a decade, but not everyone was doing A I. And so 2024, we made a very clear decision that we wanted everyone in the company to be certified to some level of proficiency, and it was optional.

And then what we started to see is that different people would prioritize. So then we made it, um, not mandatory, but we started to have some characteristics that you would be rewarded if you adopted things earlier. Ultimately, you could turn it around and say you're penalised if you don't sort of jump on.

The the. The reward sounds better.

Yeah, that's right. So you start with a framework to encourage people, then you see who's adopting, who's not adopting. So you come up with a reward framework and then over time. So I think you need to sort of recognize the the D N A of your company and the GE and the demographic

Now your culture.

and the culture and the geography, uh, because geographies can be different as well. Um, but I do think you need to reward people and encourage. So you start with encouragement, then you go to reward, and then ultimately you maybe need to push people. Because for large enterprises, it's just not the way they've operated. Even for you know, if you think about large systems enterprises, amazing companies like Accenture or Cognizant that are hundreds of thousands of people, enterprises haven't worked on this level of velocity.

They're more sequential programs as opposed to rapid deployments. And I think that's what the that's why I think the D N A opportunity and issue is is that people are used to multi-year projects and the results you get at the end of the, you know, you get milestones along the way, but the results are sort of two to three years. Whereas now you've got to figure out where can I work on something where the results could be in ninety days and then another result in ninety days.

So I think you start off with a framework to encourage, then you add reward and then ultimately you may add pressure, um, based on the speed of your organization, your own culture.

And I think if I were an enterprise leader, I would, I would want to tap in. I'm not going to put you on the spot right now, but I would, I would be very interested in, in what that process look like, looks like. Um, I've heard in some other companies, they've got, uh, what would you call it, uh uh uh excellence, uh, what do you call it? Enterprise excellence unit, where it's, it's very much driven through and.

And they're weekly or monthly meetings where they literally got rewards in the sense of you win tickets to this, you win tickets to that because of your usage. And that sounds simple, um, but we're all human. You are incentivized by being rewarded, and I guess there could be some real great strategies that you've seen before when it comes to reward and then working it through until pushing it. So I would say, like a lot of enterprises who do not have, they've got that skills gap and they now need to consider bringing somebody in a vendor.

Uh, but they all come in with use cases that look like shiny decks and and they've proven it. How? How do enterprises distinguish between, um, is this going to scale and deploy within my company, or is this just a great idea?

I I think again, it goes back to the the the basics of of speed and identifying things that you can achieve in a rapid amount of sense. Because you, you're absolutely right. Um, you know, the the consulting world, we're, we're not a consulting company, but the consulting world has has got, you know, an in an incredible reputation for delivering amazing content. Yeah, you deliver the fifty powerpoint slides and everybody says, okay, nothing really happens. I think you have to just be a lot more pragmatic.

I think you have to treat this as a, you know, as a mission that we're all going on, but not like a program that is gonna be treated in the same way. So I think the the the thing I've seen work so well in larger organizations is when they think about this differently. It's not like a, it's not another I T product, not another I T project, it's around enabling the organization to become more efficient. And you typically find that asking people to put their hand up who wants to be part of this and then showing and telling cause.

I think the shared experiences are what we're seeing really accelerate the momentum. Because, you know, if you have these massive organizations that have, you know, massive projects, you know, with with a with a name of the project. Whereas if you sort of create this environment where, you know, rapidly iterate, show and tell, then you get momentum and more people raise their hands. So I think it's more of a, um, you know, an approach, you know, there's obviously show me the money is always gonna get board levels of, uh, attention.

And typically there are some use cases which are so huge in terms of R O I. But our point of view is that, you know, ten use cases that generate $1 million versus one that generates $10 million. You're probably gonna get way more momentum on the on initially, e especially, and then once it starts, then you get momentum. So I think the net net is find a way to get momentum. And those organizations that encourage, reward, and then highlight.

It's interesting. We have a weekly AI newsletter and one of our massive clients, I'm talking, it's a fortune one hundred company. And we were talking to them, they asked about us. We said, Oh, you have this weekly newsletter. And they said, Could we use? Could we see it? And then they said, Would you mind us? We repurpose it. And it's really just an awareness mechanism because, you know, and and highlighting, you know, really, maybe small, small achievements, and then you get momentum and people start to be competitive, et cetera.

So I think it's a lot of it is is culture and approaching it in a different way, not the normal. Hey, let's get the normal people involved, the normal partners involved, external partners. Let's go on a long journey as opposed to let's, you know, go on lots and lots of things to get that momentum.

And I like that because, um, as much as we s speaking about technology, it seems like a very human story. Um, it, it's something we've seen forever. It's, um, it giving people the platform to showcase where they've, they've, uh, received results. And I especially like your encourage, reward, highlight. And if you fall short on either of these, you're probably not going to get the end result that you're hoping for. So it's very much what I'm hearing is do an evaluation of your culture, at least know your culture, understand what's going to be the driving forces, and probably you'll be able to already have an idea of the people that could drive this, uh, that are usually good at motivating the

other employees or the the rest of the company. And ensure that you get them on a platform where they are able to show and tell. And I think I like the idea of the smaller projects because what that means is the wins you make in each of those, tho those iterations, probably inform all of the other use cases. Because, um, even though it might be extremely different from C X to sales to lab work, whatever it may be, there are some universal truths.

Where if you learn within a company, this worked within this, um, specific use case, you could probably repurpose the win there in a certain way to gain faster. And that will, as as we spoke about earlier, that momentum is really what makes the difference.

That's right. And and maybe the the one other thing, whi which, um, I sort of touched upon it a little bit, but maybe a little bit more explicit. The world of technology for the last twenty five years has been sort of dominated by. I'm going to buy a piece of software and then I'm gonna get a professional services company to own the implementation. And I think what you need to look at as an organization is think about this almost like a, it's like a manufacturing project.

Is, I'm actually, I don't need someone to advise me and come up with, I need to build something. So you've got to also get into this mentality of do, don't talk about it. So I think you've got to also internally, externally. So involving the same cast of characters that you've worked with on I T projects for the last twenty years. Whilst there's always needing some level of technical expertise and some level of project management, I think you really want to encourage people to all be engineers.

Like, think about everyone being an engineer, cause what do engineers do? Whether it's a software engineer, they build things, yeah, they don't like spend 90% of their time staring, thinking, what? No, they build things. Philosophical. And I think that's the mentality, is get everyone to think as though they're, whether they're a software engineer, but that they're an engineer. Because it's about building things, not a program. And I think that's really what's different. So encourage people to think about building things rather than thinking about things too much because rapidly deploying.

Most people have a pretty good hypothesis at a conceptual level where it could work. Use either internal expertise or external expertise to validate. Okay, that's what you should build. But then encourage everyone to be involved in the building and get that building done fast. And I think that's what's really interesting about this, that the the value is super compelling versus the traditional large I T project.

A And this is actually quite interesting to me because, um, we've spoken about the skills gap. And when you see, um, when you see listings to fill those gaps, it's definitely a leaning towards. Do you have an engineer mindset? That's what I've seen is people asking, Okay, you can do this, but do you have that engineer? An engineering mindset, um, and that could be an upskilling within your company, even just figuring out what that means, uh, what is an engineering mindset?

And if you get them, if you get the company, it it is a bit of a paradigm shift. Because I do think that A I has been very, let's call it abstract in the sense that people have been thinking about it. How can we? How can we use A I? because we need to be using A I. I like this shift towards how can we build it, what are we building? Um, and that may mean that within your company you don't have that true engineering skills, but you can outsource that.

But just the engineering mindset will already get you quite a long way. A As we wrap up the episode, um, and this has been extremely practical, which I know the audience really appreciates. Because at the end of the day, as we just said, you don't wanna keep thinking about it, you want to actually take action and deploy. Are there any last thoughts that you'd like to leave the audience with, especially when it comes to those first steps?

Yeah, I think I sort of maybe restate a couple of things. Um, in my experience, both in my own company, actually with me personally as well, and encourage people to be curious as well. Because there's a there's, there's a thing that I've seen consistently over the last, you know, certainly over the last five to ten years. As as technology adoption becomes faster and faster, is that the more curious people will typically go faster. So, you know, encourage people to, you know, be curious, en encourage people that aren't necessarily the traditional people who involved in these discussions to actually be part of it.

And the more that you can encourage people that aren't necessarily curious to see the people that are curious, you'll actually see, you know, a little bit of a, you know, sort of a an effect where, wow, if I'm not like actively being curious around this stuff. So I think that's the the the thing is it really, it goes back to the fundamentals. This is a, I mean, you used the term paradigm shift. I don't. Whe whether I mean people understand paradigm shifts, but I think this is just a there are jobs that will be eliminated.

That's maybe one thing. But what we're seeing explicitly is that the value that these types of solution can drive at scale is creating significant increa net increases in expertise. Yes, it may be in different areas, and so I also think that's a key message, which is, I think a lot of the discussions I had in 2024 and 2025 with senior executives was, Hey, Lawrence, I've got twenty people, can we do it with ten?

And that's not the question.

Now what I say to people, Hey, you've got twenty people, maybe they can do the work of thirty people.

Exactly. And that's scale, right? N now now you're scaling.

Now you're, scale false multiply. We see this with clients, you know, I've got a client talking to on Friday where we've got a pretty large team deployed. It was like seventy odd people. And they're seeing massive productivity improvements over the last nine months. I mean, it's substantial. And they said, we want to do more because the productivity is not about. I now need, I need, I don't need seventy people, I need thirty. No, I see this productivity, I'm making people, I'm making the average person a superhuman, and that's a great productivity driver.

And also, I think it will ultimately mean that people that are motivated and curious will be very, very successful. People that are not motivated or less curious will be less successful. And I think that's a good signal for both employees and employers that you're going to build an organization that is ultimately over time going to leave behind people that aren't motivated or curious, and those that aren't aren't motivated and curious. Even though they may not be skilled in the same way, can really accelerate their productivity.

And I think that's what's really exciting.

And and that, um, that drives growth because it's it's cultivating a culture of ideas, rather than than than just sticking to. And I think enterprises do realize the the old way is gone. It's it's not a matter of can we, can we adapt our old way and just layer on the A I. You, you need to change what you're doing. Um, this has been extremely practical, as I said, I do enjoy it, and it's been very positive in the sense that we've we've spoken about force multipliers, we've spoken about momentum.

These are all very positive thoughts and grounding it in the idea that it's not a job loss situation. Do not consider this, because I do think that can stifle, uh, enthusiasm for A I within companies. And I really like the idea of thinking as engineers, as builders. It's moving and I, I know we've. I don't like the word pilots anymore, just as you said, it's, it's, it's been overused and it, it's maybe not. The problem might not be pilots, the problem may be, as you said, the investment.

It's investing in ideas rather than investing in something you can build and deploy. So making that shift within the company, making everybody think as builders, not as thinkers, and then ensuring that it's a multi-tiered top down, bottom up. And then I'm going to reiterate the encourage, reward and highlight cycle, um, which will encourage curious people to to come with solutions that are practical enough to deploy and get that cost to value. Thank you so much for your time.

Is no add, please.

Just one one final thing, when you talked about thinkers and doers, when you talked about thinkers, I think about thinkers and doers. You can now, you know, historically, you'd have a lot of thinkers around a project, project would run, and not many people would be doing the doing the work. Whereas I think now you need people that can think and do, can currently. And that's, again, it's. I think it's a huge opportunity, and I think it's a it's a mind shift, mind shift change for everyone.

And I think the future is good, but, you know, there's still a little bit of a change management to be done across the world.

Yes, that's the challenge, especially within big com, uh, big enterprises. It, it's historically taken longer, it takes longer to turn a big ship, a ship, uh, rather than a tugboat. But, um, I think scaling it down into those little iterations makes it a lot more practical than trying to steer the entire ship. Um, thank you so much for your time.

Appreciate it. Thank you.

Wrapping up today's episode, I think there are three key takeaways from our conversation with Lawrence. First, enterprises stall when they treat A I as isolated pilots rather than building the end to end sequences that create business impact. Second, momentum comes from small, real deployments with tight scopes and fast iteration cycles, not long planning horizons or theoretical proofs. And finally, organizations that integrate expertise, shorten cycle times, and adopt a builder's mindset are the ones that move from concept to meaningful results.

If you have an A I solution, position your brand alongside the Fortune 500 leaders defining the enterprise A I roadmap for the opportunity to showcase your solution to the executives currently funding and scaling global initiatives. Partner with Emerj, secure your partnership at go dot Emerj dot com slash partner. That's G o dot E M E R J dot com slash P A R T N E R. For further executive level analysis and to join our network of leaders delivering workflow impact with A I, visit Emerj dot com.

On behalf of the team at Emerj, we'll see you on the next episode.