Whether you use Notion, Confluence, Coda, Sharepoint, Google Drive or any other knowledge base tool. The first, and probably the most important question you will struggle with is, how do I choose the structure of the knowledge base, should I segment by team, by topic, by products, by types of documents? Don't worry if you don't have an answer for that. That's surprisingly a pretty difficult question.
Let's see the issues raised by structuring a knowledge base and then explaining what is the best way to do it.
Why you need to enforce a structure ?
The structure of a knowledge base, fit several needs:
- You want people to be familiar with the buckets they will need to use to search or to put their content
- You may want to have rights and access defined at the bucket level, instead of having users defining them at the document level
The first point is critical of any working knowledge base. If you fail at creating a structure that people understand, you will quickly get either people arguing "I can't find anything" or just not using your knowledge base at all. That's two things that you want to prevent as much as possible. The ideal thinking path for someone entering a knowledge base is "I understand this first level of folders. I pick this one. I understand this second level of folders. I pick this one. This is where I need to search or create my content". If people don't understand the structure they will do something like that "Oh it seems like the folder that I'm looking for. Hum well maybe not. Maybe this one then ? Errr where is this damn document? ". If most of people can't work with the structure you will probably end up in a situation in which only a few people act as librarians to find content for others and/or nobody creates content and your knowledge base stops being collaborative and only space of storage for a certain authority
The second point is about right management. Imagine if every time you need to create a meeting note for the weekly product management meeting, the tool ask yourself, who do you want to share that with ? You will probably answer something like that "Well with the product management team altogether". But when Jacob (or you in 10 days) will be asked the same question, he is going to answer, "Let's share it with the 3 individual people of the product management team". Then you end up with a situation in which even the same type of documents don't share the same access rights. The day you will want to make more people to access these documents, you won't be able to do so. For the same reason maybe, the person who creates the document doesn't know all the people who need to access this document. So that's why right management should be handled at the bucket level as much as possible, that will make anyone saves time when he creates a document, and gives much more flexibility. If a certain document needs a special access you can still modify the rights at the document level.
Should you let anyone be able to add folders ?
No. Of course no ! We know how most knowledge base end up. Most people can't find the documents they know exists so they just consider the KB as bag in which they put content. And to retrieve the link they will use tricks such as "I sent the link to X on slack 2 month ago, let me find it". At some point someone will tell himself "Well if nobody is using the KB, I will enforce my own intellectual schema, through folders of folders of folders that make sense for me, so that I can easily find anything I want" as a result this person will be super efficient at retrieving data, but nobody else will be able to use autonomously the KB. When this person will be on vacation of leave the company, there will be no chance to ask him to find content.
What you want to prevent is to have chaos in the structure of the KB. And always keep in mind that the structure is not here to help 2 people in the company to find information. But to help anyone retrieve content. If a structure is best for the "knowledge manager" but nobody else is able to retrieve content, then this is bad structure.
As a consequence you want to have the flattest structure as possible. It is better to have 100 documents in one folder than 100 documents in 30 folders. Because at least when there is no structure you are not tricked into search in the wrong folder
In most company the structure of the knowledge base should follow the organization chart
By default the best thing is to create one folder for each team, and nest those folders the same as the teams are nested to each other. This is the right approach because first it's very likely that most people know the different teams of their company. Don't try to outsmart yourself. Go simple. For example if you want to know about "How to create a new campaign on Mailchimp". Who do that usually ? "Mark". In which team is Mark ? "Marketing automation". Then put the document in "Marketing automation". And second rights are easy to define. As you can give rights to entire teams, it is easy to know which teams collaborate with other teams and what kind of access they need.
There are mostly 3 types of documentation if you categorize them by type of access:
- I need to access it and my team need to access it. This is basic. Put it in your team folder, this will automatically get the good rights
- I need to access it and someone out of my team need to access it. This is the tricky one. The thing you will want is that the content is both in the folder of your team and the folder of the team which need to access it. So if your tool offers the ability to link documents then do it !
- I need to access it and most of the company or a set of teams needs to be able to find it. That's a good use case in which you will want to create a new first level folder. Give this folder the good rights and start putting content inside it. But don't create a folder inside your team folder and let people try to find it, they will never find it. An example of that kind of content is "Company information", it would be a bad idea to define that content inside the People team folder, instead create a folder called "Company information" and allow the whole company to access it
In some company the organization chart doesn't offer a lot of value. For example in consulting firms, everyone is doing the same job. In that case it is a better idea to find a better structure, like by domain, by type of documents, by type of customers. Use has a delimiter the thing that you usually use as a delimiter in your company.
Other tips
-
Don't allow more than one level of folder inside a team folder. Trying to split big folders into smaller one is only going to help the person who defines the folders. And that will confuse all the other people. Don't do it, never
-
Don't allow everyone to see everything. If you give Salespeople an access to the Marketing folder. For any search that salespeople make the results of the Marketing folder will be shown even though it's very unlikely the content is relevant to its search. By giving access to more, you complexify the search and the content retrievable task. That could be a problem If you have a transparent culture and want anyone to be able to see everything.
-
Index content inside folders with non-structuring methods. For example by using tags (need to be defined centrally), using templates with attributes, ... you will probably be limited by the tool you use, check Dokkument if you feel so