How to build a company wiki that doesn't suck

Most company wikis never get used. This can help.

How to build a company wiki that doesn't suck

Most company wikis never get used. This can help.

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.

What is a company wiki?

Your team uses a company wiki to store and share information. It’s collaborative, secure, customizable, and ensures knowledge transparency.

Benefits of a company wiki

The benefits of a company wiki are:

Easy Access to Information for Everyone:

  • Breaks down barriers to information.
  • Makes sure important details aren't just stuck in emails or in someone's head.
  • Helps everyone see and use the same information.

Equality in Knowledge Sharing:

  • Puts new staff on the same level as long-time employees.
  • Helps the company move quickly and efficiently, like a small, agile startup.
  • Lets everyone add their knowledge and learn from others.

A Reliable, Central Information Source:

  • Acts as the go-to place for all company information.
  • Reduces mix-ups and gets everyone on the same page.
  • Keeps the company's main messages and rules in one place.

Always Updating and Improving:

  • Constantly changes and gets better as the company grows.
  • Reflects new learning and understanding within the company.
  • Works like a growing, evolving brain for the business.

Promotes a Learning and Sharing Culture:

  • Encourages a space where knowledge is shared and valued.
  • Makes teaching and learning an everyday part of work.
  • Strengthens the idea of sharing information openly.

Why do most company wikis suck?

Documentation doesn't suck because companies aren't using wikis right.

Documentation sucks because it's hard/impossible to do well. Every change to the code can trigger cascading changes in documentation and there's no compiler to tell you which things need to change.

- Hacker News

After years of working with teams as they create and then grow their internal 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 good 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?

You should start building a wiki from 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.

There are two ways to organize information in a wiki: 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 predetermined 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 discrete 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

The differences between, and advantages of, the two types of information design in a company wiki.

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

A snapshot of company values adapted from Front's website (front.com)

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

A wiki often contains how-to guides for standard practices, like Remote's Coding Guidelines (adapted from Remote.com)

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. And if you have the right internal links, they can easily deep dive into whatever interests them.

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. This is also a great place to store training materials, company policies, and employee onboarding details.

The product roadmap

Pardon the blurriness, but this is Slite's current strategy doc for 2022, stored in our own corporate wiki.

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. While product managers tend to write these in Confluence, they report having trouble with finding docs in Confluence. However, a product roadmap is a dynamic document that’s open to a lot of collaboration in the brain storming stage.

HR information

Gitlab has always been radically transparent with their wiki. They even share their PTO policy publicly.

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 internal knowledge bases 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. This way, 90% of our everyday writing becomes company-wide information.

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 Questions and Answers

Working remotely often 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. Here’s some more tips to improve your wiki writing:

  • Make content skimmable and scannable.
  • Add checklists, ordered lists, etc. to break long paragraphs.
  • Keep project management discussions away from your company wiki.
  • Keep adding new content regularly to relevant channels.

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 wiki pages 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.

Add video

Including videos in your company's knowledge base enhances its effectiveness and user experience. Here are some reasons why it's beneficial:

  1. Visual Demonstrations: Videos provide step-by-step visual demonstrations of complex processes, improving understanding and user guidance.
  2. Training and Onboarding: Videos simplify training and onboarding by offering consistent and thorough instruction for new employees.
  3. Product Walkthroughs: Videos showcase product features, benefits, and use cases, aiding in customer and team member comprehension.
  4. Troubleshooting and FAQs: Videos address common issues and FAQs, offering clear solutions and reducing confusion.
  5. Internal Communication: Videos create engaging and personal internal communication experiences, fostering connection within the organization.

Use AI

For example, these are some of the ways our customers have been using Slite’s new AI features:

  1. Summarize docs and improve their readability: Every doc in Slite workspaces has a readability score. It signals how scannable and digestible your doc is. Most importantly, it lets quickly get the score to 100 with a single click ‘Quick Improve’ feature.
  2. Retrieve answers from their browsers without opening Slite: Slite’s new Chrome extension helps our users get answers from trusted information from their knowledge base without even switching a tab.
  3. Quickly proofread and grammar check their docs: Slite’s editor has eliminated the need of Grammarly for many of our users and are able to directly perfect their first drafts within Slite.

No matter which knowledge management software you’re using, you’ll have some of these features within the app. All of these micro AI use cases go a long way in keeping your content fresh, and therefore, usable.

Hire a Knowledge Manager

You can have:

  • A great writing culture from day 1
  • A fast scaling team

And still fail to build a good company wiki. Why?

Company wikis get outdated very quickly. That’s because no one’s there to manage them once they grow too big for the COO to do themselves. If your company wiki sucks because it feels like a graveyard of docs no one uses, it needs a dedicated knowledge manager. Read more about it here.

Tips on using Slite as an effective company wiki

We’re building Slite to be the best wiki software for all companies. With Slite, you get several features that can make it a valuable tool for maintaining an effective company wiki. Here are some key ways companies can utilize Slite for this purpose:

Structure and organization:

  • Channels: Organize content into channels dedicated to specific departments, projects, or topics. This keeps information relevant and easy to find for the appropriate teams.
  • Smart Tables: Create tables to link documents, templates, and resources relevant to particular areas. This centralizes information and facilitates cross-team collaboration.
  • Document hierarchy: Nest pages within documents to create a logical structure for complex information.

Collaboration and engagement:

  • Real-time editing: Multiple users can edit documents simultaneously, fostering co-creation and ensuring everyone has access to the latest information.
  • @mentions and discussions: Facilitate communication and feedback within documents through mentions and threaded discussions.
  • Reactions and emoji: Encourage engagement and feedback with quick reactions and emoji.

Transparency and accessibility:

  • Open and shared by default: Documents are shared by default with the entire team, promoting information flow and transparency. Permissions can be adjusted for sensitive information.
  • Analytics and insights: Track doc views, reactions, and contributors to gauge usage and identify areas for improvement.
  • Search and indexing: Powerful search functionality allows users to easily find the information they need.

Content creation and enrichment:

  • Visual elements: Enhance content with images, videos, embeds, and code snippets to make information more engaging and digestible.
  • Rich formatting options: Utilize formatting options like headings, lists, and quotes to structure content and improve readability.
  • Templates and reusable blocks: Create and share templates for common documents like meeting notes, onboarding guides, or project plans.

Additional benefits:

  • Mobile-friendly: Access and edit documents from any device.
  • Integrations: Connect Slite with other tools like Slack, Google Drive, and Asana for seamless workflows.
  • Simple and intuitive interface: User-friendly interface makes adoption and navigation smooth.

Remember, it's not just about features:

  • Establish clear ownership and update processes: Who's responsible for maintaining different sections of the wiki? How often should information be reviewed and updated? Clear guidelines ensure consistency and quality.
  • Promote the wiki actively: Don't let your wiki become a ghost town! Encourage employees to use it as a resource, share their knowledge, and ask questions.
  • Gather feedback and iterate: Regularly check in with your team to see what's working and what's not. Adapt your approach based on their feedback to keep the wiki relevant and valuable.

Of course, the success of any wiki tool, including one on Slite, depends on factors beyond the platform itself. Companies should establish clear content ownership and update processes, encourage active participation, and promote the wiki as a valuable resource.

Conclusion

The key to building a company wiki that doesn't suck is simple:

Start writing from day one and make regular updates a priority.

The reason your company wiki may be lacking effectiveness is because it's not receiving the attention it deserves. By investing time and effort into keeping it up-to-date, your team will experience significant benefits. They will have access to accurate and current information, reducing the need for unnecessary meetings and enabling them to focus on productive work. A good company wiki is not just a task to check off; it's an investment in the collective productivity of your entire organization. So, commit to maintaining and curating your company wiki, and watch as it becomes a valuable resource that empowers your team and drives success.

You
Bring your team on the same page.
Discover Slite