Ask HN: How do you manage your companies knowledge base?

I feel we've been in the same spot as you. We had a wiki (google sites and google drive with a lot of documents) but information would become inaccessible from time to time, to the point it was pretty much useless. We eventually understood that the knowledge sharing/maintenance was simply being an extra step in our work, a mostly disregarded one, almost an after thought.

What we did was to put knowledge at the center stage, make it as easy as possible, pleasant to maintain, and avoid at all costs new/extra tools. We eventually settled for Notion. I'm sure you can find about notion benefits on your own, but essentially it does all that. It's super intuitive, easy and beautiful, easy to get around (albeit sometimes slow). Get everthing in the same place as much as possible, with every new tool you'll loose out (knowledge bits here and there, extra connections that stop working, or that people don't bother to check)

But getting a good information platform was only half of the story. We needed to start thinking and working differently. We decided that if we ever make a decision, or arrive at a conclusion, that's worth sharing, then it should be worth writing. And it's by doing this, and expecting all other team members to do it as well, that we arrive at this stage.

I'm sure this doesn't work for all teams, and other teams probably arrived at other, even better solutions, but this was what worked (wonders) for us.

I've always found that wikis are too far from the code.

To have any chance of being up to date, knowledge of the code and functionality should be as close from the code as possible.

Old style - an "intranet" wiki that is linked to from the main internal company page. No orphaned articles - each needs to fit in the hierarchy somehow that is obviously quite flexible. Searching is easy and gives instant results. As opposed to the current version of Google, you can use search operators and they work as expected. Because managers embraced it and encourage their reports to (actively) use it, it works - most of the time.

The biggest challenge is outdated information: since the responsibility is shared, sometimes I come across articles that haven't been updated since 2011 - for example, because somebody left, and I see some bits aren't up to date anymore. But I feel uneasy about deleting the article or just doing anything about it unless it's one of "my own" or directly related to my department. But in spite of that, I think it's working quite well overall. I used Confluence in another company and it felt too invasive and in the end nobody used it.

I was thinking about using https://obsidian.md with a shared file on Google Drive, but still didn't try it.

We’re using the good old SharePoint with a lot of word / PowerPoint in it. Actually PowerPoint is really nice to describe different aspect of the same object. One slide per topic.

Everyone can search for it online, or un MS Teams. It’s versioned and everything.

We can easily export to markdown or even reveal.js (for ppt) using pandoc.

Once you get over your personal dislike of Word, honestly it works quite well!

The tech might not like it at first, but it’s waaaay easier to onboard non tech people into writing docs.

I've not tried this at scale so it remains theory for me, but at a previous company, I proposed that we tackle this problem in the same way medical literature is managed by health organisations. That is, every page is owned and every page has an expiry: when a page expires, the owners are obligated to review it. The "yikes" part of that idea is that it feels burdensome, but that's because retaining and managing knowledge is burdensome and businesses should be measuring knowledge as an asset (or liability) and budgeting accordingly.

Ultimately, most people are digital maximalists when they'd be better off being digital minimalists. I (in my personal life and in the small teams I work with) purposefully delete things that I do not wish to accept the burden of owning. Either something is important enough to justify the burden of ensuring it's accurate, or it isn't and it is deleted.

I have found that thinking about documentation in these terms, it becomes clear what to document and what not to document, and it forces better practices elsewhere in the business -- like writing code that clearly communicates the why, or designing business processes that leverage a core set of business information.

The Diátaxis documentation framework is one I heard about recently, Ubuntu/Canonical are switching to it:

https://diataxis.fr/ https://ubuntu.com//blog/the-future-of-documentation-at-cano...

We are building a tool that can help you tackle some of this pain through process visualization. Built to be easy to use and create alignment across teams on how different aspects of your business works. Check us out! https://shiftx.com

All the business knowledge is in Basecamp as that's where all the "work planning" is done. If you want to find out how a specific feature works, or how the decisions were made for that, go find the project in Basecamp, it'll be archived if it's shipped but it's still searchable.

For new dev setup/infrastructure stuff we use a github Wiki and the new starters point out issues in that for us - their first tasks are to update it if they find issues or missing info because it forces them to go and dig around to find the knowledge islands - they're the best people for it because it's who we want to solve the problem for.

Admittedly we've got a small company and a nice tight tech stack but there's still tribal knowledge in 2-3 people's heads and distilling that out to the team is a slow process of pair programming and explanation.

This is the exact problem I'm trying to solve with my startup https://GainKnowHow.com .

I think we have been structuring documentation ineffectively for a while. GainKnowHow structures knowledge by prerequisites in a Knowledge Web, which I think is the best way to figure out how something works.

My goal is to let you "program" your organization through skills in a Knowledge Web that represents how your organization runs. You can write tests to see if employees actually understand their skills and there are change management features that tell the relevant employees when a skill has changed through skill diffs.

Here's an example of how to train your software engineers https://gainknowhow.com/software-companies.html

For my team, it is Github + Slack + Google Drive. Most of the ongoing discussion/planning is on slack which we try to maximize by adding each activity we can there including screenshots of imp conversations, ideas and decisions made. We store all the work including creative output and more structured plans/data on company-wide shared Google Drive. Github stores all the code base and product documentation.

I use Obsidian for my own notes that only live on my machine, then they bake there for a while until they get refined enough to turn it into something that others can read in which case it gets published within Confluence.

Personally I'd rather see a knowledge base that is in pure Markdown, perhaps a static site that auto-publishes on push to a specific repo. I just like the idea of being in control of the text, plus it means you can write these docs in the comfort of your editor instead of using a slow web UI. Right now I end up writing it offline and copy / pasting it along with formatting it in Confluence afterwards, it feels like a little wasted effort.

We try to reserve these types of docs to be guides, it's more like blog posts not so much a detailed instruction list on how to use some library or app. This way they don't really get outdated because a library or step changed.

I'm a big fan of never deleting guides and notes though, for the not needed ones I'd still keep them around but maybe move them into an archive section. Really, a static site generator has all of the tools to make a really nice system for this. You could also spend a day to make a little back-end to offer full text search too.

Started releasing https://www.waybook.com recently. It's initially aimed at onboarding, but turns out lots of folks like it for the structure it defines. Used Confluence before and things just got lost in a folder in a folder in a folder.

We (Grafana) are just about to roll out https://www.simpplr.com/ internally.

We've been using a mix of tools until now, Guru, Google Docs... but have lacked discoverability, powerful search, and in Google the ability to create sites for teams, etc.

Personally I use Obsidian and the files are sync'd via Syncthing.

What I wish would exist: A markdown driven wiki with Git (or something like it) in the backend so that you can clone the info locally, or refer to the master version, and even stage big changes to an area, etc. - basically something halfway between Obsidian and Confluence I guess.

  > A markdown driven wiki with Git

  $ cat ~/Notes/sync.sh 
  #!/usr/bin/env bash
  git add *
  git commit -am "$(hostname)"
  git pull
  git push
  echo ''
  git status

For some documentation we are using https://www.bookstackapp.com/ , we have also few instances for clients internal docs.

What is especially nice (less for us, more for some of clients) is that it has clear, understandable and working out of the box ACL system in place - and this is not obvious or easy to setup/configure for many wiki-like projects out there.

For maintenance and filling knowledge-base - I think that what's works for us is establishing and following rules, for example: one cannot mark feature as complete without creating/updating documentation page related to it, documentation maintenance is checklist element of task completion flow.

We use notion (https://www.notion.so/) but the tool itself doesn't really matter. Confluence, Notion, Basecamp, etc. We're a team of 20 people right now, and _everything_ lives in Notion. No "look at this google doc" or "go to <vendor>'s website", it lives in Notion. We can link to external vendors for "live" content, but PDFs are embedded, samples are zipped, etc.

Each page has an owner, a contact, and an expiry date. Owner is responsible for keeping it up to date, and if you see a page that is expired you can ping the owner (unfortunately we don't have "alert on expired page" yet). If the owner is unavailable, the backup should be able to answer any queries/update the page, and if they can't then the failure of that lies on the page owner. There are a few pages that have empty backups, by virtue of our company size, but all the critical stuff has an owner, backup and is checked once every month or two.

We went with Notion and while it's a Jack of all trades (it can be a wiki, a database, a public-facing web, an issue tracker, or a combination of everything at the same time), and needs a bit getting used to, we haven't regretted it and find the wide array of features very useful.

I advocate rotating roles, and having an operational doc, the trick being people have to repeatedly read and update the operational doc to fill the role they have just been assigned.

Mandating the doc stays up to date when noone is actively using it is an exercise in time wasting

The problem you are facing is the weakness of having individual specialists. The problem is not the doc maintenance but organisational

> My problem is, I know that we are missing information, what I don't know is how to tease out that information from myself and other coworkers.

I would start by reflecting on the way in which getting that knowledge out of the coworkers into the knowledge base is incentivized.

I keep my notes in markdown files. A lot of my coworkers use Obsidian, CherryNotes, OneNote, and I'm sure that there's a dozen other solutions out there. Keeping notes locally is actively encouraged by the fact you can't rely on the Confluence server to be up after business hours and the fact that the centralized knowledge base upgrades destroyed our documentation efforts twice over the past 10 years.

I also keep my notes short, omitting everything that's obvious to me. This makes them less valuable when it comes to knowledge sharing, but makes them better for me - short notes mean less visual noise to filter out. Writing a version of those notes that's more comprehensive is extra effort. That extra effort needs to be visible, treated as 'real work', encouraged and valued. Otherwise, I will prioritize other tasks that are visible, treated as 'real work', encouraged and valued.

The first thing I would worry about is making sure the central knowledge repository is as convenient as the local notes. Then, I would examine if creating / updating documentation in the central repository is encouraged, and in what way.

My BSc thesis was about knowledge management and this subject has always got my attention when it comes up. I work for an infrastructure consultancy company which employs 300+ engineers/consultants/architects over a wide range of customers. The main issue is what I call the "content versus context" problem. For example: A new engineer comes in and has a basic skill of a certain technology. Let's say he/she is well educated in Cisco routing and switching technologies. So the "content" of a certain technology space should be no problem. The challenge is the context: How does "skillset x/y/z apply to customer x/y/z" in which the specific customer operates in a certain context with its own constraints etc. In the aforementioned example: How does customer x/y/z uses Cisco technologies in what kind of architecture serving which specific services? The context is key and exploiting (in the positive sense) this knowledge is what you typically strive for to get employees up to speed with a new customer. The issue is (what you describe) how to make this contextual knowledge tangible and searchable in the least frictionless way. Within my shop there were different trains of thought:

1. Using fileshares grouped by customer (but this needed updating and not all employees uses those shares to file their work. Let alone the fact that sometimes it is not permitted to store confidential stuff on our own fileshares. We also do defense contracting work so that is a big no-no) 2. wiki's (already mentioned here), but this needed constant updating and for some the actual "coding" and using the markup language of a wiki was too much of a boundary 3. Using Yammer/Slack etc. This works OK as it is pretty low level, but it needs a certain critical mass to use and when you have 300+ employees with all kinds of customers who might also use their own Slack/Yammer what-have-you it's hard to get the employees conditioned to also check the internal channels each day/week.

We finale settled at the following mechanism which is a nice starting point to solve the "content/context" problem namely using the resumes each employee has to keep updated (and fiercely enforced by HR) and using a smart search algorithm to find the best knowledge-match of each employee. It doesn't work flawlessly and it had to be customized for us, but it works better than other methods. It's still a two step approach:

1. Search the CV for the best content-context match 2. Call/mail/IM the colleague and try to figure out if his/her knowledge helps you in tackling the issue you have.

Another method I saw someone use (and apply within a large online retailer) is to "tag" each person with his own knowledge set and visualize the links between them. So, again using my field of work as an example: Bob has a lot of knowledge (explicit in the form of certs etc.) of Palo Alto firewalls and is considered the internal "guru" in this specific field. The more Bob gets consulted for his knowledge the larger his "circle" of knowledge is (you can actually visualize this). What you eventually build is a knowledge graph were each point in the graph represents an employee with a certain knowledge set and every time he/she gets consulted for that specific knowledge by another employee a line is formed. This is a very powerful system but requires maintenance to update the knowledge sets. Setting this up requires interviewing each employee with questions like:

- What is your skillset and how do you score on a scale of 1-5 (or whatever scale one sees fit) in this specific set? - Who consults you the most for this knowledge set? - Who do you consult the most for which knowledge?

The end result is the aforementioned "chart" with "dots" representing ones knowledge. The larger the dot/circle the more knowledge one has.

If you are searching for a way to make docs more accessible to everyone and publish them as a knowldge base website for your users check out notaku.website/product/docs

It takes Notion content and generates a docs website

I am the creator of this tool so don’t hesitate to give me any feedback

We use Nuclino: https://www.nuclino.com/

The startup I'm working on right now is actively trying to solve this problem.

https://workpilot.io The platform is part wiki/ part proċess management tool. After lot's of user discussions it became apparent that lots of business know how falls into those two categories. With the latter being easier to reuse and track.

I have a strict rule, anytime someone asks me a question I respond by checking the documentation for that, and writing or fixing it as needed. Once I think the documentation is correct I tell them how to find it, and ask them to tell me where something doesn't make sense so I can fix it.

As an expert I often think things are obvious that are not. So it takes a few rounds to make useful documentation.