How to share company knowledge so it doesn't live in people's heads

In most growing companies, knowledge lives in three places: someone’s head, someone’s inbox, and a shared drive nobody can navigate. The result is familiar — the same questions asked every week, the one person who “knows how that works” becoming a bottleneck, and new hires taking months to get up to speed.

Sharing company knowledge well isn’t about a bigger wiki. It’s about deciding where each kind of knowledge lives, keeping that consistent, and making it part of how the team already works.

Four kinds of knowledge, four homes

Most confusion comes from mixing different kinds of information in one place. Separate them:

Once everyone knows which kind of thing goes where, the question “where would I find that?” has one answer.

Updates: the Hub

Each team in Clarion has a Hub — a feed of posts for the people on that team. Use it for news that matters now and will be old in a month: decisions made, changes coming, wins, reminders. Type an update in the box and click Post. See post to the Hub.

Two habits make it work:

• Pin standing information. A post that stays relevant — this quarter’s priorities, the holiday rota, the escalation contact — can be pinned so it stays at the top while newer posts flow below.
• Let meetings write to it. When a team runs its weekly sync in Clarion, the wins and notables shared in the meeting and the end-of-meeting summary are posted to that team’s Hub. People who missed the meeting catch up by reading the Hub, rather than asking someone to repeat it.

Keep the Hub for updates. If a post starts turning into instructions people will need again next month, it belongs in the knowledgebase.

How we work: the knowledgebase

The knowledgebase is for anything someone will need to look up more than once: process documents, policies, role descriptions, onboarding guides, FAQs.

Open Knowledgebase in the sidebar and click New Article. Articles support headings, checklists, tables, images and code blocks, plus a video link — paste a YouTube, Vimeo or Loom URL and it embeds with the article. Articles start as drafts; click Publish when the owner is happy the content is right. Once published, edits keep a version history, so you can see what changed and restore an earlier version. See write knowledgebase articles.

Organise with a small set of categories, set up in Settings → Categories — for example “Processes”, “Policies”, “Roles”, “Onboarding” and “Customer FAQs”. Fewer categories with clear names beat a deep folder tree. See manage categories and tags.

Each article belongs to a team and is either Team-only or Company-wide. Default to company-wide; restrict only when there’s a real reason. If you need to share an article with someone outside the company — a contractor or a client — an admin can turn on Public Article Sharing in Settings, and articles can then be shared by public link.

If your processes already exist as documents elsewhere, the knowledgebase Import button accepts Markdown, plain text and HTML files. For guidance on what to write first, see document your core processes.

Files and links: assets

Templates, brand files, price lists and signed contracts go in Assets — uploaded files or saved links, organised by category. When a file is updated, upload a new version rather than a new file, so links and references always point at the current one and older versions are kept. See upload and version assets.

The knowledgebase and assets work together: a process article explains how, and links to the current template in Assets rather than attaching a copy that will go stale.

Direction: the vision board

The most important company knowledge is often the least shared: what the company is trying to do, its values, and where it wants to be in one and three years. The vision board holds that in one place — core values, purpose, target market, the three-year picture, and goals for the year and the next 90 days. See build your vision board and, for founders, write your vision.

Point every new hire to it in their first week, and refer to it when making decisions. Knowledge about why is what lets people make good calls without asking.

Make it a habit, not a project

Knowledge-sharing efforts usually fail because they’re launched as a one-off project. A big documentation push in March is out of date by September. Build it into routines instead:

• Answer once, link forever. When someone asks a question that will come up again, write the answer as an article and reply with the link.
• Close the loop in meetings. If a challenge in the weekly sync ends with a process change, the action item is “update the article”.
• Use new hires as testers. Ask every new starter to flag articles that were unclear or missing. See onboard a new team member.
• Give articles owners. Every core article should have someone who keeps it current. Review the important ones once a quarter.

Measuring it

You can track knowledge-sharing like anything else. A few metrics for a people or operations team:

Common mistakes

• Everything in one place. A feed full of policies, or a knowledgebase full of announcements, makes both useless.
• Private by default. Knowledge that’s hidden isn’t shared.
• No owners. Unowned articles go stale, and stale articles teach people not to trust the knowledgebase.
• Writing too much. Short, specific articles get read. Long ones get skimmed and then ignored.
• Relying on memory in meetings. If a decision matters beyond this week, write it down where people will look for it.