Most companies do not have a knowledge base problem. They have a folder where documents go to be forgotten, and a supervisor who answers the same question for the fourth time this month because asking is faster than looking. A knowledge base earns the name only when that second thing stops happening.
What is a knowledge base, and how is it different from a shared drive?
A knowledge base is one organized, maintained place where answers to recurring questions live, written so a reader can find a single answer without reading everything around it. A shared drive is storage, while a knowledge base is retrieval.
The distinction seems insignificant until you watch someone use one. On a shared drive, finding the answer requires knowing where the file lives, which requires already knowing most of the answer. In a knowledge base, the reader arrives with a question and leaves with the one thing they came for.
Why do most internal knowledge bases go stale?
Because they get launched as a project and never funded as a process. Content gets written once by whoever had the time, nobody owns it after go-live, and the first outdated answer teaches the whole team to stop trusting the system.
I've watched this happen more than once in manufacturing. The content was accurate on the day it was published, but then a line was reconfigured, a supplier changed a spec, and the article kept describing the old sequence. One operator followed it, hit a wall, and told two other people the system was wrong. That's all it takes. Trust is expensive to build and cheap to lose, and a knowledge base runs entirely on trust.
What should go into a knowledge base first?
Start with the questions people are already asking. The five that come up weekly are worth more than a complete map of everything the company does, and you can write them in an afternoon.
- The questions your supervisors answer most often
- The tasks a new hire hits in the first two weeks
- Anything only one person currently knows how to do
- Steps where a mistake is expensive or hard to reverse
- Decisions that should follow a rule instead of a fresh judgment call each time
Resist the urge to document everything. A small knowledge base that's right beats a comprehensive one that is half stale, because readers cannot tell which half they are looking at.
How should a knowledge base be organized so people actually find things?
Organize by the task the reader is trying to complete, not by the department that owns the information. People arrive with a question, not an org chart.
Titles do most of the work here. "Returns" tells a reader nothing. "How to process a customer return after the 30-day window" tells them whether to click before they spend any attention on it. This is a more important distinction than it seems at first blush: a reader scanning a list is holding their actual question in working memory while evaluating each option, and every vague title forces them to open it and read to find out. Three of those and they go ask a coworker instead. Titles that state the task cut that cost to nearly nothing.
Keep articles to one question each. When a page answers four things, the reader has to locate their answer inside it, which is the shared drive problem again at a smaller scale.
Who should own a knowledge base?
One named person per article, plus one person who owns the system. Departmental ownership means nobody's name is on it, and nothing with nobody's name on it rarely gets updated.
The article owner is the person who would be asked the question anyway. Their job isn't to write beautifully. It's to notice when the process changes and fix the article that week. The system owner watches the whole set: what's being read, what's being asked despite existing, and what hasn't been touched in two years. Both roles take real hours, and budgeting them is the difference between a knowledge base and an archive.
How do you get people to use it instead of asking a coworker?
Make the answer faster to find than a colleague is to interrupt, then route questions back to the article every time one comes in. Both halves are required.
The routing habit often gets skipped. When a manager answers a documented question directly, they've just taught the team that asking works better. Answering with the link, every time, teaches the opposite, and it surfaces bad articles fast. If the link doesn't actually answer the question, that's useful information: the article is wrong, and now you know which one.
Watch what still gets asked after three months. Repeated questions on documented work mean the document isn't answering them, and a verbal answer has quietly become the real procedure.
When is it worth bringing in a writer to build one?
When the people who know the answers are the same people with no time to write them down, which describes most companies. I tend to be redundant on this point because the bottleneck doesn't clear on its own and gets more expensive as the team grows.
An outside writer interviews the people holding the knowledge, drafts articles a new hire can follow without a supervisor standing by, and builds the structure and ownership that keeps the thing alive after launch. Technical writing projects are scoped individually and can include process design and staff interviews alongside the writing. Common questions about how that works are answered on the FAQ page. If years of institutional knowledge sit with one or two people and the concern is losing it entirely, that conversation sometimes points toward ghostwriting rather than a knowledge base. Either way, book a discovery call and we can sort out which one you need.
Frequently asked questions
What is the difference between a knowledge base and a shared drive?
A shared drive is storage and a knowledge base is retrieval. On a shared drive, finding an answer requires knowing which file holds it, which usually means already knowing most of the answer. A knowledge base is organized so a reader can arrive with one question and leave with one answer without reading everything around it.
What should go into a knowledge base first?
Start with the questions people already ask every week: the ones supervisors answer most often, the tasks a new hire hits in the first two weeks, anything only one person knows how to do, steps where a mistake is expensive to reverse, and decisions that should follow a rule instead of a fresh judgment call each time.
Why do internal knowledge bases go stale?
Because they are launched as a project rather than funded as a process. Content gets written once, nobody owns it after go-live, and the first outdated answer teaches the team to stop trusting the system. A knowledge base runs on trust, which is expensive to build and cheap to lose.
Who should own a knowledge base?
One named person per article, plus one person who owns the system as a whole. Departmental ownership means nobody's name is attached, and nothing without a name on it gets updated. The article owner fixes the article when the process changes; the system owner watches what's read, what's still being asked, and what hasn't been touched in years.
