Building Digital Knowledge Bases

A shared folder fails because contributing to it is a separate task from doing the work, and separate tasks lose. What survives is a knowledge base that people read, and people read what answers a question they have right now.

Three things change the outcome. Start from real questions rather than categories: the file is called what to do when a mentee has no bank account, not Financial Inclusion Resources. Give every entry an owner and a date it was last checked, so that a reader can tell whether it is still true. And keep it small on purpose, because a base of thirty accurate pages gets used and one of three hundred stale ones does not.

The habit that makes it self-sustaining is answering questions in writing. When a colleague asks you something in a corridor, write the answer in the knowledge base and send the link. It costs a few minutes more than replying and it is the only way the base grows out of work instead of alongside it.

That last one I can do. Does anything about mentee information belong in there, or should it stay completely separate?

Completely separate, and it is worth being strict about it because the two get mixed almost by accident.

A knowledge base holds general knowledge: how a process works, which service does what, a template, a thing that went wrong last time. Case records hold information about a person and carry data protection obligations, including retention rules and the mentee's right to see what you hold. The moment a named example goes into the shared base, the whole base becomes a personal data store with none of the controls around it.

The workable version is to write cases as anonymised patterns. Not what happened with a named woman, but the shape of the problem and what worked: a mentee whose permit depends on a spouse needs a legal referral before any advice about leaving a job. That is the useful part anyway, and it does not carry her with it.