A good knowledge base is a remote team's most valuable asset. What's more powerful than a company wiki that's accessible to everyone, owned by everyone, and improving all the time? 

Since knowledge is so valuable, it makes sense to have a role dedicated to maintaining it. Knowledge Managers are becoming more popular in high-growth remote teams (along with other operators, such as Head of Remote). But while hiring a knowledge manager may seem like a logical solution, it really takes the responsibility off subject matter experts.

‍

What is a knowledge manager?

A knowledge manager (KM) is a role specially designed for a team that relies on a knowledge base to document processes, onboard new employees, plan projects, and communicate strategy, among other things. The KM oversees the knowledge base, serving a team internally by creating a system in which knowledge is regularly shared and accessed.

‍

What are the knowledge needs of different size companies?

• 10-50 people - (most) everyone is senior at this size, so everyone's an expert. Experts own their documentation and share across departments.
• 50-100 people - At this size the company starts to get more stratified, with more diverse levels and learning needs. Experts share their knowledge with more junior people and across departments
• 100+ people - roles are so highly specialized that knowledge docs are all collaborative; no one person is the holder of all knowledge on a topic anymore. Knowledge must be shared within a team and across departments. This is the when a knowledge manager starts to be helpful.

‍

Why a knowledge manager is a Band-Aid

If the problem you're trying to solve is that key information is stored in a few people's brains, then a KM is just a Band-Aid.

As we've written about before, process is a superficial solution to deeper problems. Remote leaders need to solve for information accessibility and accountability - instead of nudging everyone to be responsible for the insights they contribute, responsibility is shifted to the generalist, who by default will not manage the information as well, because it's not organic to them.

A better solution is a set of guiding principles and a toolkit that makes knowledge sharing easy and efficient. For instance:

• Writing an internal handbook to using your knowledge base - start with the Slite Guide to Building a Team Wiki.
• Getting a knowledge base software specifically designed for internal use
• Using a set of templates for repeating documents
• Onboarding new hires in the knowledge base itself
• Make documents transparent by default, so feedback is taken and given freely.
• Standardize naming for documents and channels

These are not hard and fast rules. But they've worked for us.

Caveat

While a knowledge manager is not necessary, they can de-risk processes and contribute to stronger organizations – they are big-picture thinkers, where experts can be too "in the weeds." This outsider perspective is very valuable when it comes to reducing noise in your knowledge base.

Useful knowledge comes directly from the source

It comes down to the precedent you want to set. Adding a knowledge manager is to immediately subscribe to top-down, hierarchical style, it's really a last resort, or a solution for a team whose knowledge is so vast that it requires someone to look after it, full-time. One of the benefits of having a knowledge base is to democratize knowledge. Building your knowledge base around self-ownership will encourage your team members to find their individual "zone of genius," and share it with everyone.