Nailing the basics of team knowledge management

Whether you are setting up your company’s formal knowledge management for the first time, trying to upgrade a just-okay system, or overhauling how your company captures and stores knowledge in order to scale, we know it’s not easy to choose which type of knowledge management system you really need. If you properly think through your needs and choose right from the beginning, it will be easier to grow without a constant need to migrate to another system.

‍
In this guide, we will outline three major ways of leveraging knowledge management: knowledge bases, company wikis and company handbooks. We will go over some of the pros and cons of each to help you understand how to build good knowledge management in your workplace.

‍

Understanding the factors of knowledge management methods

Here are three criteria we will be discussing for each method:

• Ownership and maintenance: who can contribute? When will they do so? How do we know information is accurate and up to date? Who is responsible for deleting things? How collaborative is the effort?
• Workflow: When will we use it? What will we use it for?
• Organization: how will we make sense of ever-growing knowledge? Will we be able to find things when we need them? Will navigation be intuitive? Will people understand the right place to add new information? Will it scale?

Knowledge bases

“Knowledge base” is a term that encompasses many ways to capture and store team knowledge. They are the umbrella that holds both company handbooks and wikis. But they are also a larger way of managing knowledge in their own right.

A knowledge base is where both canonical and emerging knowledge should be captured and maintained. It should be the hub for any handbooks and wikis, but also for decision-making, note-taking for key meetings, and even private pages where employees brainstorm or draft before adding materials the entire team can see. They should have integrations to push and pull information from other compatible team software and should be a living touchpoint.

• Ownership and maintenance: Anyone can and should contribute to a knowledge base, but knowledge bases should be a mix of ad-hoc work and structured ownership. People should be empowered to create as the need arises, and there should be more formal designation for who is in charge of certain pages.
• Workflow: Knowledge bases should integrate into a team’s workflow by balancing being a place for dedicated knowledge storage and being a place that team members can actively work in, for example by taking meeting notes. Team members should be in a knowledge base daily.
• Organization: Knowledge bases are structured, but still have room for flexibility of architecture. For example, there may be a few rigidly structured handbooks in a knowledge base, as well as a place for collaborating on emerging knowledge, for example updated brand positioning. Pages can and should have a tagging system, expiry dates, and collaborative tools like comments to keep discussion and creation relatively neat. A robust search system, or AI-powered tool like Ask, is also a feature you should look for in any knowledge base.

‍

Who is it for?‍

Smaller teams, mid-sized teams and enterprises can all benefit from knowledge bases, so long as proper attention is paid to continuously adding to and maintaining the system. If your team is large or fast-growing, it is worth considering dedicating one or multiple employees to managing your knowledge base and implementing good information architecture. Mid-sized or slower-growing teams can often forgo these positions so long as ownership and contribution expectations are clear.

Company wikis

Company wikis are the same as any other wikis but used in the company context. They are online spaces which grow as the company grows, with material being added as needed. This can lead to them being sprawling, as people continuously add new information. Their architecture is not fixed and can reflect the way a team or company processes information, which can be good for small and highly-organized teams, but can become unwieldy for larger companies, especially as wikis tend to be relatively static and hard to reorganize.

• Ownership and maintenance: Anyone can add to a company wiki or make changes to a wiki page. There may be time stamps or a log to see changes created in documents so users can investigate what is up to date or not, but wikis are not usually centrally run or delegated. Pages tend to be static and represent only canonical knowledge.
• Workflow: Smaller companies may be able to create rudimentary wikis in a docs tool, but more specialized tools are needed to scale. (We recommend you start with a dedicated software right away to avoid having to migrate information.) Wikis are usually accessed when people need information or when they want to add information, but aren’t designed to continuously capture knowledge creation like a knowledge base.
• Organization: Creating structure in a wiki is one of the greatest challenges. Because anyone can add information and there is no obvious overarching framework, material can be harder to find and easier to duplicate. Teams should agree internally on organizing principles, and companies should look for robust search features, even if they’re just starting on their knowledge management journey and are on a small team.

‍

Who is it for?

Smaller and slower-growing teams with strong cultures of learning and autonomy are the best fit for using company wikis as their primary form of knowledge management. Scaling wikis up can be difficult due to their diffuse ownership and malleable organization, but wikis can remain useful if properly maintained and paired with more flexible features of a larger knowledge base. Wikis can also serve as external-facing data, such as troubleshooting or help docs.

Company handbooks

Company handbooks are relatively static documents which store knowledge and procedures of a specific function of your company in one central place. For example, different handbooks might contain operational details about hiring, an onboarding guide, procurement rules, or brand style guidelines. They may make up part of a team wiki or part of a knowledge base, but differ from wikis because they are not typically open for anyone to add to or edit. Handbooks represent the most solidified parts of team knowledge and work best for procedures like procurement, which do not change quickly.

• Ownership and maintenance: Handbooks are a collective effort by representatives from each part of the company who gather information for and create relevant entries in their specialty. They may be updated once or up to a few times a year by designated people.
• Workflow: Employees use handbooks as they would a reference guidebook. They will open it when they have a question, but not integrate it as part of their personal workflow or knowledge storage.
• Organization: Think of the organization of a company handbook like a textbook or a site map, with specific, siloed sections for different information.

‍

Who is it for?

Handbooks can be beneficial for any company, but extensive and rigorously thorough company handbooks are mostly reserved for enterprise corporations which can dedicate the resources to maintenance. Fast-growing companies, companies with relatively fewer employees and companies who cannot dedicate a team to creating and maintaining a handbook can use handbooks sparingly and use a wiki and/or knowledge base for more changeable or emerging knowledge or protocols.

Help knowledge grow with your company

Your team needs a purpose-built knowledge base and Slite’s approach is to give you a flexible space that can cater to whatever needs your company has while also providing the architecture for something that’s beautiful, a joy to use, and easier to maintain. From text to video, code snippets to comment threads, Slite integrates into your team’s workflow to help you grow your knowledge as you grow your company. Slite offers a set of features that can help you build everything from live knowledge capture every day to more static handbooks to wikis and will scale from your first to your 10,000th employee.