In this blog, we’ll explore what happens when a room full of highly qualified people all disagree about the right way to do the same job, why “best practice” and “good practice” are not the same claim, and how I spent a year turning 150 people’s separate opinions into one knowledge management engine that actually pulled in the same direction.
The Intralogistics department for this company was responsible for designs of the inside of warehouses and stores — the racking, the flow, the automation. Everyone in it holds a logistics qualification. Nobody in it was short of knowledge. The problem was the opposite: too much knowledge, scattered across too many heads, with no agreed answer for which head was right.
Picture the department as a car park full of mopeds. Everyone has fuel. Everyone knows how to ride. And every single one of them is heading off in a slightly different direction, because nobody built the bit that pulls the whole fleet into one engine.
The junior engineer who couldn’t win
Here’s what that looked like on a Tuesday. A junior designer would take a warehouse layout to a senior colleague, get it approved, and move on. Then a different senior colleague — equally qualified, equally convinced they were right — would see the same layout and tell them it was done completely wrong. Not because the junior had ignored instructions. Because there were no instructions. There was only whichever manager happened to be free that week, applying whichever method they personally preferred.
Multiply that by three layers of management and 150 people spread across China, India, Sweden, the US, and Germany, and you get a department where the frustration ran in every direction at once. Juniors thought the middle managers were incompetent. Middle managers thought the juniors were undertrained. Senior leadership had no idea why anything took so long, because nobody had ever named the actual problem out loud.
The actual problem had nothing to do with competence. It was consistency. There was no shared standard for which tool to use, no agreed process for approving a new one, and — this is the bit that quietly costs a company the most money — no mechanism for new knowledge to ever get signed off. Engineers on the ground kept discovering better ways to automate a design and sending them up the chain for approval. Those emails sat in inboxes. For weeks. Sometimes months. Occasionally one manager would approve something and a second manager would reject the exact same submission, because the two of them had never agreed on anything either.
Best practice versus good practice, and why the difference matters
This is where I find the kitchen-noodle example genuinely useful, so I’m keeping it. Instant noodles have one correct method: boil water, add noodles, wait three minutes, done. That’s best practice — there is only one way, and it’s not up for discussion. Cook noodles from scratch, though, and there are several legitimate routes to a good plate of food: boil them, stir-fry them, add whatever you like. That’s good practice — multiple valid answers, all correct, as long as you land somewhere sensible.
The Intralogistics teams were operating in good-practice territory — there genuinely were several valid ways to design a warehouse flow — but everyone was behaving as though they were defending a best-practice position. Each manager believed their method was the one true noodle recipe. Nobody had built the shared understanding that would let good, different approaches coexist without a three-layer argument every time one of them got used.
Building the Knowledge Management Engine
My job wasn’t to invent a new answer and hand it down from on high. It was classic knowledge management: go and find out what the department already knew, collectively, and stop it fighting itself. I interviewed everyone — junior engineers, team leads, senior managers, across every site — and built up, layer by layer, what the actual working processes were. Where documentation existed. Where it was missing. Where three different versions of the same document contradicted each other.
From that I built the flowcharts, a set of Power BI dashboards, and a series of Power Automate workflows that turned “submit for approval and hope” into an actual visible process. Anyone could see what was waiting for sign-off, what had been approved, and who was sitting on a decision. A monthly approval meeting closed the loop. And critically, the whole thing was designed to review itself — every six months, the approved knowledge got checked against reality and updated, because knowledge goes stale the moment everyone stops looking at it.
It took roughly two months of interviews before I could tell management, accurately, what was actually wrong — which is never a comfortable conversation, because it involves telling several managers they were part of the problem they’d been complaining about. Then another two months to get something functional running, and by the year mark the whole system was embedded and I’d moved on to other work.
What the moped fleet turned into
Once the process existed, the fighting mostly stopped, because there was finally a shared answer to “who’s right here” that didn’t depend on which manager you happened to ask. Juniors stopped losing arguments they hadn’t lost on merit. Middle managers stopped being blamed for a lack of consistency they hadn’t actually created. Delivery got faster — not because people worked harder, but because far less of their time went into rework and re-litigating decisions that should have stayed settled the first time.
The part I’d flag to any organisation eyeing up AI adoption right now: a department with no shared, documented, trusted process cannot absorb something new quickly, because it’s still mid-argument about the old thing. A department with clear ownership and a working review cycle can plug new capability in without a fresh civil war every time. Transparency and consistency aren’t nice-to-haves you bolt on afterwards. They’re the engine block. Everything else — automation, AI, whatever comes next — bolts onto that, or it doesn’t bolt on at all.
I’ll be honest: for years I described this project mostly in terms of the tooling — the Power BI builds, the automation, the governance cadence. It’s taken a coaching conversation this year to notice that’s the boring half of the knowledge management story. The interesting half is that 150 highly qualified people were quietly making each other miserable because nobody had ever sat down and asked what the real problem was, rather than what everyone assumed it must be. That’s the bit worth telling.
See more at Our ITIL coaching & consulting or PeopleCert
To find out more about PDCA Consulting’s expert consulting services either:
- Book 30-minute conversation directly: here
- Get in touch via the contact form here
- Connect with me on LinkedIn
