The Cracks Between Good Designs, with Mike Fedorov (A Chat with Cross-Functional Experts)

Why do well-designed initiatives keep coming apart when they reach reality? 

Mike Fedorov, who spent 26 years in supply chain and operations at Mars and Accenture and now co-leads Applied AI Labs, explains that the failure usually isn’t a bad call inside a single design. It’s the coordination layer: the seams between teams, systems, and the data that no one remembers how to work. 

He walks through a transformation that stalled for months, what AI can actually do to close the gap, and the habits separating the AI programs that work from the 95% that quietly fail.

 Highlights

• The coordination layer is where modern design fails, not inside the design. The handoffs, systems, and data in the spaces between teams accumulate more opportunities to break than the parts themselves.
• The data is always a little wrong. Design for that. Waiting for perfect data is waiting forever; build systems that detect, tolerate, or self-correct small errors instead.
• AI doesn’t make the call; it should make the call obvious. AI’s job is to watch the data, connect the dots, and put the two or three important things in front of a human who decides.
• Mike's three rules that work when implementing AI for the coordination layer.

Visit the podcast blog for a special infographic from Mike.

Work with Dianna I help product development teams build quality into the front end when it's cheap and easy, not late when it's expensive and painful. 

Book a 20-minute discovery call with Dianna's calendar. Whether you're navigating the "fuzzy front end" of product development and want to explore a workshop or advisory partnership, or you'd like to be a guest on this podcast. You'll leave with a summary, relevant resources, and a clear path for next steps within 24 hours. 

Pierce the Design Fog (piercethedesignfog.com): my book on aligning cross-functional teams, defining clear design inputs, and accelerating product success. NIEA Finalist Award, reviewed by PDMA. "Great for fans of Tony Fadell’s Build, David H. DeWolf and Jessica S. Hall’s The Product Mindset."-BookLife Reviews (Publishers Weekly)

Connect with me: I'm most active on LinkedIn. 

Free Resources for Subscribers Subscribe to the Quality during Design digest — https://newsletter.deeneyenterprises.com — for monthly actionable highlights, plus access to the Strategic Quality Integration Checklist (a free self-assessment download) and my Swipe File Vault.

Transcript

Copy Transcript Copied

Designs That Still Fail

Dianna 0:00

Welcome to the Quality during Design podcast. Our designs can be technically perfect and still be wrong where it matters. Sometimes the failure is not inside the thing that we're designing. Oftentimes, it's in the cracks between the interfaces, between the teams on either side of a handoff, between the data fields someone set up a decade ago that nobody remembers how to work. We don't find those cracks on paper. We usually find them in the last mile when a transformation that was carefully designed stalls over months and someone up and down the line is asking why. Today we're asking what that gap tells us about design itself and what AI can genuinely do to protect it, I want to tell you more about today's guest, Mike Federov, after the brief introduction.

Meet Mike Fedorov

Dianna 1:32

Mike Fedoroff spent 26 years in supply chain and operations, including 15 years at Mars and 10 years with Accenture. He's helped companies navigate operational challenges and transform complex supply chains while staying closely connected to the realities of day-to-day operations. Today, he's co-CEO of Applied AI Labs, where he leads using AI to help mid-market companies quickly improve performance without overwhelming their teams. Today, Mike and I talk about why the failure so often isn't in the thing itself being designed. It's in the cracks between the handoffs that no one owns, the data that no one remembers, and what AI can actually do about those, preparing decisions and closing the feedback loop between design and operations

A Transformation Derails

Dianna 2:31

you have a lot of experience in operations, and you've watched design decisions play out in the real world. I want to ask you if you could walk us through a time where a design decision looked solid on paper but became an operational nightmare, and what was the gap between what was assumed and what actually happened?

Mike 2:55

Dianna, I have plenty of those, but I think the best ones are the latest ones. imagine a year ago, me leading a transformation program for a, a major client. they were looking forward to acknowledging hundreds of millions of value out of that. We have designed things very, very well. We have put a whole year into designing the data flows, the processes, what you can imagine. And then imagine us in the final mile, in the last mile of that transformation, when everything should be working, and then boom, that data just doesn't match between part A and part B. It doesn't match slightly by one, maybe one point two percent, but it doesn't match. And what does it mean? It's like the, the airliner. It cannot be landing in ninety-nine percent of times. It needs to be a hundred percent. In our case, we could tolerate the difference of point one percent, ideally one-hundredth of one percent.

The Hidden Master Data

Mike 3:58

We spent months, we spent months trying to find out where was that bug, where was that issue? And eventually we found it. What we found is that the design was perfectly fine. Every single interface was designed correctly. The master data between two different systems, a teeny speck of master data, was something that was designed fifteen years ago and was misunderstood because nobody knew how it was supposed to work. It caused a major delay in the project that was looked at that point of time by the C-level officers of the top one hundred company. So this is where the design work was done great. We felt good. And then at the end of the day, we delayed the realization of hundreds of millions of dollars by months because of that thing

Dianna 4:50

I was going to ask you how long it took you to find the root cause of that

Mike 4:55

It took us about two months of delay, let me put it this way. The full cycle of finding it early and starting to look at that, it took about eight months. But two months was real, a real tangible, palpable delay to the program

Dianna 5:13

Yeah. And I would imagine that the team would first look to what was designed that was new and not really think about the thing that's been existing for a long time and just chugging along

Mike 5:26

Let me tell you this, it wasn't even that. The team was after first four weeks probably, the team was very comprehensive. It was looking at every single piece, old, new, imaginary, real.

Cracks Between Interfaces

Mike 5:39

What they didn't realize are the cracks between the design elements. So on that, that from my experience, it's actually a persistent pattern. It's not that people are doing bad calls on the design of a specific thing. People tend to, uh, drop the ball on the cracks between the right things

Dianna 6:06

Now my reliability engineering friends would focus on the interfaces of a system. Are these the same kind of cracks that you're talking about,

Mike 6:16

Absolutely, but I would, uh, put it in a more extended way. Don't think just technology systems application A, application B. It's the same exact thing between the processes, between the people, between the teams. So all of them, to me, are the same design things. When you think about your organization, you design your organization as the teams, as what this team is doing, what that team is doing, who owns this and that, that's design. When you think about the work processes, it's the same reliability of the design as when you design an airliner or a car or whatever else, a computer. thing

Dianna 6:56

So you're seeing, um, not just the interfaces of a system that an engineering team is designing, but also the operational part of the, the data on the back end, um, the information flow between the teams. Also those sort of interfaces you've seen cause a lot of problems?

Mike 7:18

You got it precisely right. Let me put it even a better way.

The Coordination Layer

Mike 7:23

Think this way. Perhaps 20 years ago, I started figuring out that infrequently people are making wrong calls. Infrequently, uh, the designs are wrong on the level of a product. Increasingly, the designs are wrong between the products, say between engineering and manufacturing, between planning and execution. So that is where I'm seeing where things start getting wrong much more frequently than inside the, the object, inside the thing, inside the product or team. And that is what I explained for myself as the coordination layer. That is, things are happening increasingly wrong in the coordination between designs, things, processes, teams than inside them

Dianna 8:18

Has, has the consistency within the team, like the, the number of errors, is that stayed the same or has that gotten better? And I'm wondering how it all layers on top of each other. If they're getting better at doing the thing they do, but then the interfaces break down, and so we're left with an even bigger gap

Mike 8:41

That's a great question. I suppose I might be not very objective on that because I did my best to work in the best teams through my life, and I think I got a bit better with the pass of time in that. So in my personal experience, I have clearly seen fewer and fewer mistakes are done inside the teams. But that might be biased. That might be just because I was lucky to work for better teams. I think so. I think though that, uh, a part of that is just the technology. Technology understanding. Some people who are experienced enough tend to complain that, uh, today's school boys and girls might be not as comprehensive as the ones in 1960s or 1980s. I don't believe so. I think that people are actually studying well, and I think, uh, the new generation is coming well prepared. I don't think people becoming worse. I think people become-- are becoming better. Technologies are becoming better. We're having more tools. So I think my observation of better result, uh, results inside the teams are not that biased. I think that's the case

Dianna 9:55

Hmm.

Why Gaps Keep Growing

Dianna 9:57

So then it's between the teams. So it's not only during development you're seeing this problem, but then also in operations and the execution of it. what are some of the causes of these, these gaps? I've seen in the work that I do that sometimes it's a silo effect where teams are just kind of working on their part and then they get it done and they toss it over the wall to the next team to take on. But I've talked with other people that talk about timing problems. So I'm sure from your operations experience you have a little deeper insight into that

Mike 10:36

I think first of all, you're absolutely right. Uh, when we encounter issues, our normal first instinct is to run the root cause analysis. And I increasingly see the root cause analysis completed based on the reflections is that ultimately it's the, uh, passing between one team and the other, as you say, over the fence. It's the timing, or I would call it rushing through the things, and it's the data. Uh, data is guilty almost always because the data is always wrong. However, my personal observation is that these three are right, but those are not the deepest reasons. I think that these are just manifestations of the deeper layer of the understanding of how we can-- what we can apply to this. Think this way, why are they happening? Why are th- why are they happening? Why are the data faults or rushing through the things or the handover problems, uh, happen more and more frequently? My understanding is that this is really a coordination problem, a problem of the individual systems, teams, uh, solutions, products are becoming more and more sophisticated, flawless, complex, and then we become organizations where we've got just more things, more customers, more business lines, more transactions. So what becomes a more problematic piece is the connection between the things, and that's what I call a coordination problem. That is how your increasingly good components are connected in increasingly large number, which creates an increasing coordination problem. So think about this. What does it mean that my team was passing a thing to another team over the fence and it didn't hand over well? Well, they didn't really have time to think about it. They didn't have the design for this process. They didn't have the clarity of how to structure it, which data fields, if you will, to pass correctly, to delegate it, not to dump it on the other team. So to me, it boils down structurally, existentially to how to create better coordination between the teams, problems, objects, products

Why Data Is Always Wrong

Dianna 13:14

Now you said in all of these examples, you look at it as the data is always wrong. Can you explain a little bit more about that?

Mike 13:24

This is an interesting problem of today's day as we are working with more and more data. Data becomes the lifeblood. It becomes the critical factor of success. And, uh, most of the processes have been designed in essentially last, last decade, if not last century paradigm, where things are rigid. There is a formula connecting A and B to C. A multiplied by B equals C. So if A is wrong or B is wrong, then C is inevitably wrong. That means that, uh, if, if you have a, uh, one data piece wrong in a million points data set, it means that your data set is technically wrong. So increasingly, what we have is that the systems are designed in the paradigm where you have five, maybe ten, maybe fifteen pieces of data, which clearly people can make sure that they are right. And they, they process to the next stage, and they are still right. But the reality is that there are ten billion pieces of data, and nobody can even understand how many of them are right. And then with a few mistakes, a few points where the operator typed an extra zero, things happen like that, I've seen that, where a piece of data is missing, a piece of data is coming from a system during the outage. And increasingly people call it wrong data, just collectively wrong data. And then when you design the processes to rely on correct data, the processes give you a wrong result. So that is what I address as the real design problem. When people don't design for resiliency, people don't design for self-correction in working with the data that always imperfect

Dianna 15:31

And that seems like it would bleed over into the coordination problems. If one team is creating the data plan or has data that they're trying to pass on to the next one that if there's errors or if the plan isn't robust, then that could compound some of the problems that are seen

Mike 15:52

That's the real reason in an increasing number, from my perspective, of the data inconsistencies. Each individual process is normally fine or it's fixed quickly. The problem is when you got 10 processes coordinated with each other or collaborating with each other, and when, uh, you have moving pieces. The more moving pieces you have, the more opportunities it is for a mistake. Moving pieces means one system is down for a few seconds, or the operator is, uh, uh, just distracted, or the keyboard is hitting a key twice and not hitting key once. So all these pieces, when you have so many uh, dimension of freedom in the system, something will go wrong from time to time. So the right design decision to me is to acknowledge this, not to demand that the data is corrected first and then you do something. But to design a system where minor inconsistency in the data is either not affecting the result or it's automatically corrected or it's automatically detected

Designing for Resiliency

Dianna 16:58

So how would the people that are working on the design aspect of it what are things that they can do or what's a ideal target that they'd want to try to work toward to address some of these problems?

Mike 17:15

From my perspective, there is a simple answer that is not very helpful, and there is a complex answer that is more helpful, but requires more brain to, to implement. The simple answer is what I shared before, like, hey, design for resiliency. It's easy to say. It's hard to do because, say, if you are talking about the transactional system for a bank, what does it mean resiliency? If my transaction is wrong, if $1,000 is lost, the whole thing, the whole ledger is off. The real answer to that is that, uh, it needs to be, uh, an information flow back and forth. It needs to be quick turnaround between what you see in the-- on the design phase and what you see in the, in the outcome, in the output of the solution. So operations and design, that's old paradigm of, hey, these are two different sides of the house. Your design does something, takes some time to design, takes some time to implement, then toss it over the fence to the operation, the operations live with that. And then occasionally, maybe once per year in the past times, uh, maybe once a month or even once a week in the most, uh, nimble organizations today, there is a feedback session where something is, is coming from the operations team back to the design, "Hey, guys, it doesn't seem to work. Fix this." That's a bug report. Needs to be-- That, that is where the right answer is, in my opinion. This is where this coordination... Again, sorry I keep, keep using this word because I believe that this is the problem. This coordination back and forth needs to be accelerated. Needs to be accelerated not two times, not by five percent, but twenty times, a hundred times. This is where today's technology allows us not to rely on the paper that you file, and then eventually it makes for the courier to, to the other side of the continent next month, right? Back in the Founding Fathers' days. It is much faster. Not just it's an email. It's really not a point of how fast you can pass a bit of the token of documentation.

AI Prepares Decisions

Mike 19:38

The real difference is how fast it can be aggregated, looked at, made sense of, and this is where the artificial intelligence technologies are the best. That is, think about this, people are still thinking like some magical thoughts about that, "Oh, this will replace people. This will, uh, make decisions for us." Where AI really shines is not making decisions. Where it shines, it's preparing decisions Think this way, how to collate thousand pieces of data, make sense of them, highlight what is looking fishy, uh, connect the dots between the things, and prepare what's important. With three most important things on the top, and then a tail, a long tail of the things that can be looked at. That is what, uh, where AI shines, and then a person would be making a call. So back in our conversation of, so how do you make this faster to identify the issues and pass them to the design team? That's exactly the example of that coordination. That's where-- Imagine, just imagine that instead of people noticing all the mistakes, what if your data congruency on the back end is watched at, and on the front end is also watched at, uh, by, by the, uh, by the agent? What if your data comparisons between the, the left and right are done not once in a month or when, when the boss really insists on that? But what if they are done every morning and every afternoon? And then the agent that has the patience and the rigor to do this understands what is inconsistent, highlights the priority, and sends it to the development team within a minute. That is where the, the design can be very different, can, can be very different equation between the design and the operations

Why Enterprise AI Fails

Dianna 21:47

Is this the kind of AI use that you're actually seeing work today?

Mike 21:53

No, but this is what we are doing right now. This is where my firm belief is that this is exactly where about 95% of AI projects were essentially failing last year People in general are still figuring out what to do. So what I am seeing is that increasingly people understand that AI has value. Everybody's curious. Everybody wants to figure out how to capture that value. What I see people doing is not exactly the right thing. Oftentimes people are catching shiny things first. People are looking at the question of, "I have AI, how do I use it?" People are asking themselves like, "Hey, do I need to fix data first?" All these questions in my view are secondary. What I found to be working so far is when you ask yourself the right question, set of questions, then you'll start getting to the exact design decisions that we've talked about the last few minutes

Dianna 23:04

So you're approaching AI use from the point of fixing these collaboration issues?

Mike 23:13

Let me be honest with that. There are multiple cases of AI use. I am not in-insisting that the coordination layer is most important. I'm just noticing that you can think about the enterprise, big or small, mom-and-pop store to a mega company of the world, as a combination of two things: the solutions and interfaces, processes and coordination. Two paradigms. My thought is that products, many products, many solutions benefit from AI, and that's the point to point. So many companies are busy with that, happily busy with that, and create value. Now, when it comes to the company itself, to the client company, to the company that's taking advantage of the technology in the business, uh, they are increasingly, uh, either consuming those products, so say implementing SAP, implementing Microsoft Copilot, and that goes as a success most of the times. When companies are, uh, using AI as a part of the technology that they are implementing, that works just fine Increasingly, companies are trying to embed the AI layer on the top of that, saying, "Okay, we've got SAP, Microsoft, Oracle, a few other technologies. We've got our client database here, uh, the CRM. We've got our process. Let's create an, an artificial intelligence layer on the top of that that would help us in our business processes, in the core business process." And that is what's failing. And that is where I am suggesting that other than the individual products, when we are talking about the enterprise AI layer, whether it's a big enterprise or a relatively small company, anything in between, that is where coordination is the right terminology. That's the right paradigm to think about it.

Three Rules for AI Wins

Mike 25:23

And that's where people should be following, I'd say, three simple rules. First, to define the problem right. Not to start with where I can use my AI in my company, to start with the problem, what are the pains? Those pains, the best place to find those pains other than individual products is where are my coordination pains? Where the handover is going wrong? Where the cross-functional doesn't work smoothly? Where am I losing money? So if people ask themselves the right questions, where I'm lo-- where am I losing sleep? Where I'm losing money? They get the right application point for that coordination layer for the, for that AI. Second people need to stop thinking about that, oh, data is just fine. But they need to stop thinking, uh, as well, "Hey, we, we will not do anything until the data is fine." The data is always wrong. It has been, it will be. It will take infinite amount of time to get the data a hundred percent right. So it's not practical, not pragmatic to think this way. But it's not pragmatic to, uh, to not acknowledge that the data is a part of that equation. So whatever we develop to fix the coordination layer, we need to make sure that this is robust and this is resilient to data being imprecise. is the real solution. And fortunately, AI is pretty good at that. AI doesn't require for those coordination problems, doesn't require the precise data. It can work with imperfect data, so long as you train it And the third piece, third important piece is that people tend to start the biggest bang, like, go big or go home mentality. And that's not the h- most helpful mentality in this game. The most helpful mentality is to be modest, to be humble. To say, "Hey, why don't we first figure out how to crawl, then figure out how to walk, then figure out how to run, then go to Olympics?" Not go to Olympics first. So this is where the best way is to go back to the idea, identify where the pain points are, find one or two of those pain points that are easy, the easiest ones, the things that you can do, you can fix in a day or two. It will take you a week or two, maybe a month to fix them. But at least instead of a day or two, it will take you a month. It won't take you twenty, ten years. Ninety-five percent of the projects that were failing last year, this is exactly where people are just losing patience. One year, two years, three years from the start, it's not showing any tangible result. That's where people lose patience

Dianna 28:22

that's a high percentage of AI projects that you're seeing had failed. the three ways to look at enterprise AI in order to do it right, is identifying the problem or pain, um, not waiting until the data is done well, but making sure your system is resilient, and then try it in a modest and humble way on something small so you can take steps to learn AI. And you've seen companies be more successful with that approach with their enterprise AI projects?

Mike 28:59

Absolutely. That's where the remaining, percents are. that was last year's ninety-five percent by MIT project that was looking into the success rate. This year there were a few, a few better data points that were looking exactly at that. Uh, if I remember correctly, about, uh, eighty percent of medium-sized companies, the leaders of those companies, uh, they were quite happy with the first fruit of the AI implementation, and most of them were very simple and humble. They would be saying, "Hey, my-- say my Microsoft Copilot or my Gemini is actually helpful." Simple things, give it to people, explain to people, train people of how to get basic cases out of that, and boom, your productivity grows. Also, it was showing that, the majority of those companies couldn't tackle the real business problems yet, but still they got some value. They got some value in the first year. So they got the encouragement, they got the money to reinvest in the second stage, third stage. To me, that is precious

Dianna 30:13

Now, just to go back a little bit, uh, because you framed AI use in a way that I liked, which is preparing decisions. So if the AI is being used to prepare decisions, um, how is it best for the human decisions to get involved? How often or i- is there a critical point that's easy to identify where human involvement in the decisions is needed?

Mike 30:44

The way how I see it is very pragmatic. That is, AI is the best to summarize the data, to make sense out of that, to prepare it, to prioritize, to recommend. But AI is not good at making decisions, choosing the options making trade-offs, negotiating trade-offs. So these are the things that, in my view, would remain human for years ahead. Human beings have the will. Human beings have judgment. Human beings can be thinking outside of the box about different solutions, and human being, beings are needed to negotiate with other human beings. So the way how I'm seeing it, uh, it's a wrong dichotomy whether AI or human is better in making decisions. In my view, human with AI is better in making decisions. Or if you will, the way how I've seen it eloquently said in the last year, it's not that AI will beat the person. A person with AI will handily beat the person without AI in most of the professions, in most of the lines of business

Dianna 32:05

And that seems like it would hold true for operations also

Mike 32:10

Absolutely. Yeah, well, operations is a big area, uh, but all the s- all the areas, all the functions, uh, within, within operations and all the industries I can think about, that is exactly the case. What we need is not to replace people with AI. What we need is to amplify people with AI so that they become much more effective, so that the outcomes become bigger. Typically, in most of the industries, uh, leave consulting alone for a bit. In most of the real industries the headcount is a teeny fraction of the total value created, and the total loss is not the headcount. The total loss is the leakage of value, the, the inventory that is lost, the transportation that is not going the right direction, the product that is broken, that is returned. That is where a few percent of typical companies EBITDA is lost not the headcount. Furthermore, something that in the newest reports from this year amplifies this point of view. I mean, this is my vision, but Mike's vision can be incorrect, of course. What I am seeing in the reality in the reports is that out of the companies that were successful in applying AI, uh, the trend is to increase the headcount. So, uh, the reality, the fear is that AI will replace people and we'll have unemployment and people will go nowhere. The reality is that companies that implement AI successfully add to their headcount, and they add to their profits sensibly too. I believe the results I was looking at yesterday, it was something about, uh, six percent growth for an average company versus twelve percent for the companies that were successful implementing AI, and bigger headcount and better growth. That's, I think, what we're talking about. The game is not about, uh, kicking out people. The game is kicking out the inefficiencies that are created by just lack of something else. And in my view, it's really coordination So improve coordination, keep people, make the business better

Dianna 34:35

So if there is a engineering leader or a quality leader at an organization and they're a little bit skeptical or unsure of what their first steps should be what would you recommend to them to do? in order to decide how AI can work for them?

Mike 34:58

First thing I would like to address the skepticism. Uh, skepticism is-- can be of two kinds. Can be of the kind, well, I don't think it's gonna work to begin with, and skepticism, I don't think I, I am able to start this right. So skepticism of the first kind, I don't think that it's gonna work, just think the opposite way. Mathematicians call it proving from the opposite. Think how unwise it would be to ignore the technology that is very promising. Think about how unwise it would be to start with the wrong paradigm, with the wrong framework, that is not doing those simple, clear things that we've been talking about. That doesn't sound right if you think about, well, let me stick to those, those ways of working. So I think the first part of this conundrum is solved pretty easily. Think from the opposite, and you would see that doing something right with this technology is a great idea. And now the second part: What if I cannot do it right? That is relatively easy to solve. Start with the no regret steps. Start simple, start humble. Think this way: Identify a few points with the help of consultants, doesn't matter. Identify a few points where a small, relatively small problem causes a lot of pain. Define pain in either of two tangible ways: The money that I lose or the time that I lose. Those are real tangible pains. Define those pains, then understand of the pains that you have defined, which ones are easy. Easy in the sense which ones are obvious that you can fix them with the technology, and do this. Don't try to get major things done. Don't try moonshots. Don't try go big or go home. Fix one thing at a time, one simplest thing you can do at a time. That is a no regrets step that will boost the confidence or prove it, I should say. And that would create the first wins that will give you money to do the second wins, third wins, fourth wins. So to me, that, that is the frame of thinking that convinces the skeptics that, A, it should be done, B, I can do it

Dianna 37:40

Very good. Mike, is there somewhere that listeners can reach you if they have any follow-up questions or

Mike 37:49

Absolutely. I love discussing things. For one thing that, uh, I need to learn a broader market and for me discussing the problems, discussing the ideas, solutions with new people is one of the ways how I grow as well. So easiest way to find me is on LinkedIn to go for Mike Fedorov, uh, Applied AI Labs, you'll find me immediately. Or you can just drop me an email at my email address, mike@aalc.ai, either way will work

Dianna 38:25

That sounds great. Thanks for joining us today on the show. You provided a lot of insight and broke down a very complicated project problem that we're all handling. You broke it down very clearly,

Wrap Up and Next Steps

Dianna 38:38

so I appreciate that. Thank you

Mike 38:40

Thank you, Dianna. The breakdowns that Mike and I talked about came from what lives between design decisions. It's the handoff with no design of its own, the data that's always a little bit wrong, the coordination between teams that keeps getting more complicated because the teams themselves keep getting bigger. That's Mike's coordination layer, and once you see it, you start to notice it everywhere. The reason it matters for AI is not that AI makes the decisions, it's that AI prepares them. In Mike's picture, an agent can watch the data every morning and every afternoon, front and back, surface what looks off, and hand the team something useful in minutes instead of letting it surface months later it's the feedback loop between operations and design, and that he'd tell you, is where going fast actually counts. This is the approach Mike is building toward, and the humble "start small" path is how you get there without losing your nerve. So here's your Monday morning move. Pick one handover where you're quietly losing money or time and just watch it for a week. You don't need to fix it yet. Just notice where the data comes from, what each side assumes, and what breaks. That one observation is the seed of a humble pilot that can actually work. If this conversation was useful, the best way to keep it going is to subscribe and share it with a design or operations leader who's skeptical but curious. You'll find Mike on LinkedIn and at Applied AI Labs, and you can sign up for my monthly newsletter at newsletter.deeneyenterprises.com. It's out the first Friday of every month. This has been a production of Deeney Enterprises. Thanks for listening