It can be difficult to know where to start when you’re first implementing an internal knowledge base. But building a culture of documentation is worth the effort.
To make the process simpler for you, we’ve put together some information on the most common Do’s and Don’ts to help point you in the right direction.
Don’t go it alone
Some people envision documentation as a “done by one, one and done” activity. One person – the founder or team lead, perhaps – writes down everything in one marathon session, and voila! You’re done with documentation forever, right?
Unfortunately, trying to write all your documentation in one fell swoop by yourself doesn’t work.
You’ll likely end up documenting information that isn’t actually important because you’re guessing at what your team needs to know to do their job.
Or you won’t have the same deep level of understanding as the person who works in a specific area every single day. With less knowledge, you’re likely to actually give a less useful answer than another one of your teammates can or even worse, give the wrong answer, which wastes teammates time and erodes trust in the knowledge base.
Meanwhile, the questions your teammates are actually asking to do their job aren’t getting answered or the answers aren’t detailed enough to be useful.
Do this instead
Documentation is an ongoing, collaborative process. Instead of guessing, you should let your team surface what answers would be the most valuable for them to know based off their actual questions.
Your knowledge base is a living resource; not a static repository of company information that never changes. To treat it as such, you’ll need to get all your knowledge holders involved to make sure the best answers are captured and shared quickly.
You’re never quite “done” either, since processes are always changing and your team is always learning new ways to be more efficient. Every one of the knowledge holders on your team should make a tiny investment in the knowledge base every day, which over time will lead to big results.
Getting other teammates involved from the beginning will also create a senes of ownership among more people in your organization. Having more people to champion using your new knowledge base will make it more likely to stick.
Don’t let “perfect” get in the way of “good”
“A good plan violently executed now is better than a perfect plan executed next week.”General George S. Patton
Trying to write the perfect page can very quickly turn into knowledge-sharing paralysis. When you’re first creating an internal knowledge base, it’s natural to want to show your best work before inviting others.
This tendency will cause you more headaches in the long run, though. First, it creates bottlenecks for teammates who need an answer quickly. Second, if you try to optimize every page, you’ll likely run out of steam before you actually launch your IKB or even worse, by the time you’re done, the answers you wrote first will be out of date.
If you’ve already launched your knowledge base, this urge can also cause you to lock down ‘perfect’ pages rather than encouraging the rest of the team to update/edit docs as processes change. This defeats the purpose of having a growing and evolving loop of knowledge that your entire team has a hand in.
Do this instead
The reality is your knowledge base will never be 100% perfect. Most answers and processes are subject to change pretty quickly too. If you wait to push out an answer or page, it’ll likely get out of date before you even hit publish.
Even if your first pages are less than perfect, publishing them anyway will open the floor for collaboration and help others add their own knowledge. Sharing early and often will ensure your knowledge base starts to populate with helpful information from day one.
Keep in mind this is an ongoing process too. As questions get asked, you’ll know which answers need to be improved because they’re actually being used. This will help you make sure you’re investing time into the answers that matter most.
Don’t keep your knowledge in a silo
Remember that age old adage: if a tree falls in the woods but no one is around to hear it, does it make a sound?
Knowledge is no different. If you have knowledge captured, but it isn’t easily usable in the context of a conversation where questions are asked, then it might as well not even exist.
Whether it’s through lack of knowledge or anxiety about integrating with other tools, teams can often run into roadblocks when they don’t integrate with the tools that their teams are already using to communicate.
If you don’t integrate with these tools (think Slack, Google, GitHub, etc.), your knowledge will most likely exist in a silo. Practically speaking, your employees will be less likely to check the internal knowledge base before asking a question, which results in answers being thrown into chat streams or repetitive questions.
Do this instead
Your team will start to rely more on your knowledge base if they can easily access it while having conversations. Also, if the interface is familiar (e.g. using a slash command in Slack) and you can reference content in other systems instead of recreating it, that means that your team doesn’t have to learn yet another tool and can reuse the information they already have.
With Tettra, you can connect your IKB search for answers in your internal knowledge base right inside of Slack, reference other project management milestones like Issues in GitHub, and help your team members sign in through SSO with G Suite.
By demonstrating that Tettra plays well with these heavily-used-and-useful tools, your team members will be more likely to use Tettra on a day-to-day basis. We’ll show you how to connect your integrations in a later lesson.
- Make a list of the teammates you plan to invite to your internal knowledge base