It can be difficult to know where to start when you’re first building your internal knowledge base. To make the process simpler for you, we’ve put together some of the most common pitfalls when getting set up with Tettra.
Some people envision documentation as a “done by one, one and done” activity. One person – the founder or team lead – writes down everything in one marathon session, and voila! You’re done with documentation forever, right?
Unfortunately, trying to write all your documentation yourself in one fell swoop by yourself doesn’t work for a few reasons:
This means the questions your teammates are asking to do their job aren’t getting answered or the answers aren’t detailed enough to be useful.
It's important to get your team involved with documentation to make sure your knowledge base is continually updated with the most important answers.
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. A great 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.
“A good plan violently executed now is better than a perfect plan executed next week.”
General George S. Patton
When you’re first creating an internal knowledge base, it’s natural to want to show your best work before inviting others. However, this tendency will cause you more headaches in the long run.
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.
As soon as you’ve created an answer with even an iota useful information, publish it.
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.
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.
Your team will start to rely more on your knowledge base if they can easily access it while having conversations in Slack or MS Teams. 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 also pull documents from the tools your team is already using like G Suite or Notion for answers into your internal knowledge to answer questions.
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.
