Synthetic Data Has a Place, but It Is Not the Bias Panacea
Episode Summary
Speaking in February 2025, Matt Maccaux, head of customer engineering at Google Cloud, is asked what you do when the data you would train on carries the bias you are trying to remove. His answer starts with a warning rather than a method, because generating your way out of it may create problems of its own. Synthetic data has a real use, he says, for conditions someone has already thought of, and it stops working at the edge of what anyone thought to imagine, which he illustrates with a self-driving car and a horse on a highway. What he trusts more is people. Bringing humans into the loop while you fine-tune is, he thinks, the better route, though he is candid that it introduces a bias of its own. His practical advice is to start from the good data you already have and ask open-ended questions of it.
Key takeaways
Ethical AI is not a philosophical topic for his clients, it is an early practical one. He says it is in the first few questions he gets asked about a new AI use case, and what they want is guidance on setting up an ethical AI practice, reducing hallucinations and keeping outcomes from discriminating
His worked example of bias is a hiring one, and the mechanism is the point. An organization that has hired software engineers looks at the workforce it already has and uses that as the base for filtering incoming resumes, so the demographics of the existing team become the filter
The uncomfortable part is that the reasoning sounds fine. We have good software engineers, so should we not hire more engineers who look like that, and his answer is the yes-but, which is where he says the ethics actually live. What organizations want is to catch it early enough to avoid bad PR or bad business outcomes
Asked whether you fix biased data by generating new data, he opens with a warning rather than a method, and says the approach could create additional problems of its own
He walks through the options and finds each one costly. Eliminate a category such as an education background, filter it somehow, or build an equivalence that a degree from one university is worth a degree from another, which the college rankings may not agree with and which he calls a lot of work
What he trusts more than generated data is people, and he says so with a hedge rather than a claim. If we cannot trust the automation or the creation of synthetic data, then perhaps we just have to introduce lots of humans to nudge these models in the direction we want them to go
He immediately turns that on itself. Have we now created and introduced our own bias unintentionally, and will that narrowly drive the outcomes we are going for. Probably, he says, and only the organization can know whether that is good or bad
His rule for when synthetic data works is about what you already know. It has a use when you are trying to create known knowns or known unknowns, meaning situations someone has thought of and can describe
His rule for when it fails is the mirror of that, and the illustration is a self-driving one. A truck on the highway pulling a trailer with a horse in it: the car has been trained to brake for a horse on the highway, but should it brake here, and nobody knew that was even a thing
The conclusion he draws is about who does the work rather than which technique wins. It is going to take a human to define the conditions under which the problem exists, and there is a time and a place for synthetic data, but he would not say it is the panacea for removing all the concerns around bias
On what enterprises are actually doing, he reports no pattern yet. It was early enough in February 2025, he says, that he did not detect patterns across his clients, and most of them are working with the good data sets they already have, where good means high quality with metadata and policies about who may use it
His argument against reaching for public data is commercial rather than technical. If you can use a publicly available data set to nail your business problem, chances are someone else has already nailed it, which is why it is publicly available
The first reason AI stalls before production, in his account, is that the decision may have nowhere to sit. Maybe they do not have executive sign-off, he says, because perhaps they do not have an AI governance council in place, so they do the process, procedure and cultural legwork first, which he concedes sounds odd in an industry that usually fires first and aims later
The second reason is money, and it has two parts. The budget may never have been allocated for compute and specialized GPUs, which he called constrained and outrageously expensive in early 2025, and some organizations are not exactly sure how much AI will make or save them, so the ROI calculation stays open
That is why he sees so many companies starting inside their own walls. Productivity use cases point the model at your own data, keep it internal and make employees more productive at writing code, documenting it or searching a knowledge base, and the business case gets built on that
His worked ROI example is deliberately small and built on invented round numbers. Ten software developers producing a hundred features a year, made twenty percent more productive, gives you either twenty percent more features or the same features with fewer people, and either way the number is measurable
Asked whether companies with no technical debt reach production faster, his answer is unambiguous but qualified. The few digital natives he works with move significantly faster than the traditional enterprises, and what holds them back is not capability but budget, since computational cost is real and funding is a trade-off of a dollar here against a dollar there
His explanation for why traditional enterprises move slowly is about reputation rather than technology. They have reputations that are based on trust, so a feature that does not work, introduces bias or hallucinates is a real problem and can erode the customer base, while a digital native audience, with exceptions he flags himself, tolerates frequent releases that sometimes break
His first instruction to an executive early in the journey is to look before buying. Go and look at your existing data assets, peel back the onion to see what you have, and ask open-ended questions of it, because if your data scientists can answer them you probably have good data and the internal expertise to unlock it
His second instruction comes with a warning most vendors leave out. Start with productivity use cases in your development teams, and expect a dip in productivity and velocity as the tools go in, with the increase arriving a software release or two later
His closing advice is to leave your own industry. Go and talk to someone with a similar job profile in a completely different one, and bring your problems to that conversation candidly and honestly; conferences and meetup groups are where he says it works, and he sees it work in CIO forums
About Matt Maccaux
Matt Maccaux is head of customer engineering at Google Cloud, where he works largely with legacy large enterprises on how they adopt AI. On this February 2025 episode he says ethical AI is among the first few questions his clients raise, and that what most of them mean by it is eliminating bias before it produces bad PR or bad business outcomes. His position on synthetic data is that it has a genuine use for known knowns and known unknowns and is not the panacea for bias, and that bringing humans into the loop during fine-tuning is perhaps the better route, with the caveat that it substitutes one kind of bias for another. Asked whether companies without technical debt reach production faster, he says the few digital natives he works with move significantly faster, that budget rather than capability is what holds them back, and that traditional enterprises move carefully because their reputations rest on trust.
In this episode
| 00:36 | Welcome, and who Matt Maccaux is |
| 01:19 | The question: the ethical use of data in AI |
| 01:28 | The first questions clients ask about ethical AI |
| 02:21 | Eliminating bias, and the job interviewing case |
| 02:46 | Filtering resumes against the workforce you already have |
| 03:05 | The yes-but, and catching it before the bad PR |
| 03:35 | The question: what do you do about biased data |
| 03:56 | Writing the answer while you are taking the exam |
| 04:10 | Eliminate the variable, or build an equivalence |
| 05:05 | Humans in the loop, and the bias that introduces |
| 05:28 | Known knowns and known unknowns |
| 05:51 | The great unknown, and the horse on the highway |
| 06:26 | A human defines the conditions, and it is not the panacea |
| 06:43 | The question: is there a typical approach |
| 06:54 | No pattern yet across his clients |
| 07:21 | Starting from the good data you already have |
| 07:42 | Public data sets, and where synthetic data comes in |
| 08:02 | If a public data set nails it, someone already has |
| 08:38 | A chaos monkey, and where synthetic data belongs |
| 09:03 | The question: why AI stays in proof of concept |
| 09:25 | Maybe no governance council, so maybe no sign-off |
| 09:58 | Budget, GPUs, and an open ROI calculation |
| 10:30 | Productivity use cases, pointed at your own data |
| 11:02 | Ten developers, and twenty percent more productive |
| 12:15 | Legacy large enterprises are who he works with |
| 12:34 | The question: do digital natives move faster |
| 13:05 | They do, and budget is what holds them back |
| 13:22 | A dollar here against a dollar there |
| 14:04 | No technical debt means velocity, and reputations built on trust |
| 14:23 | What breaks that trust, and how a customer base erodes |
| 15:12 | The question: guidance for executives early on |
| 15:22 | Look at your data assets and ask good questions |
| 15:56 | Start with productivity, and expect a dip first |
| 16:42 | Look internally, draw the line to ROI, make the ask |
| 16:49 | The question: what resources to recommend |
| 17:23 | Talk to your peers, join groups, go to conferences |
| 17:49 | Talk to someone in a completely different industry |
| 18:28 | What each category can learn from the other |
In Matt’s words
“are we writing the answer to the exam question while we’re taking the exam?”
Matt Maccaux (03:56)
“then perhaps we just have to introduce lots of humans to help nudge these models in the direction we want them to go”
Matt Maccaux (05:05)
“I wouldn’t say it’s gonna be the panacea to remove all of the concerns around bias in AI today”
Matt Maccaux (06:26)
“if you can use a publicly available data set to nail your business problem, chances are someone else has already nailed it”
Matt Maccaux (08:02)
“the lack of technical debt means the pace, the velocity is so much faster”
Matt Maccaux (14:04)
“go talk to someone that has a similar job profile in a completely different industry”
Matt Maccaux (17:49)
Resources
Google Cloud: Where he is head of customer engineering, working largely with legacy large enterprises
Named on air
AI Realized: The conference he names at 17:23 as an example of where to go and learn from people outside your own company
CIO forums and meetup groups: The two settings he says at 17:49 he has seen work, for practitioners bringing real problems to peers
The self-driving horse: His illustration at 05:51 of the limit of synthetic data, and of why a human has to define the conditions rather than generating data for every case
The chaos monkey: The industry term he reaches for at 08:38, saying you can throw almost like a chaos monkey at your data to see what breaks, as one of the ways synthetic data gets used
Ideas and terms discussed
Synthetic data: Generated rather than collected data. His position is that it has a real use for known knowns and known unknowns, a second use where an organization has little data of its own, and no claim to being the panacea for bias
Known knowns and known unknowns: His test at 05:28 for when generating data works. If someone has thought of the condition and can describe it, synthetic data can cover it
Humans in the loop: His preferred alternative at 05:05. People nudging a model during fine-tuning, with the acknowledged cost that they bring a bias of their own
Productivity use cases: Internal, pointed at your own data, aimed at making employees faster at code, documentation and search. His recommended starting point and the basis for the ROI example
Technical debt: Digital natives lack it and move faster; traditional enterprises carry it along with the data and the customer trust that come with age
Related AI Realized episodes and events
AI Governance as Code: From PDF Policies to Pipelines: Ken Johnston and Bob Rapp on turning an ethical requirement into a control that runs, which is what the governance council he describes eventually has to produce.
Extend Data Governance Into Models, Then Into Agents: Kevin Petrie on the data governance that has to exist before any of this works, which is the precondition behind his good data sets.
Write the AI Policy Before You Write the AI Feature: Maher Hanafi on trust as the gate on adoption, which is the same argument he makes at 14:04 about reputations that rest on it.
Frequently Asked Questions
-
No, not on its own. Generating data to correct for bias risks writing the answer to the exam question while you are still taking the exam, which is how Matt Maccaux of Google Cloud puts it, and it can create problems of its own. His alternative is people rather than more data: bringing humans into the loop while you fine-tune is, he thinks, perhaps the best way to actually solve it. He is candid that this substitutes one kind of bias for another, and says only the organization can judge whether that is a good thing, depending on whether the use case is broad or narrow.
Transcript 03:35 to 06:43
-
Bias in AI hiring tools comes from training the filter on the workforce a company already has. Matt Maccaux of Google Cloud describes an organization that has hired software engineers looking at that existing team and using it as the base for screening incoming resumes, so the demographics of the current workforce become the criteria. What makes it hard, in his account, is that the reasoning sounds sensible from the inside, and he puts the ethics in the yes-but: yes, hire more people like the good engineers you have, but understand what you have just encoded.
Transcript 01:28 to 03:35
-
Synthetic data is useful when you are creating known knowns or known unknowns, meaning conditions someone has already thought of and can describe. Matt Maccaux of Google Cloud sets that against the great unknown, where it stops working, and illustrates the edge with a self-driving example: a truck on the highway towing a trailer with a horse in it, where the car has learned to brake for a horse on the highway but nobody anticipated this arrangement. The fix is not generating data for every animal but having a human define the conditions. He also points to a second use, for organizations that have little or no data of their own to start from.
Transcript 05:28 to 08:38
-
One reason is that there is nobody who can sign off on going to production without it. Matt Maccaux of Google Cloud puts it as a maybe rather than a rule: perhaps an organization has no AI governance council, and so maybe it has no executive sign-off either, and it does the process, procedure and cultural legwork before anything ships. He concedes it sounds odd in an industry that usually fires first and aims later, and explains it by the asymmetry: these organizations can see the power of the technology and also the downside of getting it wrong.
Transcript 09:03 to 11:02
-
You calculate ROI from AI developer productivity by converting the gain into features delivered or staff no longer needed. Matt Maccaux of Google Cloud gives a worked example built on invented round numbers. Ten software developers produce a hundred features a year. Apply AI to scan code for defects, write unit tests, document code and find API information faster, and call the gain twenty percent. That gives you either twenty percent more features a year or the same output with fewer people. Either way the result is countable, which is what turns a productivity claim into a business case that can fund the more ambitious externally facing work.
Transcript 11:02 to 12:34
-
Yes, and the gap is not small: in this February 2025 account the few digital natives involved move significantly faster than comparable traditional enterprises. What holds them back is budget rather than capability, since computational cost is real and early-stage funding is a trade-off of one dollar against another. What speeds them up, in the account Matt Maccaux of Google Cloud gives, is the absence of technical debt, and a customer base used to frequent releases that sometimes break and get rolled back. Traditional enterprises carry the opposite pair: deep historical data waiting to be unlocked, and reputations built on trust that a broken or biased feature can erode.
Transcript 12:34 to 15:12
-
Look at what you already have and interrogate it before buying anything. Matt Maccaux of Google Cloud tells executives early in the journey to take stock of their existing data assets, peel back the onion to see what is there, and ask open-ended questions of it. If the data scientists on staff can answer those questions, you probably have good quality data and the internal expertise to unlock it, and his instruction then is to unleash those teams. If you would rather be cautious, he says start with productivity use cases in the development teams instead.
Transcript 15:12 to 16:49
-
[00:36] Christina Ellwood: Welcome to the next episode of AI Realized, the podcast for enterprise executives leading AI deployments. From addressing security, data, and operations challenges to managing organizational and management changes, AI deployments present the opportunity to redesign our organizations from the inside out. In this episode, we’ll talk about what’s new and now in enterprise AI. I’m your host, Christina Ellwood, and today we’re talking with Matt Maccaux, the head of customer engineering at Google Cloud. Matt, welcome to AI Realized.
[01:16] Matt Maccaux: Thanks for having me on, Christina. I really appreciate being with you today
[01:19] Christina Ellwood: Matt, a current hot topic is the ethical use of data in AI. What are your observations around this topic?
[01:28] Matt Maccaux: I would say that it’s definitely in the first few questions that I get asked by my clients when we talk about new AI use cases, is they’re looking for guidance on how to set up more of an ethical AI practice, right? How do we reduce hallucinations, make sure that the outcomes are not going to be biased or I, I guess, discriminate certainly against people or actions that exist out in the world. And there’s a lot of unknowns out there right now. I think the knowns or the fear that exists is what is driving a lot of this. And we see the, a lot of this came around image generation, the early image generation capabilities that entered the market with LLMs that you could... You-- there was a prompt, you would put something silly or offensive in, and it would generate an image that was potentially of-offensive. Now, is that ethical? That, that’s where the, the questions get interesting. And I think what a lot of organizations are thinking about in terms of the ethics of AI are related to eliminating bias, whe-whether that’s, again, bias to, again, the job interviewing use case that we, I’m sure we all heard about, that a lot of job searching and criteria was biased based on the datasets that existed. So for example, organizations that had hired software engineers, they, organization looked at the workforce and then used that as the base that they would use to then try and filter resumes coming through. And it, it, there was bias in that though, because the workforce was of a certain demographic. And so is that ethical? We have good software engineers. Shouldn’t we hire more software engineers that look like that? Yes, but... And, and that’s where I think the ethics come into play, is the yes, but. And so what I think most organizations are looking for here is how to identify that early in the process so that they don’t ultimately have bad PR or bad business outcomes. And so I think that, at least from my point of view in the world that I live in, that tends to be where most conversations revolve around.
[03:35] Christina Ellwood: If you’ve trained on your data, and your data is inherently biased in whichever way your historical hiring has been biased How do you address that? Do you use synthetic data and train the models on synthetic data? Do you... What, what do you do? Let me ask you, Matt, you’re the expert.
[03:56] Matt Maccaux: Well, it’s a tough one because are, are we writing the answer to the exam question while we’re taking the exam? I, like, I... This could potentially create additional problems. So let’s just continue this thought experiment around hiring. So let’s go create synthetic data. W- we’re gonna do this based on what we saw as being a problem, that the output is biased because of the input. So do we just eliminate a category? Like, hey, do we say eliminate this particular education background as an example, or can we filter this in some way? Or do we create an equivalent that a degree from this university in the United States is equivalent to a degree somewhere else? Now, the college rankings list may not agree, but in terms of the type of candidates we’re looking for, it, maybe it is. That’s a lot of work though, right? So is it easier to just eliminate that as a variable consideration and retrain and see if we can do that again? It’s, there’s a lot of iteration, and I can say from some experience that bringing a lot of humans in the loop as you are f- doing your own fine-tuning is perhaps the best way to actually solve this. That if we can’t trust the automation or the creation of synthetic data, then perhaps we just have to introduce lots of humans to help nudge these models in the direction we want them to go But does that now, have we created and introduced our own bias unintentionally to take us down that path? And is that gonna narrowly drive the type of outcomes we’re going for? Probably. But is that a good thing or a bad thing? Only the organization can know, right? Is this a broad scope LLM or broad scope AI use case? Is it a narrowly focused AI use case? It’s, the answer is, like a lot of things in, in tech, it depends. And so synthetic data absolutely has a use. I think synthet- synthetic data has a use when you are trying to create known knowns or known unknowns. Where synthetic data does not come into play is when we are going into the great unknown. And self-driving, I think, certainly a couple years ago, was in one of those places where... And we, we all love these use cases. You see a, a truck pulling a trailer with a horse in it on the highway, right? Does, your car has been trained to brake if there’s a horse on the highway. Should it brake then? We didn’t even know that was a thing. I... So do we generate synthetic data for all the animals? No, we, we don’t wanna do that. What we wanna do is create conditions where the, if we know that the, the animal is traveling at the same speed, we can rule it out entirely, a- as just an example. And so synthetic data is not necessarily gonna solve that type of problem. It’s gonna take a human to define the conditions that problem exists. So there’s a time and a place for synthetic data, but I wouldn’t say it’s gonna be the panacea to remove all of the concerns around bias in AI today.
[06:43] Christina Ellwood: Okay. You do work with a lot of different enterprises. Is there a Typical or dominant way that enterprises are approaching this problem?
[06:54] Matt Maccaux: No, I would say there’s not a typical way yet. I think we’re still in such early days, I don’t detect patterns across my clients. I think what most of my clients are doing is dealing with the good data sets that they have, and, and good requires a definition, as in it’s high quality, we have good metadata related to it, there’s policies about who can use it, under what conditions, how it gets surfaced, et cetera. I think most of my clients are starting with their good data sets and building that AI muscle from there before they move into sort of that advanced stage. But this may... So then what about the customers that don’t have any data? What if you’re a digital native and you’re just starting a business? You don’t have data, so what do you do? Do you go use publicly available data sets? Sure, but is that gonna be useful for your use case? That’s where synthetic data, I think, comes into play, is for organizations that don’t have good data. What about organizations that don’t have lots of good data? A-and this is where things become challenging. Do you use public data sources? Uh, but that isn’t quite right size for your particular business and the problems you’re solving. Maybe you’re lucky and it is, but if you can use a publicly available data set to nail your business problem, chances are someone else has already nailed it. That’s why it’s a publicly available data set. Someone’s willing to share ’cause they no longer get an advantage from using that data set. Or perhaps a public source, but still, if anybody can use it, is it really gonna be that differentiated? And so this is where I think synthetic data comes into play. Synthetic data can come and, and take those publicly available data sources, or the perhaps the limited sets of good data that you have, and extrapolate that out. And there’s different ways you can throw things into that, right? You can throw almost like a chaos monkey at your data that says, “Just throw stuff into it to see what we can break,” or, “Let’s see if we can create conditions that are gonna be unique to our business that we can react to.” So synthetic data has a place, but I think it’s generally in use cases where the sets that exist are constrained for that organization. Did that make sense, Christina?
[09:03] Christina Ellwood: Yes. Thank you very much. That was quite, um, helpful. Um, as we know, many organizations have AI in POC or pilot, uh, but they haven’t pushed yet to production. Why is that in your experience?
[09:21] Matt Maccaux: Every one of my clients is gonna give me a different reason for why they’re not ready to go to scale. Maybe they don’t have executive sign-off to actually push this through because perhaps they don’t have an AI governance council in place. And so they’re just- they’re being really cautious, and so they wanna do that sort of process, procedure, cultural legwork first before they put things into production. And I do see that. And I, I know that sounds a little crazy in tech that usually we like we fire first and then we aim later. Some organizations because they see the power but also the potential downsides of getting it wrong, doing that governance first is one of the reasons that we have not seen so many use cases into production so far. That... So that’s one use case. Second use case is ch- budgetary. Organizations, uh, perhaps have not put the budget in place to spend those dollars on the AI, whether that’s paying for compute, specialized GPUs, which we all know are constrained and outrageously expensive. Some organizations recognize that there’s a ton of power and upside in AI, but they’re not exactly sure how much money it’s going to either make or save them down the road, so that ROI calculation. And so where a lot of organizations are starting is with a productivity set of use cases. Productivity use cases, point it at my dataset, keep it internal, make my employees more productive, whether that’s writing code, documenting code, whether it’s doing search for knowledge base. I think a lot of organizations are starting with that, billing- building their business cases based on the productivity enhancement return on investment So let me, for, for the listeners, let me make sure I describe what I mean by productivity enhancements as that relates to building an ROI use case. So let’s say I’ve got a team of 10 software developers, and those software developers can create 100 features a year based on their normal productivity. And with the application of AI to my business, I can make those software developers, let’s just call it 20% more productive, whether that’s scanning their code for defects, automatically writing unit tests, automatically documenting the code, helping them find information quicker about API specifications. And it-- so if I lead a team of 10 software developers and, and through the application of AI, we can become 20% more productive, then I can either produce 20% more features every year, or I can potentially reduce staff to produce the same number of features in a year. Either way, I can make the very practical business case that says, and it’s measurable, this many features get done now versus they before. Now I’ve got a, a direct line to ROI, and I can go make that ask for some of those more advanced use cases externally facing. Let’s improve our products. Let’s actually update our manufacturing line, those sorts of things. So I think a lot of organizations are still in the build the business case mode right now. As legacy large enterprises is generally whom I work with, and that’s where many of them are today. So again, multifaceted answer, Christina, to why things are slow, but I think it falls into those broader categories. I’m sure I missed some. I’m sure listeners, hit me up and tell me, like, which ones I missed, but those are the big ones that I’m seeing today.
[12:34] Christina Ellwood: Thank you. I think it’s also very different for the digital natives or these companies that are starting from without a lot of tech debt. Either they’re startup companies or they weren’t very instrumented in the first place, so they don’t have tech de-debt, and they’re in a position to design their enterprise from the beginning with AI front and center. So can you answer the same question of are they going to production, uh, faster or are they also stuck in POC? And if so, why?
[13:05] Matt Maccaux: So the few digital natives that I work with are moving significantly faster than the, the traditional enterprises that I work with. I would say that many of these digital natives are budget constrained, just the very nature of being a non-public entity, perhaps early in your funding journey. It’s always a trade-off of do I spend a dollar here or do I spend a dollar there? So a lot of the things holding back the, the digital natives is really just budget and it’s creating that budget or getting the funding to be able to put that use case into production because there is very real computational cost for this, and oftentimes that’s the budget constraint. I would say that the flip side of that is when there’s not budget constraints, they’re moving a heck of a lot faster. And yes, those digital natives may not have the history of data, the customer data, the organizational data to build on. They don’t necessarily have that intelligence already baked in, sitting in the form of a lake or a warehouse with all of that just waiting to be unlocked. But the lack of technical debt means the pace, the velocity is so much faster. And customers of digital natives are also used to a different sort of release of software. And I think this is, uh, the other thing that holds a lot of the traditional enterprises back is they’ve got reputations that are based on trust. And if, so if they start releasing software or features that breaks that trust, either the feature doesn’t work or introduces bias or it hallucinates or whatever the case may be, that’s a very real problem, and their customer base may erode because of that. Whereas the perception... There’s exceptions to this, and I’m sure the listeners will call us out on these, but if you’re a digital native and you’re used to pushing software very frequently and sometimes it breaking, or oftentimes it breaking, but being able to roll it back and adjust to it, there’s a different level of tolerance that those customers have. And so therefore the organizations have a different tolerance for risk of pushing something out that doesn’t work. So that would be a really fun time to be in a digital native being AI first and AI focused because the, the risk is so much lower, I feel, to those organizations ’cause they can pis- pivot so much faster.
[15:12] Christina Ellwood: Switching back to the focus on the enterprise for a minute, what is your guidance for enterprise executives who are early in their journey?
[15:22] Matt Maccaux: I would say to organizations and executives that are early in their journey for AI adoption, go take a look at your existing data assets, and perhaps peel back the onion a little bit to see what data you have and start asking good questions. And if you’ve got data scientists on staff, this is what they live for. Ask open-ended questions about the data and see if they’re solvable. Because if they are, that means you probably have good quality data, you have some internal intelligence with your teams that know how to unlock that data. I would say unleash them, unleash those teams. And if you’re, if you wanna be cautious, start with those productivity use cases first. The hook in code development tools, code security scanning tools, application integration tools. Start with your development teams. And yes, you will see a dip in productivity, you will see a dip in velocity at, as you start to introduce the AI capabilities for those teams. But I can almost guarantee that within the, the next couple of software releases, I don’t know how long your sprints are and those sorts of things, but I would argue that within the next software release or two, you will see the velocity start to significantly increase. Use that as the foundation for how you go ask for budget elsewhere on how you want to adopt AI in your organization. So look internally, focus on productivity, draw the line to ROI, and then make the ask for investment.
[16:49] Christina Ellwood: Great. If you were, um, talking with a executive today, what resources would you recommend that they look to for learning more? And what resources do you recommend to our listeners who may be a contributor to the team rather than leading the team?
[17:07] Matt Maccaux: I learn best when I talk to my clients. I, of course, I do my own research, but I learn best when I talk to people that are actually doing the work and struggling to do the work. Perhaps that’s looking within your organization, actually just sitting with your developers and finding out where the problems are. But maybe you lead a software development team. Maybe you know what that is. So how else would you learn? My recommendation is go talk to your peers. Join AI groups. Go to AI conferences like AI Realized. There are a number of different ways for you to go learn and talk with others. What, what I see is if you’re in the same industry, let’s say you’re in finance, you’re not gonna probably learn a lot from someone else in finance ’cause they’re probably not gonna talk to you about their deep problems. So go talk to someone that has a similar job profile in a completely different industry. And conferences are a great place to meet up with people with this, but, uh, also meetup groups are another great place, and just very candidly and honestly bring your problems to that. I see this effectively in CIO forums, and I see this effectively in meetups where we have practitioners getting together. And so I, I would say that talking to your peers and working through problems that way outside of your company is a great way to get some of that exposure.
[18:19] Christina Ellwood: Great. As we wrap up, what would you like our listeners to take away from our conversation today?
[18:25] Matt Maccaux: It’s great to be a digital native and not a traditional enterprise. No, that, that’s, that’s that’s not what we want. I, I, I think both have their advantages, right? You’re a traditional enterprise, you’ve got the data, you’ve got the experience, you know your customers. What can you learn from those digital natives and how they release software? Are there best practices you can learn around releasing frequently, making some mistakes, but being okay with that, and rebranding the way you do software or readjusting the way you do software? See what you can learn there. And then the flip side is if you are a digital native, you’re gonna accumulate tech debt, no doubt. It’s gonna happen over time. The changes of the business and the market dynamics, it’s going to happen. And so look to the traditional enterprises and see how they’ve adopted and adapted to technical debt over time. Right? Those legacy systems, oh, they’re the worst. Yeah, but they contain all of our important information. And so is there things that we can learn, and, and what mistakes did they make along the way? Get... Talk to your peers. Talk to your peer group outside your initial peer group. I’d say that’s the biggest takeaway. See if you can get outside and look at a business that is radically different than yours and see what you can learn from that. I know it sounds obvious, but especially if you’re in one of those two categories, digital native versus enterprise, see if you can talk to a peer in one of those and s- and see what you can learn from there. That would probably be the biggest takeaway for where we are in the adoption cycle today.
[19:42] Christina Ellwood: That’s great advice. Matt Maccaux, thank you for talking with me today on AI Realized.
[19:48] Matt Maccaux: Thanks for having me, Christina. It was great talking with you and the listeners. I look forward to the follow-on conversations.