Fighting the entropy of internal knowledge bases

The natural state of the universe is chaos: entropy tends to increase in closed systems, and there’s really nothing that we can do about that. So too is the nature of internal knowledge bases: unless action is taken to maintain order.

But what does this action look like?

To answer that, we first need to understand a fundamental truth about internal documentation — every document you write can fall into one of two categories:

• Type 1: A point-in-time document, that should lose relevance at some point. e.g. meeting notes, feature specs that get completed, feedback that gets addressed
• Type 2: A source of truth document, that should be maintained over time, e.g. “How work gets done at ". May also be referred to as "evergreen" content.

Few people recognize this distinction, and as a result, entropy increases:

• Members of a team tend to write type 1 documents, without thinking about the path to archive.
• Type 2 documents are rarely written since there’s never an immediate need for them.
• New employees join expecting to find type 2 documents, and instead are drowning in meeting notes, where it’s hard to gauge what’s relevant, find the information they are looking for, and get a sense of what’s going on in the organization.
• Information architecture is rarely thought about, since most team members treat their knowledge base as a note taking tool, rather than a system to organize type 2 documents.
• Your internal knowledge base becomes hard to navigate, until finally someone decides to migrate to a new tool, thinking it will fix the problem, until the cycle repeats itself.

The first step to fighting this entropy is to recognize whether the document you’re writing is type 1 or type 2.

If you’re writing a type 1 document, consider:

• Identify what milestone will move this to an archived state (it could be a date, or it could be a particular action)
• Enforcing metadata to capture a completed state (e.g. Notion’s databases feature can capture statuses)
• Using a simple system to identify questions, actions and completion. Personally, I use:
  • ❓: A question I have, which moves to ❔ when the question is answered
  • ‼️: An action to be done, which moves to ✅ when the action is resolved

  At a glance, I can tell whether a document has outstanding questions or actions based on the number of red emojis.

Then, encourage the writing of type 2 documents (which is not done enough!)

• When a new employee starts, consider: what are they looking at? What questions do they have, and is that documented?

In general:

• Enforce structure. Yes search is great, but search is only useful if you know what you’re looking for. Information architecture allows onboarding, wayfinding and discoverability.
• Be disciplined. Part of my shutdown routine is to review things I’ve created that day, and make sure I’ve closed the loop on each item.
• Archive, archive, archive.

And finally, stop blaming your tools for this entropy.

But if you are working on a note taking tool, here’s some ideas on how a tool might help with this battle:

• Create a distinction between the two types of documents
• Display date metadata as default (to help people understand whether something is likely outdated)
• Build in a path to archive objects
• Let admins enforce rules about structure and required metadata
• Make it easier to audit and archive unused content

---

Corollaries of this framing:

• Data analyses also have this inherent property, but we don’t think about it enough

• The corollary in version control would be:
  • Type 1: PR writeups, commit messages
  • Type 2: the README
• Issue writing in product management:
  • Type 1: Comments on an issue
  • Type 2: The issue body should stay the source of truth — someone shouldn’t have to rely on the comments to understand the latest version of something (unfortunately this is not always adhered to)