You bring in the one system that’s supposed to connect four sites, four divisions, or four years of growth into something consistent. It goes live. Within a month, one site is running it properly, two have built a workaround, and the fourth has quietly gone back to the spreadsheet nobody else can see.
Nobody planned that. The system wasn’t built wrong. It just landed on four different ways of getting the same job done, built up over years by people who were never asked how they actually do it, only told to use the new tool once it arrived.
Here’s what I’d notice first if I were walking that floor. Every site, every division, already has a working version of the process. Not the version in the manual, if one exists. The version the person actually running it uses when the manual doesn’t cover what’s in front of them. That version is usually better than head office assumes, because it survived real conditions the manual never saw. It’s also the version that gets overwritten first, because nobody thought to ask the person running it before choosing which site’s habits become the standard.
Three businesses, one same pattern
Picture a manufacturer running four separate production facilities, each one adding a shared piece of equipment at the same time to serve new markets. Every facility has built its own small adjustments to the same basic job over years: how a quality hold gets flagged, how a changeover actually happens, what “ready to ship” really means on a Tuesday versus a Friday. The new equipment doesn’t know any of that. It just runs whichever version happens to be running when it arrives, and the other three facilities inherit it whether it fits their floor or not.
Or picture a company with four separate divisions, visual, digital, print, and motion, bringing in one shared workflow system meant to connect how work moves between them. Each division has quietly run its own handoffs for years, because nobody ever sat the four teams down and asked how the work actually travels from one to the next. The new system has to run on some version. Whichever one it picks becomes the standard by accident, not because anyone checked it was the one that actually worked.
Or picture a company opening a brand new site in a different country to serve its biggest customer yet. There’s no history there to draw from, no existing habits to untangle, just whoever’s on the floor that week, building the standard in real time while the pressure to deliver is already on. The parent site’s way of doing things gets copied across as the template, often without anyone checking whether the people actually running the new floor agree it’s the right one to copy.
None of these businesses did anything careless. They’re growing, adding capacity, going after bigger customers. But a shared system, a shared standard, or a shared playbook only works as well as the real, specific way the work already gets done on the ground, and that’s almost never written down anywhere, because nobody’s asked the people doing it to write it down.
What I’d actually do about it
First, before rolling out anything shared across sites or divisions, spend real time with the people doing the work at each one and ask them to walk you through how the job actually gets done today, not how the manual says it’s done. Write down where those versions genuinely differ and why. Half the time there’s a real reason: different equipment, different customers, different constraints. The other half, it’s just habit, and that’s useful to know too.
Second, when the versions conflict, pick the one that survived the hardest real conditions, not the one from the biggest site or the loudest manager. Test it with the people who’ll actually run it before it becomes the standard everyone else has to adopt. A standard nobody who does the work had a hand in shaping gets worked around within a month, quietly, the same way the old one did.
Third, build in a short window, thirty days is usually enough, where the people running the new standard can flag what doesn’t hold up once real volume hits it. Treat that feedback as information, not resistance. The fastest way to find out a standard is wrong is to ask the people stuck running it, before the gap turns into a workaround nobody tells you about.
None of this slows the rollout down by much. It’s the difference between a standard that holds and one that quietly splits back into four versions within a quarter, just better disguised than before.
If you’re standardising a process across sites, merging how two teams work, or opening a new location and building its habits from scratch, let’s talk it through: https://calendar.app.google/nJyTsHMsJJ5TnCzBA