The counter-instinct: a team of three people doesn’t need a knowledge base. Everyone knows what’s happening. The problem is that “everyone knows” is only true at three people. By six, different pictures of how things work have already formed, and alignment is breaking down in ways no one has named.
The Team Knowledge Base is not a documentation project. It is the shared reference that replaces the owner as the primary source of operational truth. Without it, alignment requires constant owner involvement. With it, the team can answer most questions without involving the owner at all.
The Behavioral Values Document from How to Communicate Your Values in a Way That Actually Shapes Behavior tells the team how to behave. The Team Knowledge Base tells them how things work. Both are required for alignment. This article covers the second one.
Why Teams Lose Alignment as They Grow
The obvious problem: with three people, context travels naturally. Everyone is in the same conversations. Everyone knows what decisions are being made and why. Alignment is effortless because proximity is constant.
The less visible cost is what happens when the team grows past the point where proximity handles alignment automatically. New people don’t have the context that existing people carry. The existing team develops slightly different pictures of how things work as processes evolve. The owner makes decisions that the team doesn’t know about until the effects arrive.
The deepest problem is that misalignment is invisible until it causes friction. The two team members who handle the same client relationship using different approaches. The decision made at one end of the team that contradicts an assumption held at the other. Neither problem is visible until it creates a problem.
A knowledge base doesn’t create alignment. It gives alignment something to be built from: a shared reference that the team can check against.
The Team Knowledge Base
The knowledge base has four categories. Together they give the team a single source of reference for the things that come up most often.
Category 1 is how things work
This is the operational layer: which tools are used for what, how decisions get made, and the norms for communication and escalation.
The how-things-work document from Chapter 02 addressed individual roles. This category addresses the team as a whole. It answers the questions that arise between roles: where to go and how to ask when someone in one function needs something from another.
Category 2 is why decisions were made
Every team has a set of decisions in its history that shaped how it works today. Why the business uses one tool rather than another. Why a certain process works the way it does when a simpler approach would seem to make sense. Why a client relationship has specific handling requirements.
Without the context for these decisions, new team members make mistakes that experienced ones don’t. They choose the wrong tool because they didn’t know about the decision, or they approach a client relationship incorrectly because they didn’t know the history.
The decision record is short: what the decision was, why it was made, and what it replaced. One to three sentences per decision. A short record of twenty decisions is more valuable than a long explanation of three.
Category 3 is shared reference material
Every team has reference material that everyone should have access to but that currently lives in one person’s inbox or on one person’s computer. Templates, checklists, client-specific reference documents, key contacts, recurring schedules.
This category is the most obvious and the most neglected. The shared reference material is the documentation no one has time to create until the moment when not having it costs real time.
Category 4 is open questions and working assumptions
Every team is currently operating on a set of assumptions that have never been stated explicitly. What “good enough” means on a given type of work. How long a typical project takes. What the team is and isn’t prepared to handle.
Naming these assumptions is the beginning of resolving them. An open question that no one has answered is better named than left invisible. A working assumption that everyone holds slightly differently is better stated than left to produce friction.
How the Living Library Builds Your Team Knowledge Base
Without a knowledge base, the owner is the team’s memory. Every question about how things work or why a decision was made comes back to them.
The Living Library is the part of the Kiluma platform where the business’s accumulated operational knowledge is organized. When the team adds documents, decision records, and reference materials to the Team Knowledge Base Collection, the Library reads them and builds the knowledge base.
When a team member has a question, they check the knowledge base before asking the owner. The answer is often there. When it isn’t, the question itself becomes a new entry: here is what we didn’t have documented and needed to know.
The Conductor, Kiluma’s context-aware AI, can answer specific questions from the knowledge base. Ask it: “Based on what we know about how we handle this type of situation, what’s the right approach?” It reads the relevant entries in the Team Knowledge Base Collection and returns what the team’s documented practice says.
Add One Category This Week
Take Category 2 (the decision record) and add five decisions that shaped how the team currently works. For each one, write the decision and the reason in two sentences.
That is the knowledge base started. It does not have to be comprehensive before it is useful. Five decisions is more than zero.
The Reference Everyone Has
The Team Knowledge Base and the Behavioral Values Document let a team operate consistently without the owner being the source of every answer. The values say how to behave; the knowledge base says how things work. Together they give the team the shared picture it needs to stay aligned as it grows. Try Kiluma free for 14 days at kiluma.ai.