Episode #79: After AI Flags the Defect: Closing the Execution Gap in Manufacturing
In this episode of U.S. Manufacturing Today (powered by Veryable), host Matt Horine speaks with David Craig, founder and CEO of ProdigyIQ Technologies, about closing the gap between AI identifying a problem and manufacturers taking corrective action. Drawing on his Army maintenance background and manufacturing experience, Craig explains why clear ownership, decision-making authority, cross-functional coordination, and verification are essential to turning AI alerts into resolved issues. They discuss leadership visibility and sign-off, along with Craig’s “reversible AI rollout” concept: planning how work continues when AI becomes unavailable or unreliable and verifying operational readiness before restoring it. Craig also outlines a practical 30-day approach to documenting, testing, and improving one AI-assisted workflow and shares the thinking behind his podcast, The Operating Code.
Links
- David on LinkedIn
- David's Website
- Matt Horine on LinkedIn
- Veryable Is Revitalizing U.S. Manufacturing
- Sign Up on the Veryable Platform
Timestamps
- 00:00 Welcome and Setup
- 00:51 Meet David Craig
- 01:40 Army Lessons on Accountability
- 02:50 Pandemic Launch Failures
- 04:59 Why AI Alerts Stall
- 07:29 Where AI Pilots Die
- 09:50 Defect Ownership Breakdown
- 13:10 Readiness Mindset Transfer
- 15:03 Leadership Visibility and Signoff
- 16:25 Reversible AI Rollouts
- 19:30 Hybrid Fallback Design
- 23:44 Building Prodigy IQ MVP
- 25:50 The Operating Code Framework
- 29:11 30 Day Execution Playbook
- 31:41 Where to Find David
- 33:23 Closing and Subscribe
Episode Transcript
Matt Horine: [00:00:00] Welcome back to U.S. Manufacturing Today, the podcast powered by Veryable, where we talk with the leaders, innovators, and change makers shaping the future of American industry.
A few episodes back, we talked about getting AI out of pilot purgatory, and today we're picking up the problem that shows up right after that.
The model works, it flags the issue, and then nothing happens. Nobody validated it, nobody owns it, and three weeks later, the same defect walks back through the door. My guest today is David Craig, founder and CEO of Prodigy IQ Technologies based in Birmingham, Alabama. David has spent about two [00:01:00] decades in manufacturing, including some engineering time at Mercedes in Alabama and supplier development and launch work across the industry.
And before that, 17 and a half years in Army maintenance, so a fellow former Army guy here on the show today. He also hosts his own show, The Operating Code, so be sure to check out his podcast after today's conversation. David, welcome to US Manufacturing Today.
David: Hey, Matt, welcome. Thank you for having me.
Matt: We're very excited to have you today.
This is gonna be an exciting topic, something that we've talked about a lot on our show, and so any insights we get into this, because it's been AI, AI, AI all the time. And so we're starting to see these conversations shape up, and you've got a lot of really great things to talk about. So before we get into all that let's start where you started.
Uh, Time in the Army maintenance, then the plant floor. You were a wheeled vehicle mechanic and a power generation specialist then, engineering time at Mercedes. How did these worlds shape the way you look at the problem on a plant floor today?
David: The problem is shaped like military operations. It taught me readiness, it taught me inspections, it taught me maintenance [00:02:00] accountability, and the importance of following the process. And manufacturing, it exposed me to following production targets, defect containment quality systems, supplier problems, and cross-functional decision-making.
And the common denominator was accountability.
You cannot simply discover a problem, write it down, and assume it will be resolved. You need to define a process and an owner and evidence that the correction action worked, the corrective action worked
Matt: No, that's when we were talking and when we first met you told me about, talk- we talked about a little bit of life in the Army a lot of motor pool Mondays that I spent out there where, that you would find those types of things, and there were some corrective action, but if you didn't fix the problem it was just a recurring one.
And so this is a really interesting, crossover. The, the layover from military to manufacturing is always something that that fascinates me. It never stops.
David: Yeah.
Matt: During the, we can also talk about your time at, Mercedes and throughout the show, but specifically something that caught my attention, during the pandemic EV rush, you were doing supplier [00:03:00] development, launch work, those types of things, and you kept seeing the same issues come back.
What were you seeing, and what pushed you to start building something for yourself?
David: Matt, man, that's, that was an interesting period because when you look at what was happening in the automotive manufacturing during that time, everybody was moving fast. They were spending money and all that stuff, but you had product launches, supply readiness, quality concerns, and production demands, and there was pressure to deliver.
But something I kept noticing was that we could identify an issue, get the right people involved, have the meeting, develop a corrective action, and sometimes still see similar problems come back. And I started looking beyond the technical problem itself, and I wanted to understand what was happening between identifying the issue and verifying that it had actually been resolved, and was the right person responsible, and where, and were corrective actions being followed through.
And when I looked at all that, I saw that we wasn't verifying things effective. We didn't have any effectiveness in verifying things. [00:04:00] Leadership wasn't getting the right information. And a lot of organizations don't necessarily have an information problem. They have an execution problem. And that's the main reason why during that time it was so interesting, because everybody wanted to produce, but they didn't know how to execute. And that right there really pushed me into doing what I do because we already had systems that capture information. But we ge- had, now that we got artificial intelligence, that can analyze the information and also identify patterns faster than we could before. And that when, and that's when I started building what I built
Matt: Yeah. Excited to get into that and talk about it because you said something there that always catches my attention. There, there's more information available now than at any time, before. There's more data, there's more everything that allows you, if you're in if you're intent on making a decision, there's plenty of evidence there to make one, right?
But then the, the execution gap is really something that it, it's-- people talk about it, but they don't know what it means. So I'm excited to get into that a little bit here. And [00:05:00] everybody's talking about buying AI right now. Every vendor, every conference I go to every deck that I see, I get, probably like you, a ton of emails every day talking about this or that.
But you asked a different question and it caught my attention. Everybody wants to invest in it, and your question is what happens after AI identifies the problem, and why is that the question that most companies skip? Even though they know they have this execution gap why do they skip the outcome?
David: One thing, Matt, I think it's because everybody's excited about what AI can do. It can do a lot of things. It can it can take you-- You think, I think about, when I think about AI, I think of AI like a rocket, it takes off fast. But, and everybody's excited. But when I work in this space myself, I think sometimes we become so focused on the technology that we forget about the organization that the technology is supposed to serve, and that's the issue.
And I have an example that, let's say you got a manufacturing plant, and you implement an AI solution that monitors quality data. And now that system can identify a potential defect trend before it [00:06:00] becomes a bigger problem, that's powerful. But let me ask you something. What happen when the alert comes through and nobody does anything?
Does somebody receive it? Does somebody know they're responsible for reviewing it? Does that person have the authority to make a decision? And most businesses fail because of decisions. And once a decision is made, who's responsible for making sure that corrective action happens? See, those are questions that have to, that have nothing to do with how intelligent the AI model is.
Those are questions about how your organization operates. And what I've realized is most companies are not built to operate with AI. And I think that's where a lot of businesses miss it because they implemented AI without first making sure their operational systems are designed to support it
Matt: No, that's a really good point because you s- yeah, I'm gonna add a little color to this because I see a lot of, I see a lot of stuff out there, right? And on the AI front that people will call it a range of things like, on, like the, the public side of it, you'll see like AI slop content creation, stuff like that, that just doesn't, it [00:07:00] doesn't land.
You can tell it's not human. And then you have this st- this, this function that's designed for systems and designed for, helping manufacturers monitor the quality of their business, do things for their business and make important decisions. But it do- it goes unmonitored and it goes unchecked.
That's something that we have to keep an eye on. And, you said it's not the solution, and you don't even know if it's an advantage, but it's more of a force multiplier, and so a- adding it to a broken system is like your example was, I think when we met, you called it putting the rocket on the bicycle.
You've seen AI a recommendation that nobody wants to take ownership of, but where do they go to die or where do they go to actually become action items and things that people can execute on?
David: And what they, this is where AI go to die. They pilot, but they don't implement. I've seen so many companies pilot AI, and they s- they spend good money on pilot, but then they drop the ball on implementation. And that's because in the pilot phase I look at the pilot phase as a trial period. And at that trial period, what you're doing is you're designing your o- you're [00:08:00] designing your organization to work with the technology that you're bringing in. But a lot of times when I go into these, into the organizations, and I see that they have nothing defined. What's on paper is not what's on the floor, and you're trying to put something in place, and you don't have a control. And that's what I tell a lot of manufacturing companies. I've been to tons of manufacturing companies, Matt. Matt, it'll blow your mind when I go in there, and these are billion-dollar companies,
but they do not have the structure that is needed to be successful with this technology, and it fails
Matt: Yeah. It's easy to fail when... We talk a lot about the inputs that we put into it or the right paper, and you're right the mismatch from what's on paper to what's actually going on the floor, it can make white people's life more complex on the floor if it's not, coded to what they're doing on a daily basis.
If it's something that's just like creating dashboards, the recurring joke about creating, dashboards so executives can make informed decisions. It's like that's, it's great, but if it's just game to that system that it's not actually making an impact and it does [00:09:00] go to die, the pilot phase is something that, people will take plenty of leeway to just, yeah, we'll pilot something, and then they don't do anything about it.
What's the worst one you've seen where, if somebody's implemented a pilot, we don't have to name names, but you've seen people take on an AI pilot, but what's kind of one of the worst things that you've seen out there? Maybe it'll resonate with some folks who are listening.
David: I had an organization that they implemented some AI agents
into the organization, but their data was trash.
When I say trash, they had so much hallucination that ChatGPT would've been better than what they built.
Matt: Yeah. It's true. I think that the data validation is pretty critical. I've done some AI pilots. I've done some things that, have gone on in the space, and y- it really makes you question what were people operating off of? If this was the assumption, it's not a correct one, and then it gets into the real world, and it creates a mess.
That kinda leads into, how your company and what you do may be a little different and just walk through the s- the signal a little bit and make it more concrete. So if you picture a [00:10:00] plant, an AI tool flags a likely defect trend on one of those lines. That signal now has to move through production, quality, maintenance, and eventually to leadership.
Who's authorized to validate the recommendation, and what happens when nobody is?
David: First thing you receive the signal. Just say you get a defect. This defect is logged. Now this defect is logged, now you gotta go through the process of investigation. But before you investigate, you gotta go through who gonna own this defect? Who's gonna take lead of this defect? If two people are working on this defect, who-- how are you guys communicating with this defect?
Not only how you guys communicating on this defect, what the process... most times in a, in an organization, the person that own the defect is quality.
Quality, the quality engineers, they get beat up so bad. I seen-- I went into an organization man, and I seen the quality engineer. They went through about seven quality engineers in six weeks. Yeah. So when you're doing the execution piece, because there's things that can be falling between [00:11:00] departments, and that's one thing, the departments. It always-- You see a lot of departments work- working in silos, quality doing their own thing, production doing their own thing, and then you probably got logistics doing one thing, and you got all of these different departments working in silos, but nobody is working together.
Then you got maintenance. You don't get maintenance involved because sometimes a defect could come through preventative maintenance, it could come through production, it can come through s- a supplier. I can give you a story. I was working at this tier one supplier, and they was doing a new project launch for EV, and I was responsible for helping them get this launch off, get this launch off the ground.
And they was building 120, 120 door sets just to get 60 good ones, and those 60 good ones weren't good. And at the end of the line, they had 120 point inspection point, and they was checking for defects that should've been caught
in the place that where the part was manufactured at. So I went in and I put quality gates, and I started measuring [00:12:00] quality from there.
And the thing is, nobody wanted to own the process.
Nobody. They... It was like herding cats trying to get somebody to make a decision. And I'm a consultant.
And
Matt: Yeah. The, the consultant would love to make the decision half the time, right?
David: Yes, I'm the consultant, so I don't have the authority that the plant manager have because I'm hired help,
Matt: Угу
David: and I have the OEM breathing down my neck, and I'm breathing down their neck, and it gets to the point where it got so bad that the OEM had to bring in a special team just to run this automotive manufacturing plant because nobody wanted to own it
Matt: Yeah, that's an incredible it's scary because you don't know, like, how many of these, like you said, billion-dollar companies, Fortune 500 co- name brand companies that have these processes, but if nobody owns the execution piece of that, you're missing SLAs, you are creating and generating a ton of waste.
David: Yes. Oh my God
Matt: You just cited is an incredible one. It's [00:13:00] scary because it's a lot of money, it's shareholder value, it's employee value, it can eventually lead to impact on employment, in certain places. So these are real world problems that can be fixed by, your product, which we'll get into a little bit more here.
One good qu- crossover question here. In, in army maintenance, inspection, escalation, readiness, they're not optional things. These are not things that are just like we optionally make it, week after week. What carries over? Is, was that foundational for your viewpoint on this and what do plants get wrong by comparison if you take that worldview into, to a manufacturing plant?
David: Well, Matt, it all goes back to readiness. In the Army, just because somebody worked on a piece of equipment doesn't mean it's automatically returned back to the service.
You still have inspection requirements, you still have documentation, and you still have people who are responsible for determining its status, and that's the mentality I carried into manufacturing.
You just don't want to know whether somebody did the work, you want to know whether the equipment, process, op- operation is ready to perform. Especially just think about being in a combat zone
and somebody then said that they didn't fix this [00:14:00] weapon system, and you go, you take this vehicle out into the combat zone, and you get into a firefight, and your weapon don't work.
Think about how detrimental that would be. So I always thought about that when it comes to going into manufacturing, because when you start thinking about AI through that lens, it changes the conversation. Because now you're not just talking about technology that detects something, you're talking about a complete operational system that supports the work from beginning to end, and that's what really made me look at things like that, because Army maintenance you've been in the Army, so
Matt: Yeah.
David: you know how it is.
Matt: Yeah. There's some great stories of I always joke about with folks that I work with, and this is no knock on the supply sergeants or anything like that, but the supply sergeants always talked about the gray area and kinda how they worked and fixed problems. And they did, and it fixed problems, but it was always to the point of satisfying the requirement that a system was ready or something was ready, and you did that to make sure that the, the end state of it was a workable piece of equipment.
No ifs, ands, or buts. It [00:15:00] was no question about it. Now, paperwork followed and things had to happen, right? But the-- I think a big piece of this that really caught my attention when we first met was talking about the leadership function of this, and h-how do they know when something's actually closed?
What evidence proves the fix held and that it won't come back? And does leadership have a mandate to make sure that stays in place and not just trust it to the AI system?
David: Leadership, they have to, leadership have to have vis- visibility.
And when I say leadership has to have visibility, because it don't fall back on the-- it don't fall down on the person that had that's p- implementing the fix. It falls down on the person that ultimately responsible for the operation.
So I believe in complete visibility. Not saying that you have to micromanage, but you do have to have eyes on it. And I believe leadership should be the one to have that final si- sign off on if this has been fixed or whatever, because that drives accountability back to the person that fixed it.
Matt: No, that, yeah. It, the accountability factor is the big one. It's we're seeing too many people, leaders abdicate because they [00:16:00] think that some AI tool has probably fixed some problem when it's not even being validated. The inputs aren't right, nobody's owning the process, and so all these things continue to snowball.
You made a very interesting point about leadership having really direct oversight and measurables, tangibles to what's actually going on, not just "Ah, AI tool, fix this, we're done." It's, you can't move on, especially in a manufacturing environment. So I wanted to double down on that 'cause you made such a great point of it that leaders do that from time to time.
Yeah. Yeah, so this is the flip side of it when the AI is wrong or it goes dark, right? It you, we talked about it being a force multiplier, but when it goes dark you've built a workflow, people trust the signal, it's woven into how the line runs, then the tool goes down. Or worse, it's quietly wrong, right?
That's the worst case scenario. And you published a white paper on this recently, and it was called Designing a Reversible AI Rollout, and it argues a stop switch is necessary but not sufficient. What happens to the work that's still arriving when you turn off that artificial intelligence tool?
David: Man, I think this is one of the most overlooked conversations around AI [00:17:00] implementation because everybody wants to talk about what AI can do when it's working, but not enough people are talking about what happens when it stops working.
And I've had this to happen to me. I had a situation where one of my AI tools that I was, one of my APIs that I was using, it went down,
and I was dead in the water.
So I had to-- That's what made me write the white paper.
Matt: Yeah.
David: So let's imagine you implemented AI into a critical part of your op- operation. Maybe it's supporting inspections, maybe it's helping prioritize maintenance, or maybe it's analyzing production conditions, and everything is going well. But one day, the AI system goes down, or maybe it start producing unreliable recommendations, so somebody says, "We need to turn it off."
Okay, that's fine. But here's the question. What happened to the business when you turn it, when you turn that AI off? Because the work doesn't necessarily stop. You still got customers. You still got production requirement. You still got employees who need to know what they're supposed to do. And that's why I say stop, a stop switch isn't [00:18:00] enough.
You got to design what happens after the switch go- gets turns off. You gotta know who's responsible for the work, who can continue manually, what needs to be paused, what decision is required, what decision require additional review, and how do we maintain control over the process? Because if the business can't operate without AI, then we potentially create a dependency that needs to be managed.
And in manufacturing, that's a serious consideration. You do not want to do that.
Ford seen it. Not to call names, but Ford seen
Matt: Yeah. No, that's a really good point. Yeah it's a really interesting prospect because people talk about these rollouts and there's no-- there's not necessarily a backup plan. This isn't necessarily a contingency plan. This is like the undo button, right? "Hey we tried something.
We need to go back to the way it was." I've told this story a number of times. This was before the big AI surge in a, a manufacturing environment. We had to undo an ERP and a W- and a WMS, right? Like our WMS, and you've seen it, you know what I'm talking about. It's the consulting group that's in there.
They built like this monstrosity of a WMS, [00:19:00] and we eventually, we didn't have this on paper, but we planned for, about two months, 60 days. It was like, "We need to cut this off in 60 days. How do we back out?" We were willing to back out to spreadsheets, it was so bad. It's like we'll just do it ourselves, and this was before like AI workflows.
So you make a really good point that I don't think people have thought about or asked the question when they're doing some kind of AI implementation, what do we do if this doesn't work and we get in a little too deep? And it's I think that's that old adage, right? Like it's easier to get into something than it is to get out of it, right?
And so that's, that seems like something that you've come across before and maybe your system's designed to do. You write that leaders should define a minimum service before they ever need a fallback, before they'd ever need a fallback. So the... Is your point of view on that they need to be able to meet a minimum threshold and then have the fallback?
Is that kinda how it works out?
David: Yeah, because like I'll give you an instance about something that I built. I, the system that I built, and I know you said we was gonna talk about it, but I'm just gonna talk about that fallback process. It's designed to be AI assisted, but it just say if the API's not working, you still can, it still can be [00:20:00] hybrid where if you can't get AI assisted, you still can continue the problem-solving process because you can problem solve manually.
But you still have access to your documents and everything like that. You just may not have access to the API, the LLM that execute for you to do the that pull the data in instantly. But you still can, it still got that fallback where you won't have to worry about, if... 'Cause I built it where you can depend on AI, but not depend on AI.
And a lot of AI implementations, they building it strictly to be a dependency on it versus a hybrid model where it could be either/or, depending on how your organization run. And me, I'm a big hybrid person. I love hybrids. If I was to get something that's electric, it'd have to be a hybrid.
I don't want fully electric. I want a little gas and I want a little electric. That's how I look at when you implementing AI. Start out, because you gotta think about it, this is new technology o- on a scale, and the technology is changing so fast [00:21:00] that if you go all in, then you probably gonna be all out.
That's why, and a lot of people that's implementing this technology into organizations, they're not thinking like that. Y- and me I believe in having a fallback.
Matt: There's
David: it's just like driving a car with a spare tire.
Matt: Yeah, no, so that's yeah, these are great examples because people don't think about it. They don't think about it. It's there's this, this overwhelming sense that a lot of AI tools are just kinda like these magic fix-it buttons. And it helps. It does create a lot of better throughput.
It creates a lot of better outcomes. There's all kinds of things that it does, but nobody has that plan. You-- Y- let's say somebody has had to take that step back, and they did have a good contingency plan. You make a very important distinction here that a restart with a program is a fresh acceptance decision.
It's not a vendor system, or it's not a vendor saying the system is back up. We, we all come from, "Hey, it's downtime," or scheduled maintenance or this or that. This-- It's a fresh decision to say, "Okay, we've fixed it." Why does that distinction matter so much? Because that's very different than a software or ERP system that's just like an off-the-shelf tool or something like that.
[00:22:00] But you make a really good distinctive point about this.
David: One, one thing, Matt, because there's a difference between technical av- availability and operational readiness, and I think that's something people need to understand as well. Because a vendor can say, "Hey, the system is working again," because I had it happen to me. All of these are things that happened to me here recently, and you'd be like, "Okay, the application is online.
The servers are running. The model is responding." But that doesn't automatically mean that the operation is ready to rely on it again. Because when I started relying on it, guess what happened? It went back down.
You need to understand what happened. Why did the system fail? Was the problem corrected?
Was any data affected? Because sometime it does affect your data and things like that. What happened to the work that was processed during the op- or during the outage? Or are there outstanding issues that need to be reconciled? And have we verified that the system is performing the way it's supposed to?
Those are the kinds of questions that should be answered before restoring AI to critical workflows, because technology being available doesn't mean [00:23:00] it automatically is acceptable for operational use, and that's really the principle behind reversible AI. You need to control. You need a controlled way to introduce the technology, a controlled way to remove it if necessary, and a controlled way to bring it back in.
You just don't go all the way in
Matt: Right. Really well said and a really good point of that because people are... it's the craziest thing. I've seen people just willing to go all in on something that, it's it has the ability to make decisions for you. You are directing this traffic a little bit, and people don't realize it's feeding off of what you're giving it.
And so if you're not ki- able to roll that back or rein it in I wouldn't make any jokes about like Skynet or anything right now. It's not gonna become self-aware, but it'll definitely ruin your day. That's for sure. That's the really great point and something that's very distinct.
Let's talk about from, from pilot to the plant floor and some of the bigger picture, and let's talk about Prodigy IQ a little bit. You built an AI-assisted defect and corrective action MVP, presented it and on manufacturing quality at the AIAG Quality Summit. What did building it teach you that the [00:24:00] conference slides don't?
David: One thing it taught me is that there's a big difference between talking about an AI solution and actually building the workflow around it. Because when you're presenting an idea, it's easy to focus on the exciting parts. You talk about what AI can detect, you talk about what it can predict, or you talk about all the possibilities.
But when you actually start developing a system, you have to answer some very practical questions. What happens when the data is incomplete? What happens when AI makes a recommendation that's incorrect? Who approves the action? What happens when somebody doesn't respond? And how do we track whether the problem was actually resolved?
And for me, those questions were just as important as the AI capability itself. And because having worked in manufacturing, I understand that a plant isn't a controlled demonstration. You have, you, you got changing conditions, you got people, you got production schedules, you got quality requirements, and you got real consequences when things go wrong.
So the system has to account for that. And that's one thing I really [00:25:00] wanted to bring into the way I think about technology. Not just whether we can build something intelligent, but asking whether we can build something that fits the realities of the operation, because that's what's gonna sell.
That's what's gonna help companies move forward w- and advance in production and quality. I read the NTSB the National Highway Transportation Safety. I get emails from them every day, and it's crazy because I get emails to see where the recall's at. And what I do is I find out where the recall's at, and I research the, that company, and I track down who the supplier is, and I try to reach out to the supplier.
Matt: Yeah. Yeah. No, that's don't give away any good tips here. We're both k- on the commercial side for our businesses. That's actually a really great freebie there for anybody who's listening. You took away the free advice section of the show. We'll get two out of you for that one, but that's, that, that's great.
One thing that, that stood, it- when we met for the first time you talked a little bit about an operating code, that you had an operating code, right? And v- we talked [00:26:00] about entrepreneurs that are great at a trade. A trade is a great example of this. The, the HVAC guy who's running his own business, a small machine shop, they're not necessarily running systems.
They're really good at what they do, but they're not running systems. And your podcast and your kind of your operating code in general is built on the idea that everything has that code. Where should that person start if they're thinking about it through the framework that, that talk...
And please tell us a little bit more about it, 'cause I thought it was a, a great framework.
David: The thing is Matt, I think this applies to business of all sizes, to be honest, because you don't have to be a manufacturer with a huge budget to start improving your operations. Let's say, like you said, a small HVAC company. You're excellent at what you do. You understand the technical side of work, but now your company starts growing.
You got more customers, you got more technicians out in the field, you got appointments, service requests, estimates, invoice, and follow-up, and suddenly everything is running through the owner. Every decision, every question, every problem, and that becomes a [00:27:00] bottleneck. Now, a lot of people might say let's implement AI."
But my question is, have you ev- actually defined how the work is supposed to happen? Let's start there. How does your customer request come into the business? Who's responsible for responding? And how do you schedule the work? How do we know the job is complete? And how, and what happens if something goes wrong?
See, those are the things that I look at when I'm looking at a business when it comes to AI. And that operating code, everybody every, every organization has an operating code, whether you're an entrepreneur, like you said, or organization, or even a family person, because you're gonna have to have its business, its technology, its system, and life.
Those four things right there. And when you look at that code, if you-- even if you an employee, you still got a business because you're selling time, just like the business owner buying time, and you're using technology. That technology is connected to a system, processes, and it's life, those things that are tangible and intangible.
So when I design software I design anything, [00:28:00] I don't just think about the tangible things. I think about the intangibles as well, because I think about, how does this technology affect that person when he go home, he or she? Because I've seen so many families broken up because of problems that I saw in manufacturing companies.
And they spend more time at the plant than they spend at home. Because even if they at home, they mind is still at the plant, and they emotionally unavailable. So that operating code, that is my heartbeat
Matt: That's it needs to be said more often. People think about this pretty loosely, but I think you've packaged it all together in a way that, you don't think about the effect that it-- you have on employees and other members of your team when you just roll something out and it's not listening, it's not doing what it's supposed to do, but it looks great and it's providing, especially in AI with some of the graphics and things that come out now.
I get-- I can generate a report that looks, it looks fantastic. It looks like I had a consulting firm put it together. I won't say which one 'cause I, I'm not, particularly a fan of, of-- a fan of many of the operations consulting firms. But it looks great. It looks like you paid a lot of money for it, but at the end of the [00:29:00] day, it's like the data's not even validated, and so it's caused more headaches and it's caused more problems.
So people gotta take a little, I, I think, a nice balance of ownership to allow you to have the space to run that operating code across the full spectrum. So this kinda comes to the part of the podcast where we ask for the free advice, although we kinda got one, but I'm gonna ca-cash in this ticket here too.
If a plant leader listening wants to move one AI-assisted workflow from pilot to accountable execution over the next 30 days, what's the one thing they should do if they're sitting there thinking about it and they wanna do this within the next month?
David: One thing that I would tell them, Matt, is I would tell them to pick one fo- workflow. And when you pick this one workflow, follow it from beginning to end. And really follow it. Don't just look at a dashboard. Don't just review the AI tool. Look at what actually happened when the system identifies something that requires action.
Look at who receives it, who validates it, who makes the decision, who performs the work, and who verifies the outcome. Because I think when leaders start asking those questions, they begin seeing gaps [00:30:00] they didn't see even-- they didn't even realize were there. So during the first week, I would document that process.
During the second week, I would identify what responsibilities and decision-making authority may be unclear. And during the third week, I would test it. What happens when the recommendation is wrong? What happen when the s- when somebody doesn't respond? What happens when the technology becomes unavailable?
And during that fir- fourth week, I would evaluate what we've learned and determine what needs to be improved. Because you don't necessarily need to overhaul the entire organization to begin making progress. Sometimes fixing one critical workflow can teach you a tremendous amount about how the business really operate.
And once you've got that process working effectively, you can use that lesson to improve other areas of the organization. And I think that's the biggest thing I want people to understand in this. AI is going to continue to get smarter, but the technology is going to continue improving. But technology alone isn't the, isn't what makes the organization successful.
It's how the organization [00:31:00] uses technology, how the people make decisions. It's how work get done, and it's how leaders hold the operations accountable for results. Because at the end of the day, the goal isn't just to build an intelligent business. The goal is to build a business that operate intelligent
Matt: Very well said. For all of you listening, that was the probably most direct manufacturing and military crossover answer I think we've probably ever had on the show because, it's document, prove the process, talk through the steps, put it on paper, do the things that line everything up to see every point of failure instead of just saying this is how we do it, so let's just automate it."
That's you get a lot of that in manufacturing sometimes and, so just go back to first principles there and document it, write it down. What's so a li- a little bit about your company David, the Prodigy IQ. Where can people go to find you? What are you up to next?
I know this is something you just launched, and tell us a little bit, if you don't mind, about your podcast, "The Operating Code."
David: You can find me I got a website davidacraig.com. You can find me there. You can find me on LinkedIn at David A. [00:32:00] Craig. You can also find me on X @davidacraig. But "The Operating Code," man, it's where-- It's like I explore the systems and principles behind people in organizations, how they work.
And, I got some episodes that's coming. One of them is called "Why Businesses Isn't Built to Operate." Because a lot of companies they're not built to operate. And they wanna bring AI into something that's not-- into a place that is not ready. And I tell a lot of companies that contact me for AI, I tell them, "Before I sell you AI, I'm gonna look at your processes."
I will not sell businesses technology if I haven't looked at their systems, how they work and things like that. Because s- technology with no systems is chaos waiting to happen. So we're spending a lot of time talking about how intelligent AI is becoming, but I think we need to spend just as much time telling about how intelligent our operation, our organizations can operate.
And that's where the really, [00:33:00] the opportunity at. "The Operating Code," it bridges that. It bridges the gap between business, technology, systems, and life. Because without life, the code is broken. But we got to have business, systems, and technology to get to the life part
Matt: Yeah. No, it's it's a good balance, and it's something that-- Good point. What's it all for if there's not life, but all the other stuff is the fun things we do every day? So David, thank you for coming on "US Manufacturing" today. This has been a great conversation, and we'll be sure to link all that in the comments when we do these posts on socials.
But really enjoyed the conversation, and thanks for joining us. To stay ahead of the curve and to help plan your strategy, please check out our website and under the resources section titled Trump 2.0, where you can see the framework around upcoming policies from the administration and how they will impact you as a manufacturer.
If you're on socials, give us a follow on LinkedIn, X, or Instagram. And if you are enjoying the podcast, please feel free to follow the show on Apple Podcasts, Spotify, or YouTube and leave us a rating, and don't forget to subscribe. Thank you again for joining us [00:42:00] and learning more about how you can make your way.