After years of observing how people build (and abandon) knowledge management systems, there is a set of mistakes that repeat with almost comedic regularity. They are not mistakes of intelligence or discipline. They are mistakes of design and expectations.
Knowing them in advance does not guarantee avoiding them, but it does considerably reduce the probability of falling into them.
Mistake 1: Starting with the tool
The most frequent and most costly mistake. The person discovers that Obsidian exists, or Notion, or Roam, gets excited, spends hours configuring the perfect system, and six weeks later abandons it because “it does not fit”.
The problem was not the tool. The problem is that they started with the tool without being clear about what they wanted to achieve or what their organisational principles were.
The cure: first define what types of knowledge you need to manage, for what purpose, and what workflow best fits your life. Then choose the simplest tool that covers those needs.
Mistake 2: Saving without processing
Anxious accumulation: saving articles, books, videos and links with the intention of “processing them later”. That “later” rarely arrives.
The result is a system full of unprocessed material that generates guilt every time you look at it. And because it generates guilt, you look at it less and less, until you stop looking at it at all.
The cure: impose a limit on what enters unprocessed. When the inbox exceeds a reasonable number of unprocessed elements (say, twenty), stop capturing and process before continuing.
Mistake 3: Seeking the perfect system
System perfectionism: spending more time optimising the structure than using it. Reorganising notes every few months. Switching tools every time a new one appears. Spending hours designing a taxonomy that is then not applied.
This form of procrastination is especially tricky because it feels like productive work. It is not.
The cure: accept that the current system is provisional and good enough. Commit to using it for at least three months before considering structural changes. Evaluate based on actual use, not theoretical potential.
Mistake 4: Too many categories
Starting with three categories and ending up with forty. Creating a subfolder for each new thing. Having a tag system that nobody — not even you — fully understands.
Structural complexity is not a sign of intelligence. It is a sign that the system is trying to solve a problem it cannot solve: the unpredictability of knowledge.
The cure: limit the number of main categories. If you have more than five or six first-level categories, you probably have too many. Merge, delete, simplify.
Mistake 5: Notes written as if for others
Taking notes with the style and level of detail you would use if you were going to publish or share them. This has two negative effects: first, it makes note-taking more costly (you have to think about presentation as well as content). Second, it makes notes less useful for you (they are written for a generic reader, not for the specific you who is going to use them).
The cure: write for yourself. Use abbreviations you understand. Assume the context you already have. Notes are thinking tools, not communication documents.
Mistake 6: No review
A system without review is a dead system. Notes accumulate, the inbox grows, completed projects are not closed, and over time the system becomes a historical archive that is never consulted.
Review is what keeps the system alive: it converts accumulated material into active knowledge, identifies what is no longer relevant, and keeps the system aligned with what you are doing now.
The cure: institutionalise the weekly review. Put it in the calendar like any other important meeting. Thirty minutes a week is enough for most systems.
Mistake 7: A system that produces no output
The quietest mistake: having a very elaborate system that never produces anything. Many notes go in, few or none come out.
A knowledge management system that contributes nothing to your writing, your decisions, your projects, your conversation, is not fulfilling its function. It is an end in itself, and means that become ends are a trap.
The cure: explicitly connect your system with your outputs. When you start writing something, search the system. When you complete a project, extract the learnings to the system. When you make an important decision, consult the system. The system must be integrated into your workflow, not separate from it.
In the final chapter of the course we talk about the most important perspective of all: your system as something living, constantly evolving, that grows with you.