Your company wiki is like a Bible for your team - it's where you store knowledge and get answers you need to get work done.

Many businesses use a company wiki because they want a centralised hub of knowledge. It's populated with pages that team members can add to, edit and update as time goes on. Accessible to everyone, and owned by everyone, it puts information where everyone can find it. It's often called "a single source of truth."

But most of the time, company wikis are a confusing mess.

The hard truth(s) about your source of truth

After years of working with teams as they create and then grow their company wikis (as well as improving our own wiki over the years), we've seen the same problems time and again:

1. Too much information
2. Information is not actionable
3. No one contributes to the wiki (except admins)
4. The wiki is boring.

The result is an overstuffed, outdated, and ineffective company wiki. Instead of making your team more efficient and empowered to ship quality work, the wiki leaves them with a dusty pile of old documents and no clue what to do next.

The qualities of a quality company wiki

A company wiki that doesn't suck, on the other hand, is the following:

1. organized - only contains the information you need, and the information you need is easy to find.
2. transparent - anyone can edit it from their first day on the job, and can see documents made by their predecessors
3. actionable - documents are not just meant to be read, they're meant to influence decisions and improve the quality of tasks and projects.
4. engaging - wiki docs are far more than words. They have modular design, images and video, code embeds, data analysis, and commenting and reaction features so that people can quickly add their thoughts, however they see fit.

But when — and how? — do you start to build it?

When to build a wiki?

The answer to the first question is: day one. In fact, from the moment you write the first business plan, you’ve created a core document for your knowledge base.

Make it a priority to document processes from the start. As a founder or CEO, this isn’t really an option. Same goes for product and engineering leaders.And every new employee needs to be given this mindset too.

If you don’t currently have a company wiki, we’re going to look at what needs to be in it shortly. If you do have one, but it’s not working, there are a few reasons why this might be the case.

How to organize your wiki

A wiki is made up of discrete units of information - but you get to determine how to structure those units.

The primary ways to structure info in a wiki are hierarchical and content-based.

Hierarchical design

Hierarchical design nests smaller units of knowledge within larger units in a vertical structure.  Think compounds > molecules > atoms.

Examples:

• On your desktop, a file is nested in a folder
• In Slite, a doc is nested in a channel
• In Github, files are stored in a working tree in a repository

A big advantage of hierarchical design is that there is a pre-determined ranking system for your information units. Everything slots into place, and things are easy to find.

Content-based design

Content-based design, (sometimes called graph-based design),  links related units of knowledge horizontally so that you can easily move from one discreet unit to another without ranking them in importance.

Examples:

• A discussion or announcement links to a doc that describes a project in detail.
• An email links to a calendar event links to a Zoom window.
• A published article links to another article published on the same site, or to an article published on another site.

One of the advantages of content-based design is that you can more easily change the relationship between units of information without breaking the entire architecture.

In Slite, Channels and Docs interact hierarchically, while Docs and Discussions interact based on the content of each.

We also have databases called Collections. Collections in Slite can include docs, discussions, people, and even other collections. Depending on the way you use a Collection, it can contain info that's hierarchical, content-based, or both.

Examples of info that's organized both by content and hierarchy:

• A backlog of feature requests - the requests are vertically connected to the backlog, but if one request presents related problems to another request, they can be linked horizontally.
• Your team intros are stored in a database and all include the same set of metadata. The intros are vertically connected to the collection, but can be sorted based on horizontal information that's provided across documents, such as country of residence.

In summary

When you combine hierarchical and content-based design in your knowledge base, you can quickly get an overview of all your team's documentation, while also creating connections between projects and pieces of information that evolve as your knowledge grows.

What to include in your company wiki?

A company wiki contains everything from processes and policies, to project docs to freelancer contracts and personal updates. Here are some ideas and examples to get you started.

Company culture & values

These should be the first things that every new hire reads, and the basis on which every decision is made. Your values outline what your company stands for, and your culture describes what it’s like to be part of the team.

It’s not easy to create a company culture code or a set of core values. These take significant work and internal reflection.

But they’re essential. If you can’t define your company’s fundamental beliefs, it’s going to be almost impossible to build the company you want.

Important company processes

The biggest practical benefit of having a company wiki is to be able to show everyone in the company how business is done. Employees don’t need to ask how to run a meeting or how to manage the CRM - it’s all there for them to see.

Make sure that every repeated company process is clearly explained. Even better, give examples that anyone can use whenever they need. A simple meeting minutes template or script for candidate interviews means that, if it’s an employee’s first time handling these tasks, they have a massive head start.

The product roadmap

‍

It’s easy to underestimate how much the long-term vision can mean to your staff. They’re all head-down working on their core tasks, and it’s not their job to worry about the next two, five, or ten years.

But you want to hire people who care about the future of the business. And you foster this by being transparent about the roadmap.

Put that roadmap where everyone can see it, comment, and give ideas. The more that each employee feels invested in it, the more committed they’ll be.

HR information

Of course, your wiki also needs to contain the day-to-day stuff that makes the company run smoothly. Administrative staff spend too much time fielding simple questions from the rest of the organization.

They shouldn’t have to constantly remind people how to log paid time off, where to send invoices, and how equity works.

How to make your company wiki not suck

A great wiki provides all the information necessary for you and your teammates to get your work done. Nothing more, nothing less. Unfortunately, most company wikis don’t work. In fact, the notion of wiki and handbook feels so outdated that Bonusly refers to their Employee Handbook as the Employee Un-Handbook.  In the handbook’s intro they explain:

“Everyone has had the experience of receiving a weighty tome full of policies, disclosures and legalese on the first day of work. (...) At Bonusly we like to be agile (lowercase 'a') about everything we do. In that spirit, our handbook lays out our values and guiding principles (and a small number of progressive policies) -- in an open-source document that’s easy to read and understand.”

They’re actively making sure to not fall in the all too common pitfalls of the company wiki. Let's refresh on those pain points from the top of this article. A wiki that sucks has:

1. Too much information
2. Information is not actionable
3. Not enough people contribute to the wiki
4. The wiki is boring.

On the other hand, a great company wiki is:

1. organized
2. transparent
3. actionable
4. engaging

If you've made it all the way down here, we might as well provide some tactical tips for using Slite to get the most out of your remote team wiki. Slite can help you stay on top of things with the following features.

Organize with Channels, Docs, Collections, and Smart Tables

The main units of information in Slite are Channels, Docs, Collections and Smart Tables. While we love flexibility, we've also made each immediately recognizable so it's clear what kind of information is being stored. Last but not least, all can be linked together - for navigation that follows directions, but makes room for discovery, too.

Default to transparency with shared docs and open analytics

Every Slite channel and doc is shared with the whole team by default, except the channel called "My Private Channel." By defaulting to transparency, teammates can read, write, decide and do at their own pace, without limits. At the same time, you can protect sensitive information by toggling each doc's permissions.

In addition to sharing wiki content with your team, you can also share your wiki's performance. Analytics show data like doc views, reactions, last updated, and most frequent contributors.

Make your words actionable with Discussions and Decisions

‍

Working remotely means messages are often lost in chat tools and email. Move work along by having Discussions next to your docs. Discussions must be closed with a decision, so that everyone is clear on the next steps forward.

Engage readers with visuals

Sometimes it's easier to get your message across without writing a word.  That's easy in Slite. Record a video directly in Slite, or embed a Loom or Youtube link. And if you want to draw out some thoughts, you can embed a Miro board, Figjam file, or sketch directly in Slite with Excalidraw. Programmers can include code snippets.

Our Editor contains dozens of [/] commands for you to explore your visual creativity and share your work with your team.

A team wiki is a team effort

The best way to ensure a company wiki's success is to include everyone in growing it. As much as we find hierarchical design useful, there shouldn't be a hierarchy of who gets to contribute. Everyone should feel comfortable working on the wiki from day 1, and tools like Slite make getting involved a breeze.