A knowledge management system is a database of important team information. This might include factual information like your wifi password, tacit knowledge like your team culture, or procedural information about how to perform a certain task.
Teams have different reasons for adopting knowledge management systems. Some might be growing fast and struggling to onboard new team members efficiently. Others pride themselves on their GSD culture and don’t want to be slowed down by meetings or time zone differences. Others simply like to punch above their weight and accomplish 10x what most teams of their size can accomplish.
When to Choose a Knowledge Management System
We’ve seen teams of one use Tettra successfully to document information and processes. We’ve also seen teams with dozens of employees limp along without one before adopting Tettra. If you’re wondering if and when you should adopt a knowledge management system, here are some signals to look out for:
- Your team is growing: are you adding a bunch of new people or doubling in size? If you’re in this kind of growth phase, there are opportunities to make your onboarding process better and more efficient.
- You’ve been repeating yourself a lot: telling people the same thing over and over again can grow tedious. Especially if you’re being interrupted in the middle of doing something else. By writing down the answer to a question the first time, you’ll reduce the number of times you have to repeat yourself.
- Information and documents are hard to find: Maybe you’re already leaning into documentation, (if so, well done!) Maybe you have information scattered within different Google Drive folders, Dropbox items, and Word docs. A knowledge management system can act as a hub for everything else, so you’re not wasting time searching for the info you need.
How to Choose a Solution
There’s no single option that’s going to be a perfect fit for every team’s documentation needs. The solution you choose should depend on how you plan to use it and what you prioritize. Here are some factors that should guide your choice:
How many people are on your team or in your department? Will everyone need access to your knowledge management system? Teams with thousands of people might prefer to opt for a solution with large enterprises in mind. Smaller teams of 15-150 people, let’s say, might be better off with a solution designed expressly for that size.
Level of complexity
Some teams need a lot of bells and whistles. Perhaps they have an unusual case is unusual or a massive team. Other companies prefer less complexity; complexity can feel overwhelming, and can make team members less comfortable sharing information. You might think bells and whistles are a good thing, but only implement what you actually need. You might gain complexity at the cost of actual team usage and usefulness.
Does your entire company need a knowledge management system or just one department? If it’s just your department, what unique requirements do you have? For example, if you’re part of a product or engineering team, you might need to be able to use code blocks within your documentation system. If you’re using it with your entire company and some sub-groups need to document sensitive information, you’ll need an advanced permissioning system.
Make sure you differentiate between nice-to-haves and need-to-haves. There are a lot of nice-to-haves when it comes to any kind of software, but start by seeking a solution that fits your use case and your true needs.
Last, solve for your current needs, and select the right tool for the job to be done. Oftentimes, people will reach out, asking if they can use Tettra for internal, as well as external documentation. Ie they want to use it to document team knowledge, but they also want to use it to build public support docs for their customers. Our answers generally run along the lines of “Well, sure, you could use Tettra in that way, but there are better tools out there for your customer support documentation.” If you try to kill too many birds with the same stone, you risk getting a suboptimal outcome for both use cases.
Integrations with other tools you use
The integrations you need are likely driven by your use case, as described above. After determining which groups need a knowledge management system, figure out whether they need specific integrations. For instance, Tettra is often used by founders, tech teams, and HR departments, so we’ve prioritized the integrations that these functional groups need, (like Slack, Google Docs, and GitHub.) If, on the other hand, your sales team needs a knowledge hub, you might prioritize a solution that integrates with Salesforce or HubSpot.
Not All Considerations are Created Equal
After you’ve taken inventory of your needs, try to pinpoint what’s most important to you. If you had to choose just one thing, what would it be? Ultimately, your biggest priority should drive whatever decision you make. Better that you nail it 100% on your most important requirement than get to 60% satisfaction on 50 different preferences.
Frequently, we see companies build a 50-row matrix of various features and functionalities. They try out countless knowledge management systems, adding checkmarks for each system, based on whether they have those features. Ironically, we tend to see these customers choosing another solution, using it for a few months, and then coming back to Tettra for the long haul.
This “matrix approach” to choosing software is dangerous because it puts one in the mindset that all 50 features are equally important. It might help you justify one choice over another with your manager, but it might also lead you to make a bad choice. Instead, there’s usually an 80/20 rule at play. The 80/20 rule (or Pareto principle) underscores that 80% of the time, we actually only need 20% of what we have.
In our humble opinion, simplicity and a straightforward user experience matter more than almost anything else. Roughly 80% of the time, you’ll be reading or writing documentation in your knowledge base. So those two actions need to be easy and pleasant. The other features we build are nice, sure, but they’re lower on the totem pole than a simple and elegant design. All other considerations take a backseat to this most important one, since it’ll determine if and how often people actually use Tettra.
Preparing for Launch
Once you’ve made your choice, prepare your team for launch. Create some basic structure by building categories. You don’t have to get these perfect, since they’re easy to adjust down the road. Build some basic pages with useful information on them. If you want to get really fancy, turn on some of our integrations, so that people on your team can get a feel for how to embed a Google Doc, for example.
Start inviting people early, and don’t fall into the trap of thinking you have to build out your entire wiki before sharing it with others. Don’t let the perfect get in the way of the good. Building up a knowledge base shouldn’t fall on just one person. Everyone’s an expert in something, so everyone has something to contribute.
When you start inviting people, direct them to a specific Tetra page that relates to the work they do. This helps orient them to the materials you most want them to see. Plus, it helps ensure that their first experience with Tettra is a good one, thereby increasing the odds they’ll contribute to and seek knowledge from Tettra.
After inviting people on your team, start making suggestions and assigning them to others on the team. If there’s a process that one person usually manages, ask him or her to document it. If you follow the same format for your weekly standups, ask someone on the team to jot down a few bullets about what that format looks like. Getting more people involved early helps everyone grow comfortable with the system.
Last, share context with your team about why you want to implement a knowledge management system. Give them details about how your team can use it to communicate with one another more easily. The more people understand the why and how of your decision, the more likely they are to support it with their own great knowledge. And the more likely you are to build a high-performance team via good documentation.
For more tips on implementation, take a look at our post, “How to Roll Out a Knowledge Management System,” and make sure you’re communicating the right things in the right way.