Internal Knowledge Base Template

Start with an inventory, not a writing sprint. Most teams keep knowledge in a wiki, pinned chat threads, closed tickets, onboarding notes and a few people's heads. Give each topic one row: a runbook, a system, a recurring decision or a process people follow from memory.

Split topics that fail separately. Deploying a service and rolling it back come up at different moments, so they get separate rows, even when one person owns both. Note where each one lives today, because that decides how much work it needs.

Flag every topic whose only record is a chat message or a ticket comment. GitLab, the software company, keeps just 90 days of Slack history on purpose¹. Its handbook explains that when people can search old chats, they have no motivation to write things down where everyone can find them.

Make the owner one person, not a team. "Owned by platform engineering" can't be checked against a team list, and a team never leaves the way a person does. If nobody fits, mark the topic unowned. A false owner sends people to someone who can't help.

Software Engineering at Google, the 2020 book on the company's engineering practices, says documents without owners become stale and difficult to maintain². Pages on Google's old internal wiki had no true owners, and many became obsolete. At one point the wiki held 7 to 10 documents on setting up the same production system, and only a few seemed to be maintained.

Check every owner against your current team list, and rerun the check whenever someone leaves. A departure makes a topic risky that day, not at its next review. Flag people who changed roles separately, since they can often still answer a question.

For each topic, count the people besides the owner who have made a substantive edit or logged a review. A corrected step counts, and so does a walkthrough that confirmed the page still works. Typo fixes and reformatting don't. Call this the backup count: zero means only the owner has ever shown they can maintain it.

Researchers measure the same risk in software projects as a truck factor: the number of developers who would have to quit before a project is incapacitated. A 2016 study of 133 popular projects on GitHub estimated that 65% had a truck factor of two or less³. Don't assume your team is different until you've counted.

Then rank each topic on two things together: whether its owner has left, and its backup count. Where a topic has backups, write down their names. A backup count nobody can put names to is only a guess.

Work down from the top of that ranking, not from the pages people read most. Get the steps written before anyone needs them in a hurry. Google's site reliability engineers found that recording best practices ahead of time in a playbook produced roughly a 3x improvement in mean time to repair⁴, compared with "winging it."

If the owner is still around, have them walk through the procedure once while you write. A version pieced together from old tickets can look complete and still be wrong. Record the exact command or click, the value to check, and what success and failure look like. Where two sources disagree, mark the conflict for the owner to settle rather than guessing.

Backups only grow if editing a page you don't own is normal. If you're sure of a change, make it and ask the owner to review. If you're not, propose it and say what you're unsure about. Settle disagreements with evidence, not seniority: test the step against the real system when that's safe, and record what happened.

What keeps backups at zero is asking the owner instead of reading the page. Software Engineering at Google also warns that knowledge bottlenecks can grow out of good intentions. A habit of "Let me take care of that for you"⁵ saves time today, but the team never learns to do the work. If you own a page, answer questions by linking to it, and fix the page when it's wrong.

Set review timing by how fast each topic changes, not one interval for everything, and automate the reminders. Google often attaches freshness dates to its documentation, and that metadata sends email reminders when a document hasn't been touched in, for example, three months².

• Runbooks for systems still changing: every quarter, and after any incident that used them
• Stable infrastructure procedures: every quarter, since even slow-moving systems drift
• Policies and standards: every 6 to 12 months, or when a decision changes them
• Onboarding material: after each new group of hires, using their feedback

A review date only proves someone looked. Use is the stronger test. After each incident, support case or new hire's question, record which page was used and whether it was right. A postmortem report built from your incident data is a natural place to note it.

Write the Docs, a global community of people who care about documentation, advises treating incorrect documentation as worse than missing documentation⁶. So a page that looks fresh by edit date but failed the last person who relied on it goes to the top of the rewrite list. A high-risk page nobody used this quarter is unverified, not safe.

To capture a procedure quickly, record the owner walking through it and turn the transcript into steps with the SOP from a walkthrough tool. When an owner is leaving, start a role handover document well before their last week.