Knowledge debt

Every company I've worked with carries two kinds of debt. Technical debt comes up in every retro. The other kind, knowledge that exists somewhere but can't be found, trusted or used, rarely gets a name. I call it knowledge debt, and three projects from the past year showed me how expensive it is.

Four weeks a year, searching

It started at home. Reviewing BN Digital's year, I was in decent spirits: utilisation acceptable, client satisfaction growing, the company in good shape. We'd started tracking more parameters about our internal processes, so I went looking for insights.

One number stopped me. Our project managers were spending up to 47 minutes a day searching for project-specific details: technical specs, past decisions, stakeholder contacts. Things we knew existed somewhere in our systems.

Forty-seven minutes doesn't sound catastrophic until you multiply it. That's nearly four hours a week and more than 200 hours a year: an entire month of productivity spent hunting for information we'd already created. When I polled the managers, they guessed about an hour a day, so the feeling wasn't far off.

I checked whether it was just us. It isn't:

• The average knowledge worker loses 8.2 hours a week searching for information (APQC).
• A quarter of the working week goes to information hunting (Atlassian, 2025).
• 48% of workers struggle to find a specific document quickly (Adobe, 2023).
• Internal enterprise searches succeed on the first attempt about 10% of the time (Slite).

So we're below the industry average. But being better than average at wasting time isn't a competitive advantage. Underneath, I found three things. We stay fairly organised, but a lot of the data is already stale, and we keep skipping routine clean-up and archiving. Managers sometimes duplicate work; research says half of all teams unknowingly do the same, because they can't find what already exists. And none of the AI tools we tried gave real relief yet. They all promise; none work out of the box.

The strategy that made it worse

The obvious response is a document management strategy. One client showed us why that isn't enough.

A 40-person asset management firm came to us shortly after its Head of Operations had rolled out a comprehensive one: strict folder hierarchies by client and fund, mandatory metadata fields, three-level approval workflows and regular compliance audits, all on leading software.

Nothing improved. People stopped doing one dull task and started doing another. Analysts spent more time filling in metadata than analysing investments. Urgent market reports sat in approval queues for days. And despite all the rules, nobody could find anything, because everyone interpreted the categories differently.

The breaking point came on a live client call, when a partner spent half an hour hunting for a risk assessment. It existed in three versions across two approved folders. None was current.

A platform isn't a solution. There's no magic document management system that fixes everything, and the pattern repeats everywhere: startups moving too fast to document systematically, Fortune 500 companies with dozens of legacy systems that can't talk to each other, projects that fail because nobody knows what they're about.

The causes are natural. Startups move fast and pile up documentation debt; as they grow, discoverability breaks, and departments build their own flows because they can't wait for a central one. Enterprises build robust systems and then fail to get people to use them, so documents scatter across personal folders, the DMS and every other tool.

Hercules cleaned the Augean stables by redirecting two rivers. Untangling enterprise documents is harder: you have to route the knowledge through one workflow and get everyone to adopt it. The problem isn't discipline. Digital information simply moves faster than any method designed for filing cabinets.

The project that lost half its budget

The most expensive knowledge debt I've seen was at a European professional services firm, part of one of the largest networks in the world. They brought us in after their engineering team kept underperforming, and we added two senior developers to speed up a critical project. Both had stellar backgrounds and were ready to ship.

Then they went through onboarding, and were shocked. The architecture diagrams looked impressive, straight out of a textbook, and had nothing to do with the actual structure or requirements. Nobody owned the documentation, so the knowledge base was fragmented and out of date.

The first two sprints produced nothing. Our engineers spent four weeks reverse-engineering the existing team's work: cutting unused database tables, rewriting thousand-line classes, working out which features already existed and which of them worked. No new features. No problems solved.

Then it got worse. Watching the existing team, we saw engineers building blindly from user stories without understanding the bigger picture. The managers ran every agile ceremony perfectly (stand-ups, retros, sprint planning, twenty people on calls), and still nobody understood what they were building or why.

The business missed deadlines, burned through its resources and ended up with a buggy, unmaintainable product that delivered no value. Its answer was more management and more control. They followed every ritual except the one that generates knowledge, because the agile books don't list it.

What the three stories share

These look like three different problems: a search problem, a tooling problem and a delivery problem. They're the same one. Knowledge was created and then left without an owner, a place or a way back.

What we wrote into our Experience Bank:

• Preparation and strategic planning are undervalued. Writing down what you're building costs less than any sprint spent rediscovering it.
• Ceremonies don't create clarity; documentation does. You can't sprint towards a goal when most of the team doesn't understand the terrain.
• Productive teams aren't the ones with perfect stand-ups. They're the ones where knowledge is captured, shared and accessible.
• A system nobody uses is a folder with extra steps. Adoption is the project; the software is the easy part.
• Clean-up is a process, not an event. Stale data is how a tidy system turns back into a swamp.

This is a problem AI should be good at, and, built properly, it is. I wrote up how in Turning a document swamp into an organised knowledge system on the BN Digital blog.