Maximising AI Value: Jeremiah Mannings on Strategic Adoption and Long-Term Benefits

So if you're a— if you compare a mining company versus a bank, right, there's different types of domain knowledge you need there. Like you've got assets, supply chain, all kinds of different considerations from a bank.

There's a lot of—

from a miner, sorry. There's a lot of physical elements you need to consider. You work with different types of data systems. You're talking about different types of assets. Whereas a bank, you're talking much more digital assets for the most part, and you're more customer-focused. You have different kind of things that relate to the job that you're doing. If you move from one of those organizations to another, there's a learning curve. As a data person. Whilst the systems you're using are quite similar, that skill set's now easier to find. What is not easy to find is that, okay, what do we do with this information, right? We're in this, in this situation, we need to know what we can do and where we target and where we spend the money. And that's where you, you've got a greater ability now to get that kind of focus.

Jeremiah Mannings, welcome to The Mentor List.

Thank you.

And, uh, well, thanks for coming in today and really looking forward to the conversation. Um, so we're sort of talking about, you know, what are the various topics that we can talk about today relative to your experience. Obviously AI is, you know, the hot topic at the moment. But maybe we could sort of kick it off and just so the listeners sort of don't think, oh gosh, another AI podcast, not necessarily from us, but just in general, because it's hype and it's starting to get a little bit of resentment's not the right word, but it's starting to become a little bit like, okay, yep, you want to talk about AI again, right? Yeah, thank you.

Yeah.

So how are you finding, how are you finding that?

Yeah, look, it's a really good question and I think From my experience, look, I've been doing this for quite some time now through, uh, we used to call ourselves decision intelligence, then data science, and all these different terms that kind of come into play. AI at this point, it had a lot of, um, a lot of hype and a lot of, uh, kind of support behind it, particularly because you had large tech firms getting into it, you had all the publicity about it. But what it really is, is it's another suite of tools, right?

Yeah.

And it fits within the landscape of the suite of tools that we have. And when you look at that, you need to actually— I think we were speaking earlier at the value conversation, right? It's you want to use the right tool for the job. You don't use the tool because the tool is fun to use. And I think you've had a lot of people that have gone through and, um, you know, you've had boards jump on, you've had executives jump on and go, look at this new fancy thing that we're doing.

Yeah.

The problem is if you're not using the right tool for the job, what you're actually doing is spending more money to solve a problem that you could have solved in other ways.

Right. So you mentioned the magic P word, and maybe that's it. Maybe we're just looking at a solution to an undefined problem.

Yeah, correct.

Yeah. Is that—

it happens in hype cycles all the time, right? Blockchain's a great example.

Yeah.

Blockchain, whilst technically a good solution for some specific use cases.

Yeah.

Was not applicable to 50% of the projects that I saw about it, right? It was just put in there because it was the new interesting thing to do. And AI is no different. AI, it does have some incredible benefits with the right use cases and with the right understanding of the metrics and the payback and the outcomes, and also the cost, right? It goes without saying that AI is a high-cost tool compared to a lot of things that people use, right? Even if I compare to some of the more traditional data science platforms I've built, They are much less cost per, per access, per person using it, all these other things. The cost was a lot lower. So now you have to have a very strong value component in order to make that worthwhile.

Because I mean, it's, it's, it's, it blows me away that, I mean, Microsoft, the suite of Microsoft, which everybody— well, not everybody, but mostly everybody— well, it's almost a given that, you know, you start your first day, it's like, oh, where's my Microsoft account? If you're in a big enough business. And, you know, they're a corporate license somewhere about $50 and it's a sliding scale a month. And then AI comes along and it's $50 a month as well. And it's like, hang on.

Doubles the cost of it, right?

Yeah. So yeah, I mean, how is that being justified in business cases and clients that you're sort of working with and helping to maybe steer away or steer into these types of scenarios? Where does it How do you define value in, in that? Because that just seems like, oh, another subscription will just load up another $50. Now you need twice the value, but Microsoft obviously gives a lot of value. So I don't know if there's a question in there, Jeremiah, but I'm confused.

Yeah, well, I mean, you could, you could— there's a few different ways to think about this, right? I would say Copilot on top is not essential to any business, right? But it will make certain employees more productive, right? And the thing that I've seen organizations get wrong, particularly early adopters, is getting a vast majority of the organization onto these licenses. And not everybody's going to use it in every role, right? Particularly if you're an organization that has frontline staff, you have people whose primary role is not to sit behind a computer and create information, it's less valuable. If you've got staff that are, you know, authoring documents where they might be doing things differently each time and they need to create bespoke sorts of reports and those sorts of things, there's a lot of value in having these types of systems because it can help you collate research, it can help you put points points of view together. It could do things rapidly. But what I would say is you then need to be careful on how reliant your workforce becomes on those things. So for example, if you're putting a compliance report together, would you trust a generative AI system to collate all that information for a compliance report?

Yeah.

And the answer is probably partially, but you still need to check and confirm that information, the conclusions that comes to, are still valid and relevant for the use case that you're doing. So it can help the right employees. And that's probably the best way to think about the rollout. The problem is, is I say that like it's easy, but it's not, right?

Yeah.

Because most organizations don't have a good handle on the role descriptions that each person in the organization plays and who could actually benefit from it. So you're kind of playing this game of, okay, let's see who uses it, and then maybe we keep the licenses for the heavy users. But that's one way of doing it, but it doesn't necessarily get everybody on board because there's a lot of parts of the organization that may not be mature enough to understand how to use it, right?

Yep.

So you've got to do a bit of an education. You've got to do a bit of pre-work before you figure out which licenses to turn on where, particularly for Copilot, because it can have a great deal of impact to the right people.

Yep.

But it's locating those right people. And I think one of the things that I always talk about with these types of systems and data science more broadly is change management is probably the most important component because if you don't have that, you don't actually know where to target. You don't know where the right parts of the organization are to find that value. So there's a lot of steps you need to take before you do it. And you might find out that there's other solutions that may be more cost effective for a particular use case in those user groups as well.

Yeah, it's kind of, um, it just— this conversation is kind of like reminding me— I'm not reminding me, but it gives me a picture that— and it sort of links a few conversations I've had with different execs. It's like there's this push for AI, and I don't really see it coming from the CIO or the IT function in businesses. It might be an executive that's been in an external influence and now it's like, okay, we need to get this in and we'll trial it with 10. And obviously you're sort of giving some guidelines around, well, yes, the 10, but the 10 would need to be in certain types of roles doing certain types of things to get the benefit. It's almost like it's not born out of an issue or problem and then the concept is applied to address that issue or problem. Or is the issue and problem—

It's not a core operational issue, right? Yeah, so this is a, this is a really good point. I had an interesting discussion a few days ago with someone on this around ownership, right? Who should own these systems within an organization?

Good question.

And the CIO would— is the logical point that you'll go to. And if your organization's mature enough and you've got a CDO or a CTO, then potentially there's some options.

Who would own Word and Microsoft?

This is the thing. So the license would be owned by the CIO because it's a, it's a core system that you're using. It's operational for the business. But I would argue that something like a generative AI system isn't solely owned by a CDO. CDO is responsible for the data that probably feeds and contributes to that system. CTO is responsible for the architecture and the platform that enables the system. And then the CIO is responsible for the cost and the operation of the system. But the desire and the want for the system is not going to sit with either of those 3, right? Right. Unless they're looking at it just from a tool perspective, right? Because those 3 components of the organization aren't going to have the drive for it, right? It's just like if you look at a supply chain asset management system, that's not being driven out of IT, right? Most of the time that's been driven by a supply chain component or a finance component of an organization.

Yeah.

They will own the solution. The CIO and the IT team will build, create, run the solution, but the ownership will sit within the business. And AI is pretty similar for bespoke use cases. Yeah, so for example, there's a really interesting use case, um, and a couple startups in the area actually as well that just do responses to external bids. So like RFPs, those sorts of processes, they have a generative AI system that responds to those things on your behalf, learns your context, does what you need to do, helps respond. Now that would be set up, managed by IT from an operational perspective, but the person paying for that and paying for the license and paying for the benefit is coming out of the business.

Right.

It's gonna come from some function in the business that needs to respond to those sorts of things. So you need to kind of balance where the need fits as well as how the platform is operating. And that's when you're thinking about, it's like any technology procurement process, right? It's no different. AI is no different from that. The only difference is you need to have security. So if you've got a CISO, get them involved. You've got a CTO, get them involved to make sure that the platform you turn on doesn't, you know, Consume more information than you expect it to is the other thing that's happened. So we had a funny situation at a client where someone had installed one of those little meeting bots that take notes on your meeting, Read AI or something. Every meeting that they joined, it started joining as well.

Yes.

But then it started joining meetings where that person wasn't in, and then all of a sudden it's in half the meetings across the organization even when it hadn't been invited because people had gone between meetings and accidentally activated it. Potentially going to another It was a free solution, which means you're the product, right? So it's going somewhere else, and IT's got limited control over that because it's going through your personal computer.

Yeah.

And it's in meetings where you're talking about, you know, things that definitely should not be going external. You need to have a good handle on how those things are being accessed. And the one of the challenges with AI tooling is it's so easy to access now.

Yeah.

Right? You can bolt it onto a license, you can do free trials, you can do these other things that people can just install on their machines, or even install web apps. They don't even have to install it. applications, right?

Yeah.

So there's a lot you need to manage from the security perspective. But coming back to the ownership, that's the kind of things where the CIO is involved, is making sure that we are using it responsibly, the operation of it is managed and controlled, but it needs to be driven and potentially funded for particular solutions out of other parts of the business.

Yeah.

And otherwise you don't get the buy-in. Like, if you create a tool and you haven't thought about who's using the tool and why, nobody's going to use the tool. You can create the most technically advanced AI system that you want, but it's got to be usable for the business and solve a problem.

Yeah, you sort of mentioned, you know, other parts of the business of funding it and giving the driver and the want, which completely makes sense. Um, and you've mentioned about 5 different titles there, and just maybe we can tease them out a little bit. CISO, CTO, CDO, CIO. Um, talking about the evolution of different roles, you mentioned decision intelligence, data scientists, cyber Cyber's another—

Oh yeah, that's another component.

Yep. Putting in front. But it seems like the evolution of the IT function and the roles within it, um, is certainly changing. And where the CIO sits, or the CTO, CDO, is sort of starting to become a bit varied in terms of the hierarchy, but also what part of the business. So maybe just getting your view on a bit of maybe the evolution of it, because we used to just have a CIO that sat at the C-suite And they had an IT function.

Yep.

Um, they would potentially have an on-premise setup and they would hold positional power and location power. And now it's like, if I'm in the business, I can just go to a supplier and put my credit card in and like—

Yeah, the controls are a bit looser, right, than they used to be?

Yeah.

And I think that's because of the environments that we're consuming from as well, you know, with the advent of cloud, with these systems being distributed, it's easier to consume those sorts of things. Now what I'd say with the CIO is, uh, there's a few interesting components, right? And it depends on the maturity and the setup of your organization. So for example, if you have a business that can profit from data, you will have a CDO in the C-level, right? They will be a proper C-level title, they'll be reporting to the executive, they'll have a stake in that.

What is a business that can profit just in this?

So for example, if you've got information that you're selling back to your clients, you've got information that it's a competitive advantage for your business to have additional information over its peers, those sorts of things, you see a CDO title get elevated.

Right.

If that's not the case, they generally sit under CIOs for the most part. Sometimes they are sponsored by other parts of the business as well, and you see CDOs in kind of random locations, and they become more of a— less of a tech function and more of a governance function. So you've got the 2 elements of a CDO is they're either, they're either tech governance or both, but a lot of the times you see them split. So a chief data officer will have the governance functions sit underneath them, they'll have the policy, the compliance, they'll have those sorts of things that sit under the title, but then the people actually doing some of that work will sit under the CIO, right?

Got it.

So then the data engineers, the data scientists may not actually sit under the CDO, they'll sit in adjacent teams. Or they sit in business teams. So I'd say a lot of organizations that are larger that have data as a focus will have a CDO office in the center, right? And then they will have the actual people building the use cases sit within the business functions, so in the different divisions of the business. And then those people are working with the CDO to make sure the guidelines and the standards are kept in there.

Got it.

And it— that is unique to the CDO role because you start looking at CTO and CISO, they are broad functions. They— but they tend to sit in most places under or around the CIO because they are, you know, every system the CIO touches has a cyber, has a technology function, right?

Yeah.

And they need to be kind of, you know, in that, in that bounds. But you then do see some organizations that may deal with a lot of personal information, a lot of, you know, if they were to have a data leak, it would be a serious problem. They might have a CISO that's elevated as well, and the CISO may have a program of work. But once again, very similar to a CDO, where they'll run and govern a program, but they won't directly manage the people doing the work in that program. And it will usually sit under the CIO.

And sorry, Jeremiah, very basic question, but Chief Data Officer and CISO, Chief Information Security Officer? Correct, yes.

Sorry, sorry, should have started with that one.

But that Chief Information, so I imagine these are fairly, like if I'm a CDO at a bank, Yep. And I'm looking for my next role and I saw the title CISO, would I not identify with that? Or is there a fair bit of overlap depending? Like, sorry, it depends. So out of curiosity.

No, it's a good question because the, the way I consider the CDO title and the way I've heard it described is like a baby C-level, right? A lot of people use that as the stepping stone to CIO and then potentially other roles within the executive as well. What I haven't seen very often is going from CDO to CISO because the domain knowledge that you need between those 2 roles is quite different.

Okay.

Well, as a CDO, you need to consider the security of the information that you use, the data that you use, how it's being consumed. But a CISO has much more broad kind of considerations, and they need to be looking at the market. They need to be heavily involved in that field. So they're not too interchangeable. I have seen people interchangeable from CDO to CTO. because there is a lot of crossover between data and technology systems. But once again, those 3 titles tend to be the stepping stone to a CIO title. All right, thank you very much.

Sorry, I just wanted to click to clear that up. And then I guess, so what do you— we seem to go in these sort of waves where, um, you know, the centralization of resource decision-making, which, um, which we've kind of gone through, and then you end up with this factions within the business or shadow IT. Where are we on the spectrum at the moment? Have we just come off a big centralization or is it out there?

Starting to federate again, right? Okay. It comes between— you're going to see this cycle going back and forth between central and federated. And I think now we are— a lot of organizations that I'm working with are considering federated, right? And the reason for that is as particularly in the data space, as data tooling approaches, standards are becoming stronger. So the standards are there, the patterns are there to do the work. They are quite a bit stronger and it's commoditized now, right? You're not necessarily paying a data person 50% more as you were 5 or 6 years ago because they were hard to find in the Australian market. They're a bit more commoditized, a bit easier to get, and a bit higher— easier to get a high quality as well. So what that means is it's now easier for a less technical division within the organization to hire and get use out of data people, right? So if you've got specific things you want to build, the domain knowledge is also very important, right?

Right.

If you cast your mind back 10 years ago, it was such a niche skill set that the domain knowledge wasn't as important, right? Because the actual knowledge of how to set up and run these systems was more important than the domain knowledge because it was very Difficult to get both, right?

Right. So domain knowledge is in— if you're working like, what's an example of—

So if you're a— like, if you compare a mining company versus a bank, yep, right, there's different, different types of domain knowledge you need there. Like, you've got assets, supply chain, all kinds of different considerations from a bank. There's a lot of— from a miner, sorry, right? There's a lot of physical elements you need to consider. You work with different types of data systems. You're talking about different types of assets. Whereas a bank, you're talking much more digital assets for the most part, and you're more customer-focused. You have different kind of things that relate to the job that you're doing. If you move from one of those organizations to another, there's a learning curve as a data person.

Got it.

Whilst the systems you're using are quite similar, that skill set's now easier to find. What is not easy to find is that, okay, what do we do with this information, right? We're in this, in this situation, we need to know what we can do and where we target and where we spend the money. And that's where you've got a greater ability now to get that kind of focus.

So is that sort of happening across the board, the systems knowledge being less of a part of what goes into, well, the CDO role, for example? And is that driven by supplier support or, because I mean, we used to have everything on-premise, we'd have our experts wrapped around it. It'd be safe, and now it's gone to the cloud, which we'll come back to in the end and find out what that actually means because it's not in the air. Um, but the system's knowledge becoming less, less, um, and gosh, I don't even know what question I'm trying to ask.

But I get what you're saying though, like it's more accessible now, right? So if you've got a platform in the cloud, and let's say for example's sake you're on AWS, Yeah. And let's say you're looking at your cloud vendors and you go, there's something interesting in GCP, so Google's Cloud Platform, that I want to consume. It would take you no more than 10 to 15 minutes to set up a cloud connect between the two, and you could move information from one cloud to the other, and you could engage with an off-the-shelf system within GCP relatively quickly, assuming that, you know, you don't have to go through too many hoops to move that particular set of information.

Yeah.

But the actual ability to do it from a technical lens is there. There. And when you're in these cloud platforms, you then have access to the marketplaces that sit behind them, right? And you have access to the thousands and thousands of vendors that make solutions specific to those platforms. Whereas if you were on an on-premise platform, when you talk to a vendor, the first conversation is, what do we need to adapt our solution to your specific environment, right? Because it's hyper— it's specific to you because you've created it on your own premise with your own servers, with your own, you know, information. As you're now in the cloud, you've got access to a standard set of capabilities that are much easier to engage with. You know, if you want a CRM, you can bolt it on the side of something else. If you want a new database, you can just turn it on and move information into it. You don't have to go through the rigmarole that you used to do in order to set up and get these things running. And like, GenAI is another example of that. A lot of it is just bolt-ons to the side of existing capability. You don't need to set anything new up. There's no new server you need to to put in, anything like that. It's much easier to consume. And the good thing about that is it means you can try technology out, you can engage with the trials and things that these vendors run to get you on board, and you can start playing around with this technology in a safe environment to figure out what's actually going to work for you. The key point there is making sure you do play around with it, you compare the different vendors, and you do a fairly rigorous assessment.

Yeah.

Because these days the assessment of the vendors is probably more important because you've got so much information out there, you can— there's so many systems you can consume, you need to know what's going to work for you and you need to know what the cost profile looks like. Because one of the things that's changed now when you're talking about AI and you're talking about data science is people tend to, tend to neglect TCO. So your total cost of ownership, right? You look at it and go, okay, your first year is going to cost us X, but there's less consideration of, okay, well, what if this gets widely adopted across the business? Now it's going to cost— 10 times that? And where are we going to get the money for that? And where are we going to get the justification for that as well? The other consideration is with our existing assets, are we using those to their fullest potential before we shift across to these new assets, right? If you've built— and this is the trouble with technology moving so quickly— is sometimes the business cases for your prior stack of technology is invalidated by new things. And that can be tricky as a CIO when you're looking at this and going, well, I can't change my technology base every year, right? Because otherwise you're constantly asking for development funding and you're never getting to the point where you prove the value of the system. So you need to be— you need to start picking and choosing the things that you engage with and start looking at it over a larger time horizon.

Yeah, right. Gosh, it's actually quite stressful being a CIO. You're like, what's the new—

what's the new thing this week? Yes, from what I've heard from CIOs I've worked with, it's not an easy role.

No. And you mentioned cost profile, and yeah, obviously total cost of ownership you know, has to come in it, but it sounds like that's probably not the leading, maybe it needs to fit in an annual budget or something, and then there's a bit of bill shock down the line potentially.

Mm-hmm.

We mentioned sort of moving to the cloud, which is probably, it'd be interesting from your perspective to hear about, you know, where are we in that sort of, you know, broadly speaking, where are we in that? And what are some of the, Focuses now that, you know, people are potentially in the cloud and there's adoption or not adopt— things not being adopted. Where are you seeing, um, you know, clients and businesses at in their stage of journey? What are some of the focus areas?

Most are on the cloud in either full or some capacity, okay, what we see. And one of the very common things is you may have some, uh, some parts of your technology stack that don't have equivalent cloud solutions, so they're hard to migrate. Right. An example of that would be Teradata. That's hard to migrate to a lot of cloud platforms.

That's widely adopted.

Yeah, it's a widely adopted platform. And whilst there are solutions to do it, it's not as easy as lifting and shifting, right? So sometimes I've seen organizations make the decision and go, okay, we're going to use this until its lifecycle is over, but we're not making changes and we're not adapting it. So you have change locks on your on-premise systems, right? So you've already paid for the servers. In most cases, you've already paid for the infrastructure. It is functioning and providing value. There's not much harm in continuing to do that. It's just where you put your development effort, and your development effort is pretty much universally happening in the cloud at this point, unless the organization hasn't moved there. But the majority have.

Yeah.

And even then, you've still got some systems that are simply not supported by the vendors anymore, and the migration between the, the system they have and the one on the cloud is a whole project in and of itself.

Right.

So then you've got a lot of people going, okay, well, is it worth us staying with this vendor because it's going to cost us the same as rebuilding with any other vendor. Yeah, let's do a vendor assessment as we move across. So you see a lot of the cloud transformations, that's kind of the basis of the thought, right? It's not necessarily as easy as moving it in there, and it's not supported anymore.

Yeah.

But for saying that, most people have made that move and they've gone through a lot of those changes now, and you see future development is primarily on the cloud platforms. Now, the interesting thing I've heard about this is it costs Small, right? Because being on the cloud, being on the cloud, because you need very tight cost control over a lot of the things that you're using. And when you're using dynamic and serverless compute, so basically you've got instances on the cloud where they can scale by themselves. It's like adding an extra, an extra mainframe on whenever it needs it and taking it off, right?

Yep.

If you don't have good controls on that, and let's say some people in your user base all jump on at the one time, A system may add 3 mainframes on in order to deal with that demand in a 2 or 3-minute window.

Yeah.

And then it takes an hour to turn them off just in case there's the demand, right? So depending on how your cost optimization thing works, then you have— you're paying for those 3 in parallel whilst you actually might not be utilizing them because you've kicked into those hyperscaling things. So there's a lot of cost control that needs to be put on cloud platforms to avoid that because when you have an on-premise system, you physically only have 1 mainframe. Right.

Yeah.

It doesn't hyperscale upwards because it can't. It's not how it works, right? So then you have service impacts to your users. So those 2 or 3 users doing something heavy may actually have a service impact, but overall that is minimal compared to the cost of scaling up. So you have to make those decisions when you're on the cloud as well, because most things that you engage with and most vendors you talk to by default will have scale built into their applications. It's why you go— it's why you go to SaaS applications. It's why you do these sorts of things. But you need to have a conversation around when those use cases for scale are useful and when they're not.

Well, is it a dumb— you mentioned Teradata, which— so if you had something in Teradata and they're not providing a cloud solution—

They do provide a cloud solution, but it's not that they don't provide it. It's that people have been using Teradata so long that they don't really know what's in their Teradata systems. solution.

Yeah.

So you may have dozens and dozens of models that were built by somebody 10 years ago and could be being used, but you don't actually understand why they're there or how they're there. And potentially they might have a very important report that goes to the board quarterly that you don't know how to rebuild that model, right? And if you can't pick that model up, move it to the cloud, and you've got to think about that model again, that's a whole new project, right? In order to pick apart those pieces, understand why this model is how it is.

Yeah.

And then migrate it across. Because if you pick everything up that's on your on-premise thing, put it on the cloud, it'll be expensive, right?

Because the whole idea about on-prem was trying to get everything in. So I guess your unit cost of running potentially a separate location.

Yep.

But then if you've got one, you know, one computer or whatever it is running Teradata, then you can't shut down that location. So you're sort of paying for the off-prem anyway, which is potentially fully depreciated in some ways. And then you're bringing, I guess, cloud usage directly into your P&L on a monthly basis, which varies now. So it's—

And there'll be a lot of crossover between the two as you're doing the transformation.

Yeah.

And you'll be paying for both. And then the other question is, as you said, your depreciation schedule on your physical asset has completed. Are you sweating that asset to its full value if you move off it?

Yes.

And the answer is, in some ways, it's— it does make a lot of sense to move off it because you're planning for the future, whereas these assets that you may have purchased 10+ years ago are no longer adequate for the workforce that you have, and scaling them up would be— it's not worthwhile. You may as well move to the cloud and use dynamic scaling there. So there are a lot of arguments for and against, but at the same time, it's still It's worth making sure that you are using those assets appropriately.

Yeah, yeah.

Or repurposing them as well.

Yeah.

Potentially there are components that can run on-prem that have good, you know, back and forth with cloud. Can you repurpose that asset to do something else?

Yep, yep.

'Cause they're not worth much to sell is the problem.

Well, it's, yeah, I mean, but it's like, yeah, I mean, just from a business operation perspective, you sort of, you've had these big, I guess, balance sheet, IT transformation programs that have left technology that's now, we're moving away from. So it's becoming more expensive to run whatever's left on there. Well, I imagine there's some decommissioning, but, and then we're moving to a cloud model. And maybe, maybe if you could just help understand what moving to the cloud actually is.

Cloud is just somebody else's server. Right. So it's still physically the same thing, it's just an obfuscation layer that sits on top. So instead of you having to control the bare metal, you don't have to do that anymore.

Got it.

So you don't— depending on how you want to manage it, you can still manage in terms of how many CPUs, how much hard drive space, all of that. You can still do all of that. But if you're using like more dynamic clustering, you can— all of that is taken care of. The actual usage of that is taken care of. So you're moving from— there's less controls you need in terms of that, like day-to-day maintenance of how things are allocated.

Yeah.

But you, you start to shift your thinking to cost management, right, when you go to the cloud. So when you're moving things up there, a lot of the systems are one for one. If you have a Microsoft SQL database on-premise, there are many equivalent things on the cloud. I mean, you can even just use Microsoft's if you want. It's exactly the same thing, works the same way. You move everything up, but then you'll have the integration is different. So these cloud platforms tend to manage the integration between their apps, whereas you have to build that on-prem. And what I mean by that is, let's say you've got a dashboarding system and a database. Super simple, right? The dashboarding system has to communicate with the database to then put that information on the dashboard. So you've got a back and forth communication. When you're doing that on-premise, you would have to set up what's called a connector. You would have to configure that to go, okay, this server is here, this is the URL of the server, this database is here, this is the URL, this is the login, this is how you talk to each other.

And then do the testing and the—

And do the testing, make sure it works, and then put a big load on it, make sure the load works, all of that sort of thing. So you've got a lot more to set up in that instance.

Yeah.

You know, under Microsoft, you put something in Azure Storage and then you log into Power BI, and then assuming you've got the access privileges to see it, you'll see it.

Right, right.

All of that's taken care of, the communication between things. Correct. It's in your own, what's called your virtual private cloud, your VPC. It all sits in there, it's all secured. You'd want— you log in once through your SSO, your single sign-on, same as you log into Microsoft 365. And then you inherit the privileges. So you start managing things like privileges because beforehand you would have the person logging into the dashboarding software would have privileges for the dashboarding software and you have to consider what your role-based access is there. And then your next system, the next thing, the next thing, the next thing you have. There's a lot of things you've got to manage, whereas here it's more centralized. So you have one policy attached to one person. That policy dictates what they can see and what they can't see.

So really, I mean, if you, if you swap dashboard with AI, yeah, for example, that's what's made this new hype and sexy product possible, really.

Well, once again, you used Microsoft as an example. If you wanted to use any of their components in the AI space and you've already got information in Azure Cloud, you just point it to that information and go, I want you to consume this.

Right.

And then you can build and train and spec things off of that through a UI. You don't even have to do anything technical if you want to start at the base level, right? You can train something specific to your organization just by pointing it to a SharePoint.

Yeah, right.

Whereas if you were doing that on-premise before, there is no just pointing to a SharePoint. You would have to set all those things up, you would have to do all of that, you would have to create those connections, you would have to do all that integration work. Whereas all of that's taken care of now. So the barriers to entry are a lot lower, but also the importance of an information security officer, a CDO, and these types of roles is actually takes a step up. Because now one of the things that I see is you've got— you'll see in a lot of organizations there'll be one SharePoint or some shared drive somewhere that's just got everything in it.

Yes.

Right, people have just dumped everything in. It's just the catch-all of, that probably shouldn't be on my computer, we'll put it here, right? None of that information is generally classified. And classified is very simple: internal, external, secured, right? You shouldn't share this with anyone, it's okay to share with anyone, or it should only be internal. If you haven't got that classification on your information and you point an AI system at it, it will consume everything by default, right?

Right.

Unless you tell it, don't consume classified information, don't consume this, don't consume this. And, you know, as humans, we have no idea what's in these folders anyway, right? So the AI is going to pick those things out and it's going to— I had one very funny use case which I won't name who it happened to, but they pointed it— they did exactly that. They wanted a generative AI system to help with kind of just everything around the business. So, you know, all the policy documents, how to use systems, all of that. So they pointed it to one big SharePoint that had all that information in it.

Yep.

Someone had copied information into that SharePoint that they shouldn't have, and they hadn't tagged it as classified. And in that information had people's salary information.

Right.

So now you could ask this AI system that was trained what somebody's salary was.

Yes.

Which luckily we found this in testing before it went to anybody else, but still a funny example, right?

Oh God. Okay.

So depending on what you do, then you have, you have to be very careful around what you're feeding these things because it will, it'll be, it has the ability to surface most things that it's seen, right? Unless you have very strict controls on, um, the types of information it's allowed to share, which is what's happening now. So that kind of AI trust side of things is getting better and better. around limiting what LLMs can actually produce as information and governing what they can produce. Because early on we got funny examples like that, right?

Yeah.

And I even had one system once, someone had loaded in just an Excel sheet they found on the internet of funny jokes, right? So that if you asked it to tell a joke, it would tell a joke, right?

Great.

Makes sense. Logical. Executive asked it to tell a joke and it told a very inappropriate joke, one that we had not seen in the training set and was like, oh, this is a nightmare. Yeah, and then we spent that night just going through absolutely everything to kind of pull out all the inappropriate jokes and make sure that it was appropriate, because the system itself has no idea of what's appropriate or inappropriate in terms of the information that's surfacing. It's up to you to make sure that it's limited to what it's supposed to be limited to. Yeah, and that takes strong information governance and strong kind of ability and control of information, which we're typically— no organization is good at, right?

So even to the individual, you've mentioned human behavior a couple of times, and the classification, like, um, having that discipline to classify a document or an email or whatever it is.

And it's a huge thing to do, right? Like, do you classify your emails? Because I don't classify mine. So it's, it's things like that. And then let's say you, you bolted on an email assistant and it's got access to everything in your email, and then it writes an email for you and you don't QA it correctly. There's potentially things you don't want in that email.

Yeah, right.

Those sorts of things need to be considered as well.

Absolutely. So there's a big human behavior component. I imagine this is part of—

Biggest part of everything that I do.

Yeah. So maybe we could dig into that a little bit. And you mentioned sort of cloud cost management, which is the result of human behavior, whether it's non-informed or however that's sort of eventuating. But yeah, what are you sort of seeing in maybe some of the new, later projects that you're working in? What, what is the sort of secret sauce to change management and helping people understand and leverage this technology and to basically get the value out of it?

Yeah, look, like anything, any technology, it's about communication and understanding the impact. So when you're implementing these systems, you, you obviously get some pushback on, I don't want my job to be replaced, all these sorts of other things. But you need to be very clear around how the system you're producing or the the information that you're, you're coming out of this is actually impacting that person, right? So you'll see a lot of solutions developed in a vacuum. So they'll be developed by 2 or 3 steps from the executive for a frontline staff member, right?

Yep.

But rarely do they get the frontline staff member involved in the conversations around how this would impact them. They're usually told at the end, right? Right. So if you're doing change management well, you've got them involved throughout. Consulted throughout. They understand the impact, they understand the things that we're thinking on what we've chosen, and then how it actually— you don't need everybody, you just need representatives from the user groups that you're targeting to help understand how these things work. So what you need to do is you go, we're augmenting your role, we're helping you perform better, we're not aiming to replace. But what you might do is you may replace components of a role, and when you're replacing components, you have to do something else with that time. Otherwise people get nervous, right? So a good example is if you're a salesperson, what do you do as a salesperson? Step 1, 9 AM in the morning, you log into your CRM, right? Then you catalog all the information that you're— the phone calls you have, the emails you send, everything that's going on. So for one use case that we did, we replaced all of that. You don't have to do any of that anymore. We go through your email, we figure out when you're talking to a client through the CRM, put that on there, we match it all together. You don't have to do any of that manual things.

Yeah.

You know, your phone's connected to it, you make a phone call, we log it in the thing, right? You don't have to do any of that. So that's 30% of the role, right? And it's admin, it's paperwork, but now you've got 30 extra percent of your role to do something with. So if we just said now 30% of your role's automated and said nothing else, it's not an effective way to get that person on board with now what do I spend the time on. So you have to work with those user groups to go, okay, now that you've got 30% more time, you know, the honest answer is your target is probably now higher, right? Because you've got 30% more time to hit that target, and this is what we're expecting of you to do with this program.

Yeah.

Whereas if I just said everything's the same, you've got 30% more time, it makes people nervous, right? Well, you've got to be very clear on your expectations, and if their performance targets are changing, you've got to say that up front. You've got to make sure that you're giving them examples of what to do with the time. So for example, if you're working with Um, if you're working with a nurse and you're helping them understand their patients quicker— so for example, they come to a patient, instead of having to flick through 20 different documents, now they've got a generated summary of exactly what's going on and everything that's happening.

Yeah.

What you're now expecting is potentially your patient— the time that you're seeing each individual patient to, to change, right? Maybe they spend more time on making the patient feel comfortable, making sure to get to know them. The social element, right, might increase, whereas Now you're not standing there reading documents, you've got 5 more minutes per patient to do that.

Yeah.

But you have to give that information up front. You can't assume that people will know it because otherwise they might go, oh, maybe I should spend 5 less minutes with the patient and get more patients in. Whereas that might not be your intended outcome, right? Your intended outcome might be the patient experience. So you need to be very specific with, okay, our intended replacement of this time is the patient experience. This is how you should spend the time that you've got back. And that applies to almost every use case you do these things with.

Yeah.

You need to be very specific around what you're doing with that time. And call center work as well, right? Call center has a huge impact from AI because your, your level 1 and 2 is quite easy to replace. The, hey, I need to change my password, usually has the same answer every time, and systems now can handle that, right? Whereas before it was very clunky, difficult to talk with, it didn't really make much impact on productivity. But now we're at a point where it does, and it does impact that productivity. So now you've got L1, L2, L3 support staff, and what are they supposed to do with the time? Well, beforehand, if you're L1 or L2, you would have, you know, an expected amount of time to solve a problem on a call. Now that problem-solving time may go up because you're only dealing with the tricky things that the AI systems can't deal with. So you need to go, okay, well, now our expected time is not 5 minutes a call, it's 20, and we expect you to deal with more complicated problems that are outside of these problem sets.

Yeah.

And it's okay if you spend that additional time because it impacts our customer service and improves those metrics. So you have to be very specific around where you want those things to go and articulate that before you even start building in most cases.

And sort of those few end-user examples, how are you sort of, um, how are you seeing things evolve from an enterprise solution perspective around, you know, we used to build in-house capability and systems which would support whatever the process was that we'd created. Now, if we're in the cloud and where you mentioned CRM, the sales module, for example, they would have a process and system. And if it's a new CRM coming in, how are you seeing, are we adapting processes to fit a unified sales process? As an example, or logistics, whatever the operation is within a business, are we moving towards a unified global standard of things, or are software and enterprise systems sort of building flexibility in these cloud solutions so you can create customization? Or is that just a—

99% of it is configured.

Configured.

Okay, so you've given a base toolset and you configure with that toolset. I mean, if everything was a universal standard, consultants I'm going to be out of a job effectively, right? So what you're coming in and doing is, you know, the setup of it, of a platform, may be relatively straightforward, but the configuring is very dynamic for that organization, right? So, you know, an example, if you're putting in a product category hierarchy, it's going to be very different at different places.

Yeah.

Because they treat products differently, they have different, you know, hierarchies of location, they have all kinds of different things that you need to configure, but your base platform is the same. You're similar thing to your competitors, right? Now when you start talking about the first part of that question, which is COTS, which is off-the-shelf procurement, first building it yourself, that becomes more interesting. So with tool sets now and the availability of, of products, it's much easier to purchase off the shelf because it's— the emphasis is on the product to be able to integrate into your environment, right? Because your environment is you have standard tooling and you're in a cloud and the integration is there. Yeah, it's up to the product to then fit in. So very rarely are you paying a product to adapt themselves to you anymore, whereas a couple years ago that might have been the case. You go, okay, we want to use you guys, but our environment looks like this, your product looks like this, we need to build something in the middle. Yeah, now you don't really need to do that. It's up to the product to do that. They should be plugging into your environment and consuming from your environment, meeting you where you are, not the other way around.

And does, does this create— and I'll give you the example that happened in my household— I ended up For some reason with Netflix, Disney, uh, Binge.

Yeah, classic conundrum, that one.

Yeah, then I had to go through this process to say, how did all these subscriptions sneak in? And then I went through this process of, you know, culling it basically. And it's a continual process, um, that, you know, versus 10 years ago where I had maybe Foxtel. I had one thing and it was— I paid it.

Because you had a physical box for Foxtel. Yes, a very good example, right? It actually relates very directly. So because you had it, it's a physical reminder. It needs to be plugged into the wall. You need to maintain that working. You have a remote to use it, for example. All these little things, uh, make it very easy to manage, right? Because if you wanted to get another Foxtel service, well, now you go, you put it in, you go, okay, I've already got one. Am I going to put it on top of the other box or am I just going to use this one, right?

Yeah.

So you have that consideration, whereas now because it's much easier to integrate. All you've got to do is put your credit card in, you've got a new streaming service, right? And you never see it unless you engage with it. And SaaS products are the same. If you never logged into it, you've never engaged with it, it's never going to be front of mind, you've never considered it. So now you've got things where organizations— I've seen a lot of them now going through and doing assessments. Okay, what products do we have? What's being used where? What's being used by business? How much is it costing us? What's the the risk involved with it as well, very importantly.

Yeah.

And then can we migrate off it? Can we, you know, merge it into something else? Do we need all of these different things?

Yeah.

Because the risk with SaaS platforms is also quite high, um, because you're usually giving some component of your information to an external party who is doing hopefully exactly what they said with it on the box most of the time. But you open yourselves up to cyber risks, right? What if they get hacked, right? What if you get hacked and then it affects them as well, right? You've got all these other different considerations, so the risk profile goes up.

Yeah.

And you have to make sure that it's worth engaging with that particular software to make it happen. But back to your first point on creating bespoke software as well, you see the organizations that are leading in their industries tend to be the ones that are doing more of the bespoke work, right? Because they go, we have this asset, we can see where it's going to add value, there's nothing off the shelf just yet that our competitors are using that really hits that mark. Yep, let's build something and let's— or the other option is we see an early-stage startup doing it, let's just buy them and continue to build their product to give us an advantage, right? So it's really the advantage play where you start building bespoke software, because I would argue for your core use cases, for your, your asset management, your CRMs, your HR systems, there's not much point going bespoke in today's day and age. You're much better buying off the shelf, because when you buy off the shelf, you're also buying skills in the market.

True. Yes.

So if you get a bespoke thing and you get a person, a 10-person team to build it, what happens if that 10-person team leaves 2 years later?

Yeah.

How do you maintain that? And the answer is it's expensive to maintain because people have to retrain. Whereas if you get a, um, a known CRM, a known ERP, you can get people at a known cost to maintain and improve, and it makes it much easier to maintain through its lifecycle. Yeah.

Wow. Okay. Fantastic conversation here, Jeremiah. And yeah, sorry if I'm digging in all sorts of different directions. No, it's always good. I'm just very curious. I guess, you know, on your walk in here today, was there any questions you thought, oh Dave, you gotta ask me about this because I've got a view on this or any sort of closing comment or remark where you think actually this is probably my advice or I guess it's your chance to answer your own question, Jeremiah.

Um, look, I think one of the things that I spend a lot of time thinking about and talking with people about is how to speak to your executive about all of these advanced technologies.

Got it.

And I think it really comes down to the value conversation again. And I know I've said value about a dozen times thus far, but it really is important, right? Can you think about ahead of time exactly what impact you're having, what impact that has business, how much that's going to cost, and can you justify it. And if you can do those things, you can usually come up with some industry-leading use cases that will help in a lot of different ways for your organization. You just need to be able to have that conversation, and you also need to be able to understand what's important to the organization, because different organizations have much different views of data, views of information, views of reporting. I mean, sometimes people don't even trust their reporting systems. So if they're not trusting their reporting systems, it it may be difficult for you to tell this AI-generated report is trustworthy because you've inherently got a lack of trust. So can you build something that helps improve the trust here, right? Maybe there's parts that you can start on to build along that journey, but it's really taking a broad view of where you sit and how you can build that value that is important. And it's worth a discussion up front.

Yeah.

And it's more than just a business case, right? It's not this cost of X, we expect this to happen. It's, you know, we've sat with the users, we understand exactly the impact. This will be what the new role looks like, and this will be the 1, 2, 3-year outcomes for that position, right? Those kind of conversations go a long way.

Yeah, much deeper than ROI, cost.

And ROI is— it's a made-up metric in a lot of times, right? It's an estimation, right? The more detail you can get in that estimation, the better. And if you look at companies that are doing AI well, that's what they've done well. They haven't even done ROI. They're not going it's going to cost us $400,000, we're going to get $600,000 worth of value. Generally, it's not the best way to think about AI capabilities if you're thinking purely in terms of financial ROI. Usually it's, it's going to cost us $500K, it's going to have X percentage increase on this customer service component, it's going to have X percentage increase on productivity for this specific role, and then it's going to have, you know, a decrease in headcount in this particular division by X Right? And all those things together have an impact on your outcomes for your flow-on divisions. But the actual system itself has no economic return. It is a cost, right?

Yeah.

It is a line item on your P&L.

It's a cost.

But when you look at the impact flow onto your organization, that customer service increase could result in more sales, that productivity increase could result in more outcome, that reducing headcount results in a more efficient division, and then a better percentage outcome from their ROI, right? Those things are flow-on effects that may be difficult to actually put on your P&L but have big impact on the organization. And that's where you need executive alignment to go, we're doing something here to impact these 5 things down here. And you have to bring that up and tell that story. If you don't tell that story, they'll just go, you've spent $500K and it has produced $0, right?

Yeah.

So you need to have a very broad story. You need a lot of people aligned to tell that. So it's not easy, and I'm not going to pretend it's easy, but That's where the value is for these sorts of things.

I imagine it was a similar sort of dynamic with moving to the cloud, which you're effectively moving to a more expensive way of operating, which would be hard to—

Initially it was cheaper because it was— the cost has increased over time, but usage has increased over time, right? Yes. The difference is cloud scales with usage, whereas your on-prem systems are set, so they never scale. They just impact the service that you provided.

Well, that's an interesting one around usage. And I'll give you a very simple example, and the one that frustrates me. I have Google Mail on my phone. I'll receive an email, maybe it's an EDM, and I'll want to delete it. But for me to delete it, I've got to click 3 buttons, or I can just click archive.

Yeah, so now you've kept it and it sits on the system and you're using more of it.

Yeah, that's right.

Yeah, well, because users expect more nowadays too. They expect available information. If you click a button, You don't want to be waiting for that button to do something.

Yes.

Whereas 10 years ago, click something, wait a bit, is probably more acceptable, right? Yeah, exactly. Wait for this thing to process, uh, to be done in 5 minutes, no worries, I'll go and chat, right? But now it's click, need it now, need it done. So your systems need to scale to facilitate that as well. So the user experience keeps changing and adapting, and user experience is not something that is— it's, it's more considered, and day in, day out it gets more and more considered, but there's all kinds of elements of it that need to be thought about as an executive. You need to think about your customer, your user, your employees, uh, your— even your suppliers. Your suppliers using your systems, are they— do they dread logging on to your procurement portal all the time? Because I can tell you, having logged on to many procurement portals, most of them are dreadful, right? Is there an experience element there you can improve to make sure you're getting the best out of your suppliers? Those sorts of things, right? There's— and that, from a technical function perspective, works fine, but it may not actually be fitting what you need as an organization. So they become your competitive advantages, and that's the human element, right? That's people want to work with us because our systems help them work with us, right? And all of a sudden you start taking a slightly more market position because you're more— you're easier to work with, you're easier to engage with, your processes make more sense, they're more adapted to how people work.

Yeah, yeah. And just following up on sort of, you know, how to speak to your exec team about a, um, maybe a tech-flavored investment or concept, um, you mentioned sort of, you know, it's more than just the ROI. What are some of the other, um, you know, elements that you can draw on to communicate value?

Yeah, so we are blessed in this day and age that it is easier to explain because you can play with it now, right? So 10 years ago, when I'm explaining the value of a data science platform, very theoretical, right? I've put a picture up on the wall and I'm going, you know, this is valuable. I'm kind of just telling you that it's valuable. You don't really see the benefit of it. Whereas the executive now is a lot more educated on technology, and they have a— they've played with AI systems, they've played with ERPs, they know what these things do, they know how they function in general. And you can use their knowledge to kind of explain how this would fit in with what they know existing, right? So it is much easier to explain those things now. If you look at like— so I'm part of the AICD, for example, They do a lot of uplift on technology, cyber, and all these other risks you need to consider. So now you find you're sitting with the directors and they're asking really good questions, right? They're asking really pointed questions around, have you considered this? Have you thought about this? What's the impact? What's the risk here? And you need to have prepared for those things, provide adequate examples, and really break it down to something they understand. Like, most people have smart technology in their homes. They're starting to understand broadly how data is connected. know, if your fridge has your emails on it, then it's an example of a random asset being connected. You could do the same thing about a truck in a mine, right? Like, it's connected in the same way. It has processes on the edge. Just like your fridge can figure out when you're out of milk, the truck can figure out when it's out of fuel, right? And you can start making things more real because technology is more connected in our homes.

Yeah.

So it's just telling that story. Becoming a, becoming a storyteller is a very important thing in the technology space, and you see a lot of the the most successful executives are able to tell those stories and build that kind of, that prop, that value prop.

Right. Okay, thank you for, uh, for sharing, Jeremiah. So we're going to move now into a couple of short answer questions. Um, yeah, so just, um, any favorite quote or, um, reference that you, uh, refer back to in—

It's a good one.

Found useful.

My favorite quote is probably slow is fast, and it was said to me by, I can't even remember who, But when I was learning to drive on a racetrack, right? So, um, one of my hobbies is building cars, racing cars, breaking them and fixing them again, and in that order.

It's a cycle, right? It's a cycle.

It's a never-ending cycle that cost me a lot of money. But when I was learning that, um, you know, this guy I was, I was driving with told me slow is fast, right? When you're coming into a corner, if you're coming through the corner and it's aggressive and you're turning in, the wheels are squealing too much, you're going a little bit sideways, All of that feels fast, but it's not actually good for the time it takes you to get through the corner.

Mm-hmm.

And that quote for me now gets applied to a lot of things in my life where, you know, if I'm preparing, um, you know, a value prop, even to use a relevant example, if I rush through it and I put the first thing that comes into mind, I do it quickly and it, you know, it looks good because I've only read it briefly, put it in front of someone, it's not actually the best result I can do. Whereas I step through, I take the time to understand the user, I understand the technology systems behind it. The coming together at the end might actually be quite fast because I've taken all of the steps to get those things together. And the end result is you get to the goal that you want quicker, even though you've kind of slowly taken all these steps. So it's just, yeah, a bit of a guiding principle, I suppose.

Like you're building on each step instead of going back and reworking it or proofing it.

It's exactly the same way you build an architecture, right? So I've been trained in enterprise architecture quite beaten into me over the years. But you kind of— you spend 2 weeks talking about it, and then in half an hour on a Friday afternoon, you go, I've got it. Bang, straight on paper, there's your architecture, right?

Right.

Because you just need all the pieces in line to get it in your head, to visualize it, to make sense of it, and put it down, right? Whereas if I just started— if I'd rushed day one, put an architecture together, and then I just spent 2 weeks validating the crappy architecture I put together at the start, you would not get to the same location, right? Even in the same amount of time, even though it feels like you've produced something quicker. Right.

Yeah, interesting. Oh, great quote. Thank you for sharing. And more importantly, thanks for the context.

I don't think that was a quick answer, unfortunately, but yeah.

Well, slow is fast.

There you go.

But we didn't have to go back and I didn't have to ask you more questions about it. So there you go. It's validating the concept. Yeah. So favorite book or maybe reference that helped you sort of, you know, pick up all your knowledge in this space or something that you think Might be relevant for people to read.

Maybe not specifically in the space that I'm in, but Thinking Fast and Slow by Daniel Kahneman is a very popular book, and for good reason. Um, basically helped me understand how my own brain works and how I could apply that to the work that I was doing. Yeah, so that was a very, very interesting book.

Very informative. I'm picking up on a theme here. Yeah, and even in the conversation, um, like, uh, the ability to get, um, complex scenarios out Quickly. It's like, I mean, I feel like I've had a lot of knowledge passed to me in this conversation here. So fantastic. Uh, who was the author on that one? Thinking Fast and Slow?

Daniel Kahneman. I'm not sure I'm saying that correctly.

No, good. We'll, uh, we'll put a link to that up on the website. Thank you for sharing that. Um, and this would be interesting, uh, what advice would you give your younger self?

Uh, kind of related to my last answer actually. So when I read that book, I started to realize how I was missing a lot of what I was doing. So when I first started my career, I was the kind of guy you would lock in a dark room with a laptop, right? Build me this thing, go have fun, never talk to anyone. To the point where, um, I sent some emails when I first started my career that I wasn't allowed to send emails by myself anymore after a couple of those emails. I had to tag my boss on every single email so that I didn't offend anyone we were working with. So for me, there was a lot of learning there, right? I had to learn how to, you know, come out of my shell, be social, how to tell my story as well was important. And I think that was the biggest thing that I wish I'd done sooner, um, because it goes a long way in everyday life, right? Yeah, the ability to just chat with someone you don't know, learn something about them, have a conversation, goes a long way and it impacts everything you want to do.

So are you naturally extroverted or introverted? Would you label yourself anyway, or I would like—

for most of my life I was quite introverted, and I think I came into that extroverted, and now I'm very comfortable in that extroverted thing.

So, but is that your natural self? So if you're at a social function now and you're very active and you're engaging with people—

Oh yeah, I'll talk to everybody I can.

Yeah, but when you get home, are you exhausted? No, not really. Okay.

Yeah, I think you've got to get used to it. Yeah, um, you can adapt to the— like, the brain is infinitely adaptable, right? That's the whole point of having it. So Um, yeah, that's kind of how I've gotten— because I used to be like that, used to come out and, you know, it was an effort to talk to people. But once you start actually thinking about, okay, I want to talk to people because people are interesting, I can learn something, I can help them learn something, you know, I might get a recommendation I wouldn't have gotten before.

Yeah.

Um, like, uh, I spent a couple months in Europe last year and I didn't plan a single part of that. The only way I planned is you'd land in a country, you'd talk to a bunch of people, do all the things they recommend, and it ended up being a really interesting trip, right?

Yeah.

And then, you know, all of a sudden you've made a dozen different friends and you're in countries you were never expecting to be in and all kinds of different things. So there's that kind of, um, it opens up a lot of opportunities if you are that way.

Yeah, awesome. Sounds great. Um, planning and arriving and working out where you're sleeping that night.

Yeah, that sounds fantastic. Yes, I've only slept on a bench once or twice. It usually worked out most of the time.

Oh, thank you, Jeremiah. Um, so now we're going to move into, uh, what is 60 seconds of me firing as many questions as I possibly can.

Yeah.

I'm just gonna get my timer here, which I couldn't get working in my last podcast. Here we go. All right, we're all working. Okay, you ready to go?

Mm-hmm.

All right. Gen AI or traditional data analytics?

Oh, traditional data analytics.

AI-powered chef or automated bartender?

Both are equally terrible.

Smart home gadgets or futuristic wearables?

Uh, wearables.

Gen AI in marketing or operations?

Oh, uh, easier in marketing, more value in operations.

Virtual reality or in-person?

In-person, definitely.

Cutting edge or proven systems?

Oh, I, I'm cutting— I like cutting edge more.

In-house development, outsourced solutions?

As a consultant, I would have to say outsourced, but in-house does go a long way.

Self-driving car or drive yourself?

Drive myself every time. Don't trust them.

iOS or Android?

iOS.

Summer or winter?

Oh, that's a hard one, but probably winter.

On-prem or cloud?

Cloud.

Software or internally built?

Let's go software.

Customer experience or product innovation?

Oh, customer experience, definitely.

I'm not sure if they're mutually exclusive.

Yeah, I was going to say a lot of these are like, I'd just choose both if I could.

Yeah. Oh, great. Well, thank you, Jeremiah, for, I guess, being so generous with your It's fantastic to probably just have a safe chat about some of these things. And sorry about some of the questionings like tell me what a CISO stands for and things like that, which—

No, it's good to chat about, right? It's good to have the context as you go through it because sometimes you hear a lot of these terms being thrown around and with AI you kind of don't really get what it is sometimes. So yeah, happy to chat through where it sits and what it looks like most of the time.

No, thank you. You just hear the term so much that you think, I've heard it so many times. It's like when you know someone but you can't remember their name.

Yeah.

And you've met them so many times, you're like, I feel embarrassed now.

So familiar yet so far away. Yep.

Yep. But no, thank you for coming in and share— and sharing, and I guess sharing what sort of some of your use cases as well and being so generous with your experience.

No worries. Thank you for having me.

Appreciate it. Pleasure.