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.
Your team uses a company wiki to store and share information. It’s collaborative, secure, customizable, and ensures knowledge transparency.
The benefits of a company wiki are:
Easy Access to Information for Everyone:
Equality in Knowledge Sharing:
A Reliable, Central Information Source:
Always Updating and Improving:
Promotes a Learning and Sharing Culture:
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.
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:
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.
A company wiki that doesn't suck, on the other hand, is the following:
But when — and how? — do you start to build it?
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.
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 nests smaller units of knowledge within larger units in a vertical structure. Think compounds > molecules > atoms.
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, (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.
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:
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.
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.
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.
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.
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.
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.
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:
On the other hand, a great company wiki is:
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.
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.
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.
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:
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.
Including videos in your company's knowledge base enhances its effectiveness and user experience. Here are some reasons why it's beneficial:
For example, these are some of the ways our customers have been using Slite’s new AI features:
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.
You can have:
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.
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:
Collaboration and engagement:
Transparency and accessibility:
Content creation and enrichment:
Remember, it's not just about features:
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.
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.
Ishaan Gupta is a writer at Slite. He doom scrolls for research and geeks out on all things creativity. Send him nice Substack articles to be on his good side.
Aron Leah is an illustrator and designer, who can usually be found thinking up new ways to clear his mind over a cup of coffee and has yet to realise the irony in that. His work is informed by an enthusiasm for uncovering meaning and emotion to develop ideas.