My last 12 months have been spent thinking non-stop about knowledge management products and how they can be better.
Why do team knowledge hubs tend to become a dumping ground for incomplete/outdated information? Why is it so hard to create and share high quality documentation? How can I make sure people actually read what I wrote?
After a few failed prototypes and a lot of interviews with engineers, PMs, founders, ect., I think I understand what a team knowledge hub should be — let me take you on a journey… without the music unfortunately.
- 👊 Down with the hierarchy
- 🧠 Knowledge lifecycle
- 👩⚖️ We need accountability
- 😑 Centralising knowledge is a fools errand
- 📖 Join me on the journey with Scribe
Down with the hierarchy
I’m sure you’ve all experienced it. You’ve taken the time to write up a document you hope will be useful only to realise it could belong in one of three different folders. So you pick the folder you believe it relates to the best and you move on.
Add up hundreds of these decisions from every member in your team and you now have an organised mess of a folder structure no one really understands.
Hierarchical folder structures are the enemy. They create disorganised silos of information and they give you no good way to draw connections between content. The rationale is that the folders act as waypoints to the information you need — but waypoints only work if you know what they are. Unfortunately in a team setting you aren’t the only one creating them!
We need to move away from this forced folder perspective and start building webs of knowledge instead that focus on building connections between content.
With this we don’t have to just have one path to a piece of knowledge, we can have many. We can even layer a tagging mechanism on top so you still have a way to easily group loosely related content.
If you are clued into the startup or knowledge management scene you have probably heard of Roam Research. They have really pushed this idea of having networked notes and it’s amazing what you can do with it. I truly believe this approach is the future of note taking.
Unfortunately whilst Roam is a powerhouse of a tool it can have a high barrier to entry and it isn’t tailored for a team setting. To really work in a team setting you absolutely need first class support for knowledge lifecycles and accountability.
How many times have you not been able to find the information you need when searching through your companies knowledge hub? The information in question was either:
- Missing completely
The problem is that knowledge hubs are treated as a place to write, store and organise documents. They aren’t focused on what happens before the content is written or after the content is published.
So what does this actually mean practically?
-> We should treat knowledge hubs less as a box to tick after the real work is done and more as a tool for asynchronous communication.
You should be able to post any question and have the relevant teams be notified. We should stop answering the same question over and over again in slack channels and instead answer it once in our knowledge hub. The beauty of this approach is that we would now have the ability to update our answer in a centralised way.
As for after the content is published, this is where the concept of a document lifecycle is crucial. Knowledge is rarely static and how up-to-date it is should be reflected in the status of the document housing it. There needs to be a mechanism to mark content as outdated or formally ask questions and have the answers be folded back into the content. Each one of these actions should in-turn affect the document status.
The key to making this work is for every piece of content to have an owner that is responsible for updating or deprecating the content over time.
We need accountability
I think this is one of the most crucial yet forgotten parts to having a functional knowledge hub. There is little to no accountability in products like Confluence or Notion. Sure you’ll be notified when someone mentions you or replies to one of your comments but there really isn’t the concept of a document owner who is ultimately responsible for the ongoing maintenance of that knowledge.
This is a problem. We need to know that when we ask a question of a document that there is someone responsible for answering. Ideally we should be able to have a team own a document to mitigate against the risk of someone leaving.
But what does it actually look like to own a document?
-> Each person would have a task list and whenever a document they or their team owns has a pending question they would be assigned a task — think of it like an internal inbox. This task list can even be extended upon, for example you could assign a task to your team members to read a specific document — this would go a long way towards helping disseminate knowledge.
Introducing accountability not only makes it significantly easier and more reliable to collaborate on and update documents but it gives everyone more visibility into what teams are working on. This is a really powerful idea when you start to combine it with the ability to connect documents.
Your company can start to document things holistically, capturing and grouping the knowledge of each team working on a particular product. You can start to break down the silos between teams internally.
Centralising knowledge is a fools errand
One of the things that surprised me the most when interviewing small to medium teams is how hard it was even at their size to get buy in on a tool from everyone. Everyone seemed to have their own preferences and habits, and there was little to no incentive for them to switch.
This meant that most teams didn’t just have one centralised store of knowledge, they had several. This is pretty much the worst thing you could do because everyone now has a partial view of the world.
Importing isn’t the answer here. Sure you may be able to import all the knowledge to one central system but without buy-in that central store will quickly become outdated, and I will bet any amount of money no one will be raising their hand to try and centralise it all a second time.
Unlike other tools that simply give you the ability to import or search over content from other systems, we need a product that treats these knowledge sources as first class citizens and acts as a layer on top. You should be able to sync with other knowledge sources so that you don’t have to use one central tool.
It’s a lot easier to enforce that everyone has to use a product that can be synced rather than enforcing the use of a single product. This is obviously easier said than done — but the important part is that it can be done.
I’ve been developing Scribe to solve each and every one of these issues. It’s still early days so a decent amount of what I’ve described is COMING SOON, but if you’ll entertain me I’ll give you a brief overview of what it has now and will have in the future.
What it has today
It removes this dated hierarchical structure and focuses on forming relationships between content (think of it like a web of knowledge).
For when you need to group pages we introduce collections. These are much more flexible than hierarchical folders:
- The same page can live in multiple collections.
- Collections don’t live inside other collections, they connect to them — This gives the ability to have multiple pathways to a piece of content.
Every piece of content you write in Scribe is private until shared. We make it simple to capture your thoughts, synthesise those thoughts into a curated piece of content that can be shared with your team when ready.
What it will soon have
- A task list for every team member
- The ability to create teams on the fly
- Request a piece of knowledge to be written
- Assign a document to be read by an individual or team
- Ask questions regarding a document
- Get feedback on a document before sharing
What it will have if I can get some paying customers/help
- Collaborative editing
- Sync knowledge from other tools
- Slack integration for answering questions
I believe Scribe can provide a whole new (and much better) approach to knowledge management for teams. If you are excited by this and want to be a part of the journey please sign up for beta access over at:
Scribe - A Second Brain for you and your team
Knowledge hubs have become a source of misery for many - often full of outdated and incomplete information. We think…
The next round of invites should be coming in the next few weeks or so!