Tom Godden:
So we lived through in 2023 and 2024 a little bit maybe of the hype of generative AI, the excitement, but a little bit of hype that came with it. I believe, and I think we believe here strongly at AWS that over the fullness of time we're going to see really almost every application augmented by AI and by generative AI. But given that as a backdrop, how do we still help leaders rationalize as they bring forward business cases on generative AI so they don't oversell it? So that you find that correct value. How do you advise people to move forward in that?
Matt Fitzpatrick:
So this goes a little bit to why only 8% are making it right now. And I do think the uncertainty of success is a tricky part in the business case development process here. What I mean by that is let's say that you want to install a new software system to do any process like expenses right? Right now you would build a business case and you'd know exactly the workflow it's going to do and you'd have very high confidence. And so it’s a very simple process to build a business case for that. But imagine your business case rests around 12 different things where you could use your organization-
Tom Godden:
Solve for N, yeah.
Matt Fitzpatrick:
Where five of them might work and seven of them might not work. And I think you actually have to change the way business case development works to look a lot more like venture capital. I don't think that means that only one in ten work. I think it means that you've got to be comfortable experimenting, trying 10, 12, 14 different things and over time you'll get in the first batch you'll get five that work. And the next batch you'll get 10 that work. You also won't be investing huge amounts to develop each one.
The way I think of it is, take knowledge management, the same data you use for that service call as an example, you can probably use for contact centers, you can probably use for document production about how the call went, all this kind of stuff. And so you'll end up with 5, 6, 7 use cases linked to the one you built that worked.
Tom Godden:
I love that. And I advise people all the time on it, get that document summary use case maybe to work, but then use it in HR, use it in finance. You're going to have to tweak it and train the model a little bit, but you're 80% or 90% of the way there.
Matt Fitzpatrick:
This has been the hard thing about business cases. You're not taking a paradigm where it's going to take you two years and it's one monolithic business case that at the end it's done. You're actually more of a paradigm of “I need to get four different data components for this use case. All of those data components are modular, I can use them for four other use cases. And so actually my business case development is, ‘does this seem worthwhile, where I'm going to build enough capabilities and I can justify getting started because it'll be useful for things repeatedly?’” And over time on a three, five year basis, you're going to make multiples of your investment. It just may not be on the first one.
Tom Godden:
So Matt, let's pretend that I'm a CIO, as a former CIO, so not a hard thing to pretend. And let's say I'm looking at a circumstance where I want something to be very unique, customized to me, but I also want it to be inexpensive, right? Isn't that always the paradigm? How is McKinsey, how are you approaching advising people build versus buy? When you build it, you get to customize it. It costs a lot more. When you buy it, theoretically less expensive, less customized. I as CIO, I'm stuck in the middle now. Help me out. What advice do you give?
Matt Fitzpatrick:
Yeah, you know, I have I have this view that actually the definition of build versus buy has become very skewed in how we think about it as any technology organization. Here's what I mean by that. 10 years ago, the definition of build versus buy meant, buy: I take something off the shelf and it works and it cost me a certain amount. And in build case, to build, I would literally have to stand up a mainframe computer. I have to build all of my code largely from scratch, often in, maybe this is 15 years ago, but-
Tom Godden:
Build it all.
Matt Fitzpatrick:
You are really building something from scratch and your investment is going to be massive.
Tom Godden:
We appreciate you saying that because that's a little bit AWS's strategy. Help take that undifferentiated lifting.
Matt Fitzpatrick:
Well if I take a broad view, not with any particular technology provider, today, “building” means I spin up a cloud instance. I use various modular components. I pull GitHub code, code repositories with information. I pull from six or seven different off-the-shelf components that allow me to stand something up for a fraction of the cost that we used 10 years ago that's really useful and customized to my organization.
And so three years ago I was working with a player that was debating buying an off-the-shelf, it was a large asset manager and they needed to rebuild their credit system. And their debate was do I buy an off-the-shelf credit platform or do I build one? And no, this is not a technology company, 10 years ago the idea of building a credit platform would've seemed absolutely insane.
Tom Godden:
Alarm bells are going off.
Matt Fitzpatrick:
But when they ran through it, what they ended up realizing was, okay to buy this, it's going to take me a very material investment to customize the data schema to match to the off-the-shelf credit platform. And then I'm going to need screens that look like...They had a homegrown system they were trying to replace when they did this, it was going to take a ton of investment to customize the off-shelf system to look like what they wanted. It was going to take a ton of investment to map the data to it. And so the time they were done-
Tom Godden:
What's the end game?
Matt Fitzpatrick:
They were basically building a new system on this kind of off-the-shelf system. So their other option was take all the modern tooling that exists, modern data tooling, cloud infrastructure, all that, and just stand up a system. And that actually ended up crazy enough not being more expensive than using it.
And we're seeing that more and more. I think Gen AI is going to really accelerate that because one of the things I've loved about the Gen AI ecosystem is how interoperable all the different applications are. Nobody is building this to say, "You can only use ours." Everyone is saying you can participate in best of breed. And so any new tech comes out you're going to be able to participate in it. And so the question then becomes if you create a new credit application today and you buy something and then some new interesting Gen AI tool comes along, you can't use that. You've actually got more tech debt by using the ten-year-old off-the-shelf credit platform than you would if you built a modern Interoperable evergreen stack and allow you to use all the modern components.
I will say the number of companies that have gotten comfortable with building, as you might call it today is way higher than it was five years ago. And it's all the investment cloud and infrastructure allows it to be so much faster.
Tom Godden:
So Matt, you've done a lot of transformations, you've led a lot, you've seen a lot. McKinsey talks a lot about rewiring organizations to be able to do this. What are you seeing is successful models for how people are approaching that cultural aspect to help succeed as we move into this generative AI?
Matt Fitzpatrick:
I think a couple of different things have been key for that. One is being very clear on what use cases actually matter and can move the needle. I think again, if you take a 10 year ago view where you might have your tech organization not really talking to your business organization, that is surefire failure. You need a clear view of what's my vision? What are the 10 use cases I'm going to try out, how are my tech teams and business teams going to work together to test and learn? That whole process is a new muscle. I think the skill set we're seeing the most interest in these days is what you might call a translator skill set or somebody who's kind of digitally knowledgeable but also understands the business. I've worked with a bunch of real estate clients, for example, and somebody who understands both tech and the real estate industry is way more valuable than someone who understands one or the other.
I think you need to have the link between the tech organization and the business teams so that what's being built is workable and relates to what the business users want. So I think the translator skills gets really important.
I also do think you have to think a lot about re-skilling, or at least the technical skill set of your engineering organization. Like if you have an engineering organization that doesn't know how to use Python or even things like Rust that are a little bit newer, it's going to be harder for you to take advantage of a lot of the modern Gen AI tooling. And so what that may lead is kind of retraining, re-skilling, things like that or new hires, but you're going to have to augment your traditional engineering organization.