The Knowledge Base Nobody Uses

Somebody built a wiki here once too. It had a real launch, a real announcement, a page for everything. Eighteen months later almost nobody opened it, and the people who needed an answer went back to asking a person instead. That isn't a story about laziness. It's the normal life cycle of a knowledge base, and it's worth asking why.

We keep a working log of every session at this company: what got decided, why, and what was still open when we stopped. Hundreds of them now. It works, and it's tempting to conclude that we just found the discipline everyone else lacks.

We didn't. We found something narrower, and it's the actual difference between a knowledge base that dies and one that doesn't.

Writing it down was never the hard part

Almost every company we've looked at has more written down than anyone gives it credit for. Old Slack threads. A Notion page somebody built during a slow week. Meeting notes nobody reopened. The information usually exists somewhere. What's missing is never the writing.

What's missing is a reason to go looking. A wiki page sits there being true or false, and nothing tells you which, and nothing tells you it exists at the exact moment you need it. So the next person asks a person instead, because a person, unlike a page, can be interrupted. The page didn't fail because it was wrong. It failed because being right and being findable are two different problems, and most tools only solve the first one.

We built one of these mechanisms and it didn't work either

Early on, we wrote a real safeguard directly into how this system works: a check that catches a specific class of mistake before it ships. Correct code, reviewed, tested. It sat there for months doing nothing, because nothing was wired to actually run it. Not broken. Just never invoked.

That happened to us more than once, in more than one form. A check nobody had turned on. A notification hook that was configured exactly right and never fired, because nothing ever wrote the one line that would have triggered it. Each time, the fix already existed. What was missing was something calling it.

A mechanism nobody invokes is indistinguishable from a mechanism that was never built. The same is true of a document. Writing an answer down and never surfacing it again is functionally the same as not writing it, except it costs you the false comfort of thinking the problem is solved.

What actually changes the outcome

Two things, and neither one is "write more."

The first is retrieval that happens automatically, at the moment somebody is about to ask a question, not a search box they have to remember exists. The second is provenance: a marker on the answer that says whether it was actually decided, by someone with the standing to decide it, or just typed once and never checked again. A stale answer that looks exactly as confident as a current one is worse than an empty page, because an empty page at least tells you to go ask.

We didn't set out to build a smarter wiki. We set out to make sure an answer that already existed would actually reach the person who needed it, without them having to remember where it lived or whether it was still true.

A few questions this raises

Isn't this just a wiki with extra steps?

No. A wiki is a place to put an answer. The actual failure is retrieval, not storage, so the fix has to be automatic surfacing at the moment of the question, not a better place to file things that still require someone to go looking.

How do you know an answer hasn't gone stale?

By recording when it was decided and by whom, and treating anything without that as unverified rather than true. A date on a document tells you when it was written. It doesn't tell you whether it still holds, and those are different questions.

What if the company hasn't written much down to begin with?

Then the first fix is capturing decisions as they happen, at the moment they're made, rather than trying to reconstruct them later from memory. Every company we've looked at has written down less than it thinks, but reconstructing a decision after the fact is much more expensive than recording it once, at the source.