Company Wiki: Why It Fills Up and Empties Out

There is a garage on most streets that started as a good idea. One neighbor needed somewhere to put the ladder, so a shelf went up. Then a second shelf, for the paint. Within a year the whole family is dropping things in: the broken lamp that might get fixed, the box marked “misc,” the bicycle nobody rides. Everyone has a key. No one has the job of tidying. And one wet afternoon, when you need the good wrench, you stand in the doorway looking at a wall of stuff and you cannot find it, so you go buy another wrench.

A company wiki is that garage with a search bar.

It starts the same hopeful way and ends the same cluttered one, and the reason is worth understanding, because the usual fixes (a stricter tool, a tidier structure, a quarterly clean-up) treat the symptom and miss the disease. Our position, and the line to carry through this whole piece: a wiki is judged by whether its answers reach the person at the moment of the work, not by how many pages it holds.

What is a company wiki?

A company wiki is the loosest form of an internal knowledge base, a set of linked pages anyone on the team can create and edit to share what they know. It holds the policies, the process steps, the product notes, the onboarding guides, the things a colleague would otherwise have to ask someone for. It points inward, at your own people, which is what separates it from a customer help center.

The looseness is the whole appeal. Spin one up in an afternoon, hand everyone edit rights, and the pages multiply on their own. That same looseness is the trap. A wiki with no gatekeeper fills with everything anyone thought worth saving, and a store that holds everything is a store that helps with nothing, because the one page you need is buried under forty you do not. It is the easiest member of the internal knowledge base family to start, and the quickest to rot.

Why does a company wiki fill up and empty out?

Because two deaths kill it, and both are built in from the first page. They run at the same time, which is why a wiki can look full and feel useless at once.

The first death is the content. Most pages go in without an owner or a review date, so the moment the process they describe changes, the page becomes wrong and stays up, sitting on the shelf right next to the pages that are still right and looking exactly like them. You cannot tell the true page from the rotted one without already knowing the answer, which defeats the point of looking. A store you cannot trust is a store you stop trusting all at once. One burned afternoon, chasing a page that turned out to be a year out of date, teaches a person to guess instead.

The second death is the habit. After the launch push fades, opening the wiki means leaving the work to go look, and that small detour is heavier than it sounds. The work is in one window; the answer is in another. Under any deadline, a guess or a quick message to the colleague two desks over beats the trip to the shelf. Nobody on the team decided to abandon the wiki. The detour decided for them, one deadline at a time.

The cost of that second death is large enough to measure. The McKinsey Global Institute estimated that knowledge workers spend close to a fifth of the workweek searching for and gathering the information they need to do their jobs (McKinsey Global Institute). Panopto’s workplace-knowledge study put the figure at roughly 5.3 hours a week per employee lost to hunting for information that already exists somewhere in the company (Panopto). Two independent numbers, the same picture: people burn a day a week looking for what the wiki was built to hand them.

The shelves were never the problem.

You might say this is a discipline issue, that people will not keep their pages current or check the wiki before they guess. Fair, and it feels true from a distance. But blaming the people misreads the mechanism. When the right action (check the wiki) costs more effort than the wrong one (guess), people take the cheaper path, and they are right to, because they have work to finish. The same wall stops a sales knowledge base and breaks ordinary knowledge sharing: the knowledge is posted, and posting is mistaken for landing. A page nobody opens changed nothing, however well written. Storing was solved years ago. Finding is close to free. Use is the part still standing open.

How do you keep a company wiki from rotting?

You stop fighting the symptom and treat the two deaths directly. One fix per death, and they are structural, not motivational. You are not asking people to care more. You are making the true answer the easy one.

• Ownership. Give every page a named owner and a review date, so a changed process updates the page instead of orphaning it. Cut the pages no one reaches for. A smaller, trusted store beats an exhaustive grey one, and ownership is what stops the content from rotting.
• Delivery in the flow. Surface the answer inside the tools where the work already happens, the CRM, the inbox, the help desk, so consulting it costs no detour. When the answer comes to the person, the habit never has to fight the friction that killed it.

The first move keeps the wiki true. The second gets it used. Skip either and the wiki dies its usual death wearing a cleaner tool.

The second move is the one that breaks the old model, so it is worth being plain about. A wiki is built to be visited. A wiki built for use comes to the person instead. The answer arrives where the work is, triggered by what the person is doing, and the wiki stops being a destination and starts being a behavior. That is the same shift behind the better knowledge base examples worth copying: the ones that win are not the ones with the most pages but the ones whose answers show up at the moment of the work.

This is where the measuring has to change too. A wiki graded on page count or page views is grading the shelf, not the use. The question that matters is whether the answer changed what someone did. You can only improve what you inspect, and counting pages inspects the wrong thing.

The payoff for getting this right is not tidiness. It is behavior. Our State of Sales Enablement found teams whose guidance reaches them in the flow of the work hit quota at 49 percent, against 15 percent for teams whose knowledge sits in a separate place to go look. Same content, same people. The difference was whether the answer arrived where they stood or waited for them to come find it. A wiki measured on page count would rate both teams the same. A wiki measured on use can tell them apart.

What we recommend

Two paths sit in front of anyone staring at a bloated company wiki.

The first path keeps polishing the container. A neater tool, a stricter folder structure, a better search box, another spring clean. It feels like progress, and it buys a few good weeks, and then the same fog rolls back in, because none of it touched either death. The content still has no owner, so it still rots. The answer still lives one detour off the road, so the habit still fades. You are tidying the garage without giving anyone the job of keeping it tidy or moving the good wrench to where the work happens.

We recommend the second path, and the evidence makes the case without much help from us. People lose close to a fifth of the week, and on Panopto’s count more than five hours of it, to searching for things the wiki was supposed to hand them. Content with no owner drifts wrong and stays up. And answers delivered in the flow of the work more than triple quota attainment over knowledge parked somewhere separate. So give every page an owner, curate the wiki down to what people reach for, and deliver the answer where the work is happening. Then measure whether it changed what people did, not how many pages exist.

Build the wiki, then go past the shelf. Make the answer find the person in the flow of the work, and the company wiki finally earns the keep it has been costing. Start with the broader pattern in the internal knowledge base, then the habit that makes any of it land in knowledge sharing.