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 the design of the inside of warehouses and stores: the racking, the flow, the automation. Everyone in it held 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. That’s the classic shape of a knowledge management problem: not too little expertise, but no agreed home for it.
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
This is what happens without a working knowledge management practice underneath a highly skilled team. 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 and 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. None of that is a training issue. It’s what happens when there’s no knowledge management process to catch a contradiction before it reaches a junior engineer.
Best practice versus good practice, and why the difference matters
The kitchen-noodle comparison earns its place here. 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.
This company’s 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. That shared understanding is, in the end, just knowledge management by another name.
Building the knowledge management engine
The fix wasn’t a new answer handed down from on high. Building a working knowledge management engine rarely starts with an answer at all. It’s classic knowledge management: go and find out what the department already knows, collectively, and stop it fighting itself. It started with interviews: junior engineers, team leads, senior managers, every site, building up, layer by layer, what the department’s actual working processes were. Where documentation existed. Where it was missing. Where three different versions of the same document contradicted each other.
From those interviews came flowcharts, a set of dashboards, and a series of automated 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. The department’s scattered knowledge turned into something people could actually see and trust. 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 the real picture was clear enough to tell management, accurately, what was actually wrong: never a comfortable conversation, since it meant telling several managers they were part of the problem they’d been complaining about. Another two months got something functional running, and by the year mark the whole system was embedded and running without hand-holding. A year sounds slow for a knowledge management fix, until you remember it replaced three years of standing argument.
What the moped fleet turned into
That’s the actual return on a working knowledge management practice. 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, and not because people worked harder: because far less of their time went into rework and re-litigating decisions that should have stayed settled the first time.
Here’s the part worth flagging 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 knowledge management practice 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 dashboards, 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.
If any of this sounds familiar, it’s exactly the gap PDCA Consulting’s work closes: project and programme governance built from our own principles for learning from experience and defining roles, not a framework recited at people.
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
