Team Knowledge Bases Die in Month Four. Here Is the Alternative.

Every team knowledge base has the same life cycle, and it is predictable enough to plan around. The useful response is not more discipline in month four. It is accepting that a document collection can only hold one kind of knowledge, and being deliberate about which.

"The wiki is a graveyard with a search bar."

The four-month curve

Month	What happens
1	Structure agreed, templates made, genuine enthusiasm
2	Real contributions, mostly from people who enjoy writing
3	First stale pages. Somebody acts on one and is wrong
4	Trust gone. People ask colleagues. Contributions stop

Month three is the pivotal one, and it is usually a single event: one person relies on a page, the page is out of date, and they tell two colleagues. Trust in a reference collection is binary in practice, and it does not recover on its own.

Mixed shelf life is the killer

The structural error is putting pages with completely different decay rates in the same collection. "How to request production access" changes once a year. "Current release scope" changes weekly. Both go in the wiki, under sensible headings, and the reader has no way to tell which category a given page is in.

So every page carries the credibility of the worst page. A reader who finds one stale entry cannot distinguish the stable pages from the rest, and rationally stops trusting the collection. The same dynamic in FAQs is covered in an internal FAQ that stays current.

Why a graveyard is worse than nothing

An abandoned knowledge base imposes a cost rather than merely failing to help. Someone with a question now has a worse decision to make: search first, possibly find something plausible and wrong, then ask anyway. Two minutes lost and a risk of acting on stale information, versus asking a colleague immediately.

It also creates a false sense of coverage for managers. "We have a wiki" reads as knowledge being captured, which delays addressing the actual concentration of knowledge in a few heads, sometimes for years.

The alternative, in two parts

Keep a small stable set. Twenty or thirty pages maximum, each with a date and an owner, covering only things that change a few times a year: setup, access, runbooks for rare procedures, the architecture diagram. Delete anything nobody will vouch for rather than leaving it as a hazard.

Capture the perishable half daily. Current state, decisions and their reasoning, what was tried and abandoned, who owns what right now. None of these belong in a page, because they change faster than any page is maintained.

That second half is what a brief does. Ninety seconds at the end of each day, mostly pre-drafted from the work that already happened, and with StandIn it stays answerable: while someone is off, their StandIn answers questions from it in their words, with a source under every answer, and never guesses. Nobody maintains it as a separate artifact, because maintaining it is just finishing the day, and it cannot be four months stale because it was written yesterday.

The two halves together cover what a wiki was always being asked to do alone. See how StandIn works.

Common Questions

Why do team knowledge bases fail?

Because they mix pages with very different decay rates, so the perishable ones go stale and destroy trust in the stable ones. Once a reader has been misled once, they stop consulting the collection at all.

Should we delete our wiki?

Prune it hard rather than deleting it. Keep the pages someone will vouch for, put a date and an owner on each, and remove the rest. A small trusted set is far more valuable than a large uncertain one.

How many pages should a team wiki have?

Few enough that one person could review all of them in an afternoon, which for most teams is twenty to thirty. Beyond that, maintenance exceeds anyone's willingness and staleness becomes inevitable.

What belongs in a wiki and what does not?

In: setup, access, rare procedures, architecture overviews. Out: current status, recent decisions, who is working on what, anything that changes weekly. The second list is where the volume of questions actually is.