Every leader has done it at least once: read about how an admired company works, and tried to install the same thing back home. New team names, new rituals, new tooling — and six months later, nothing has actually changed. On today's debut episode of The Focal Point, host Filiberto De La Cruz chats with Beau Sprig, CIO of regional grocery chain Marlowe & Finch Grocers, about why borrowed practices so rarely survive the trip.
Beau calls it the difference between the flower and the root system. He walks through the questions he now asks before importing anyone else's operating model — what problem was this actually solving, what is our current process quietly compensating for, and what capability would we need to build before the practice could possibly work here.
Episode Video
About the Guest
Beau Sprig is Chief Information Officer at Marlowe & Finch Grocers, a 140-store regional grocer known for a short supply chain and an unusually stubborn refusal to copy its larger competitors. He joined in 2016 to modernize a fragmented store systems estate and spent his first two years deliberately not replacing anything — mapping instead what each creaky process was compensating for before touching it.
Earlier in his career Beau led distribution technology at Halverd Foods and ran the store operations platform at Cobbleway Markets, where he watched two expensive "best practice" transformations stall for reasons nobody had diagnosed up front. Those experiences shaped his conviction that a copied practice is a hypothesis, not a prescription.
He mentors technology leaders through the Ledgerfield Retail Technology Forum and holds a B.S. in industrial engineering from Ashmoor State University.
Transcript
The practice-transfer problem
This is the Focal Point Podcast, an ongoing series where we deep dive into the meat of messy management. Whether it's technology, business, government, or entertainment, we chat about our experiences and perspectives in life and leadership. Join us as we learn about their latest insights and hopefully inspire you to have some of your own. Here's the scary part. Your transformation can look successful right up until it collapses. Because from the outside everything looks right. >> Exactly. The team has the rituals, the language, the standups, the OKRs, the product squads, the design sprints, the shiny delivery tools, >> the costume. >> The costume, but not the capability. >> That's a little uncomfortable because a lot of organizations do this with totally good intentions.
They look at a high-erforming company and say, "They figured something out. Let's learn from them." >> And that instinct is not wrong. The problem is when learning turns into imitation. When leaders copy the visible practice without understanding the invisible conditions that made the practice work. >> So this episode is about what the article calls the practice transfer problem. >> Right? The belief that high performance can be imported through imitation. >> And the article's argument is pretty sharp. Practices do not travel alone. They are carried by context, strategy, constraints, talent, trust, incentives, architecture, operating history, leadership behavior. >> Which means if you copy the practice without the context, you may inherit the artifact but not the advantage. >> Right? You get the jacket, not the athlete.
>> Okay, let's unpack that because this shows up everywhere. >> Every industry has organizations that become shortorthhand for excellence. tech giants, productled companies, lean manufacturers, elite design shops, high-erforming software teams, >> and leaders study them. >> They study their rituals, tools, team structures, deployment practices, meeting norms, cultural language, decision models. >> And the hope is understandable. If it worked there, maybe it will work here. >> But that's where the trap starts because the visible practice is often the last thing that became visible. >> Wait, say more about that. A practice might look simple from the outside because the organization has already done years of hard work underneath it. Trust has been built. Talent has been developed. Architecture has been cleaned up.
Incentives have been aligned. Leaders have learned how to behave differently. >> So by the time we see the practice, we are seeing the flower, not the root system. >> Exactly. And then another company comes along and says, "Great, we'll install the flower." >> That is such a good image. They copy what is above ground. But capability lives below ground. >> The article starts by saying, "Imitation is a human default. Organizations copy because people copy." >> Yes, benchmarking, case studies, conference talks, executive visits, they all activate the same instinct. Successful groups behave this way. So, we should behave this way too. >> And the article makes an important point here. Imitation is not foolish, >> right? It is one way humans learn. Children imitate, apprentices imitate, teams imitate, leaders imitate. That is normal.
Imitation versus diagnosis
>> The risk begins when imitation outruns diagnosis. >> That's the line. A copied practice should be treated as a hypothesis, not a prescription. >> So, not Spotify has squads, therefore we need squads. >> More like what problem were squads solving in that context. Do we have that same problem? Do we have the conditions that would make that structure useful? What might break if we adopt it here? >> That's a useful distinction. The practice is not the answer. It is a possible experiment. >> Exactly. >> And this is where leaders often get seduced by the external clean story >> because the external story is always simpler than the internal reality. >> A company gives a talk about continuous delivery. And it sounds like the breakthrough was tooling.
But underneath that tooling, there may have been years of test discipline, architecture changes, production ownership, incident learning, and leadership tolerance for smaller, safer releases. >> So if another company just buys the tool, it has not bought the discipline. >> Right? Installing a continuous delivery tool is not the same as learning to release safely. >> That connects to the next section of the article. Direct practice beats passive borrowing. Yes, capability does not transfer because a team adopts another organization's vocabulary. >> So, saying empowered teams does not create empowered teams. >> Exactly. Reading about empowered teams is not the same as moving real decisions closer to the work. >> That's the part leaders usually miss.
>> They think the transformation is happening because the organization has changed its labels. Team names changed, meetings changed, the road map format changed, the operating model deck changed, >> but the underlying behavior may not have changed. >> And behavior changes through practice, local practice in the actual conditions where the team needs the skill. >> Give me an example. >> Take product judgment. A company can adopt design sprints, discovery rituals, customer interview templates, opportunity solution trees, whatever. But if teams are still not allowed to make meaningful tradeoffs, if customer evidence loses to executive preference every time, then they are not practicing product judgment. >> They are practicing performance theater. >> Exactly. They are rehearsing the ceremony but not building the muscle.
>> That reminds me of learning a language by downloading a phrase book. >> Yes, >> you can say the words, but you cannot really converse until you have practiced in the messiness of real conversation. That's the point. Transformation requires local reps, not just knowledge about the practice, but repeated attempts to perform the underlying behavior in the real environment. >> And that is slower, >> much slower, which is why imitation is tempting. It feels like a shortcut, >> but it may only shorten the visible part, >> right? It skips the learning that actually matters. >> The article then brings in Chesterton's fence, and this is one of the most practical parts. Do not remove the fence before you know why it exists.
Understand the existing fence
>> Meaning when organizations import a new practice, they often remove an old process because it looks slow, heavy, or outdated. >> And sometimes it is slow, heavy, and outdated. >> But sometimes it exists for a reason. >> Exactly. Maybe the process is compensating for a trust problem or a regulatory constraint or a skills gap or a brittle system or a past failure nobody wants to repeat. >> So the old practice might be ugly but it might be holding back a real hazard, >> right? It might be a guard rail and if you remove the guard rail without understanding the cliff, you haven't modernized the organization. You've just made it easier to fall. >> That's where copying can become dangerous.
A leader sees a high-erforming company with lightweight governance and says, "We need less governance." >> But maybe that company has strong engineering discipline, high trust, excellent observability, clear ownership, and leaders who actually respond well to bad news. >> Whereas your organization has unclear ownership, fragile systems, low trust, and a long history of punishing failure. >> Exactly. In that environment, removing governance may not create speed. It may create chaos. >> So, this isn't really a metrics problem. >> No, it's a diagnosis problem, >> right? Because the dashboard only shows the smoke, not the wiring inside the walls. >> Yes, the imported practice may make the dashboard look modern, but if the wiring is still faulty, the risk is still there.
So before importing a practice, leaders should ask, "What is our current process compensating for?" >> That's one of the strongest leadership questions in the article >> because it changes the posture from contempt to curiosity. >> Exactly. Instead of saying this old process is dumb, you say, "What problem was this process trying to solve?" >> And once you understand that, you may still remove it. >> Absolutely. Chesterton's fence is not an argument for keeping everything. >> It is an argument for understanding before demolition. >> Yes, remove the fence after you understand the hazard or replace it with something better, but do not confuse the absence of a fence with progress. >> The next move in the article is subtle. Preserve the core, change the practice. >> This is important because the best organizations are not static.
They adapt constantly. But they know what should not be casually copied, diluted or traded away. >> Right? Their practices evolve around a core they underst. >> So the issue is not never copy. It is know what you are protecting while you adapt. >> Exactly. Because an outside observer can see operating practices much more easily than the core purpose. >> You can see the meeting structure. You can see the org chart. You can see the tool chain. But you may not see the principle underneath. You may not see the decision logic, the value system, the trade-offs the organization is willing to make. >> And if you copy the visible practice, you might accidentally import someone else's logic. >> That's the danger. A borrowed practice can quietly replace your own core if you have not named what your core is. >> Give me a concrete version of that.
Imagine an organization that has historically won because of deep domain expertise and long-term customer trust. Then it copies a faster moving product model from a company that wins through rapid experimentation and aggressive market capture. >> The copied practice might not just change how they work. >> It might change what they value >> and not necessarily in a good way. >> Right? Speed might start replacing judgment. Experiments might start replacing responsibility. Local autonomy might start eroding the consistency customers depend on. >> So leaders need to ask which parts of our organization should adapt and which principles should remain stable. >> Yes, that is the transformation question. >> It is like a scaffold. >> Say more. >> A practice can be a scaffold. It helps you build new capability.
But if you forget what you are building, the scaffold can become the building >> or worse, the scaffold becomes the ceiling. >> Exactly. The organization stops growing because it has mistaken the borrowed form for the final goal. >> That's a useful distinction. >> Then the article gets into mimicry and this is probably the deepest failure mode. >> Mimicry misses the culture beneath the practice. The article points to the lean example where organizations copied behaviors they observed at Toyota but missed the culture and values that framed those management practices. >> And this pattern repeats constantly. >> Agile, >> DevOps, >> design thinking, >> OKRs, >> product operating models. >> Every management fashion eventually gets copied at the surface. >> And the surface is always easier to copy than the discipline. Exactly.
Capability beneath ceremony
It's easier to hold a daily standup than to create real cross-functional accountability. Easier to write OKRs than to make hard prioritization choices. Easier to create platform teams than to build a real service mindset. Easier to say you build it, you run it than to fund reliability, observability, and on call health. >> So mimicry asks what do they do? Transformation asks what conditions make that behavior effective. >> That second question is slower >> and better >> because it forces the organization to look at itself. >> Yes, that is the uncomfortable part. Copying keeps attention outside the organization. Diagnosis brings attention back inside >> and inside is where the constraints live. >> Trust lives there. Architecture lives there. Incentives live there. Leadership behavior lives there. Old scars live there. >> Old scars.
>> Past failures that shaped how people behave now. Maybe a team shipped too quickly once and caused a major outage. Maybe leaders asked for transparency and then punished the first person who brought bad news. Maybe autonomy was tried before but without support and it failed. >> So now the organization says it wants modern practices but its nervous system still remembers the old injuries. >> Exactly. And if you do not understand that history, the new practice lands on top of the old fear. >> That is why a practice can look adopted but not become real. >> Yes, people know the script but they do not trust the stage. >> Let's make this practical. Suppose a leadership team is listening and realizing we may be doing this. >> The article gives them a better set of questions. >> First, which organization are we copying?
And be honest, sometimes leaders say they are adopting a best practice, but really they're copying a specific admired company. >> Second, what do we believe this practice will solve? >> That question matters because vague admiration produces vague transformation. >> We need to be more like them is not a strategy. >> No, we need to reduce decision latency between customer insight and product change is closer. >> Third, what local constraint might prevent this from working here? This is where the real work begins. Maybe it's architecture, maybe it's compliance, maybe it's leadership approval patterns, maybe it's incentives, maybe it's skill, maybe it's trust. >> Fourth, what capability must be built before the practice can produce the same result? >> That's the big one. >> Because the copied practice may require a missing muscle.
>> Exactly. If you want autonomous teams, you may need better strategic clarity. If you want continuous delivery, you may need stronger test automation and operational ownership. If you want OKRs, you may need leaders who can tolerate focus and say no. If you want product discovery, you may need access to customers and permission to change direction. >> So, the artifact comes last. >> Yes, that is the article's closing idea. Good ideas should travel, but they should travel as principles, patterns, and hypotheses, not as cargo cult rituals. Cargo cult rituals. That phrase stings. >> It should because a lot of transformation work accidentally becomes ritual without transfer. >> People perform the shape of success. >> But the capability doesn't move. >> So what does real transfer look like?
Copy the artifact last
>> The organization studies the example, extracts the principle, tests it against its own constraints, practices the underlying behavior, adapts the form until it becomes real, >> and then copies the artifact last. Exactly. The artifact is the final expression, not the starting point. >> That flips how many organizations approach transformation. >> Most start with the artifact because it's visible and purchasable. >> New tool, new framework, new operating model, new meeting structure. >> But the deeper question is what must become true here for this practice to actually work? >> That's the leadership question. >> Yes. And it's harder because it usually implicates leadership. >> How so? Because many practices depend on leadership behavior. Psychological safety depends on how leaders respond to bad news.
Empowerment depends on whether leaders actually release decisions. Focus depends on whether leaders stop flooding teams with priorities. Technical excellence depends on whether leaders fund invisible work before it becomes visible failure. >> So leaders cannot just announce the practice and wait for teams to transform. No, they have to become part of the conditions that make the practice real. >> That may be the biggest takeaway. Practices do not create the context by themselves. >> Right. Sometimes a practice can help reveal what context is missing, but it cannot magically supply all of it. >> Like a smoke detector. >> Exactly. A smoke detector can alert you to fire. It cannot repair faulty wiring.
And a copied practice can reveal organizational friction but it cannot automatically fix trust incentives architecture or leadership behavior. >> That is why transformation often feels frustrating. The organization says we adopted the thing. Why are we not getting the result? >> Because the thing was never the source of the result. >> It was the expression of a system. >> So final thought. What should listeners do with this? The next time your organization admires a high performer, do not stop at what do they do. >> Ask why does that work there? >> Then ask what would have to be true for it to work here. >> And then what do we need to practice before we copy the artifact? >> Exactly. >> Because this looks like transformation right up until it collapses.
Unless you go below the surface, >> below the ritual, >> below the costume, >> below the copied language >> to the context, the constraints and the capability. >> That is where transfer actually happens. >> And that's the warning. By the time the copied practice fails, the real failure already happened earlier. >> When imitation outran diagnosis >> when the organization copied the flower and forgot the roots. >> So borrow the idea. Study the pattern, >> practice the capability, >> adapt the form, >> and copy the artifact last. >> Thank you for tuning in to this episode of The Focal Point. Be sure to subscribe on your favorite platform. I am your host, Filiberto De La Cruz. Until next time, God bless you and yours and everyone.
