Knowledge management: stop depending on specific people
Every company has people who are indispensable — not because they are irreplaceable as individuals, but because critical knowledge lives only in their heads. When that person goes on vacation, gets sick, or leaves the company, the knowledge goes with them.
This is not a people problem. It is a knowledge management problem. And it is solvable.
What is knowledge management
Knowledge management (KM) is the practice of capturing, organizing, sharing, and maintaining the knowledge that a company needs to operate. It turns individual expertise into organizational capability.
There are two types of knowledge in any organization:
Explicit knowledge
Information that is already written down: process documents, SOPs, manuals, policies, databases. This is the easy part — it exists, it just needs to be organized and kept current.
For guidance on creating this type of documentation, see how to document processes and SOP examples.
Tacit knowledge
Information that lives in people's heads: the workarounds they use, the judgment calls they make, the context they carry from years of experience. "I know to check with finance before processing refunds over $500 because there was an issue in 2022" — this is tacit knowledge.
Tacit knowledge is where the real risk lies. It is harder to capture, but it is also where the most value is lost when someone leaves.
The cost of key-person dependency
Key-person dependency is not theoretical. Here is what it looks like in practice:
| Scenario | Impact |
|---|---|
| The only person who knows the billing process goes on leave | Invoices are delayed, cash flow is affected |
| The senior engineer who set up the infrastructure quits | The team cannot debug production issues confidently |
| The office manager who handles vendor contracts retires | Contract renewals are missed, terms are renegotiated from scratch |
| The customer success lead who knows every client's history transfers departments | Client relationships lose continuity, churn risk increases |
The pattern is always the same: a single point of failure disguised as a trusted employee.
How to spot key-person dependency
Ask these questions about your team:
- If [person] were unavailable for two weeks starting tomorrow, which processes would break?
- Which processes can only be executed by one person?
- Which questions does the team route to the same person every time?
- Which processes have no written documentation?
If the answer to any of these identifies a specific person, you have a dependency that needs to be addressed.
How to capture tacit knowledge
Capturing tacit knowledge is the hardest part of knowledge management. You cannot simply ask someone to "write down everything you know." Here are methods that work:
1. Process recording
Have the expert perform the process while a tool records their actions. This captures not just the steps, but the specific clicks, the fields they check, and the order they follow. Tools like Instruo automate this — the expert just does their job, and the documentation generates itself.
2. Structured interviews
Sit with the expert and walk through the process together. Ask specific questions:
- "What do you check first?"
- "What could go wrong at this step?"
- "Is there anything that is not obvious that a new person would miss?"
- "What did you learn the hard way?"
Record the conversation and convert it into documentation.
3. Shadowing and observation
Watch the expert perform the process. Take notes on what they do that is not in any existing documentation. Often, the most valuable knowledge is in the small decisions and checks that the expert performs automatically.
4. Post-incident documentation
Every time a problem is solved by someone's specific knowledge, document the solution immediately. "Maria knew that the system requires a cache clear after updating pricing" becomes a documented step rather than tribal knowledge.
5. Teach-back method
Ask the expert to train someone else on the process. Observe the training. The questions the learner asks reveal the gaps in existing documentation. Update the docs based on what was explained verbally.
Building a knowledge management system
A knowledge management system does not need to be complex. It needs to be consistent and accessible.
Step 1 — Audit your knowledge landscape
List every critical process in your organization. For each one, answer:
- Is it documented? (Yes / Partially / No)
- Is the documentation current? (Yes / Outdated / Unknown)
- How many people can execute it? (1 / 2-3 / Many)
Processes that are undocumented and known by one person are your highest priority.
Step 2 — Define your documentation standard
Choose a consistent format for all process documentation. Whether you use SOPs, work instructions, or training manuals, the format should be the same across the organization.
A consistent standard makes documentation easier to create, easier to find, and easier to maintain. See our SOP template guide for a ready-to-use starting point.
Step 3 — Create a central repository
All documentation needs to live in one place — searchable, organized by team or function, and accessible to everyone who needs it. This is your knowledge base.
Avoid the trap of scattering documentation across Google Docs, Notion, Confluence, shared drives, and Slack pins. Fragmented documentation is almost as bad as no documentation.
Step 4 — Assign ownership
Every documented process needs an owner — a person responsible for keeping it accurate. This is not the same as the person who wrote it. The owner reviews the documentation on a set cadence (quarterly is practical for most processes) and updates it when the process changes.
Step 5 — Embed documentation in workflows
Documentation that requires people to leave their workflow to consult it gets ignored. Link guides directly from the tools where the process is executed. If the process happens in a CRM, link the guide from the CRM. If it happens in a spreadsheet, link it from the spreadsheet.
Step 6 — Measure and iterate
Track these metrics monthly:
| Metric | Target direction |
|---|---|
| Documentation coverage (% of critical processes documented) | Up |
| Key-person dependencies (processes known by only 1 person) | Down |
| Documentation freshness (% of docs reviewed in last 90 days) | Up |
| New hire time-to-productivity | Down |
| Repeat questions in Slack/Teams about "how to do X" | Down |
Common mistakes in knowledge management
Treating it as a one-time project. Knowledge management is a practice, not a project. Companies that do a "documentation sprint" and then stop find themselves back at square one within six months.
Focusing on volume over quality. A knowledge base with 500 outdated articles is worse than one with 50 accurate guides. Prioritize the processes that matter most and keep them current.
Not involving the people who do the work. Documentation written by managers who do not execute the process is often inaccurate. The people who do the work must be involved in creating and reviewing the documentation.
Making documentation creation too painful. If documenting a process takes four hours, people will avoid it. Tools that reduce creation time — like screen-capture documentation tools — remove the friction that kills knowledge management programs.
Start today, not next quarter
Knowledge management does not require a company-wide initiative to begin. Start with one team, one set of critical processes, and one consistent format. The goal is not perfection — it is reducing the risk that walks out the door every time someone leaves for the day.
Pick the three processes that would cause the most disruption if the person who knows them were unavailable. Document those first. Build from there.
Ready to capture your team's knowledge before it walks out the door? Start with Instruo for free and document your first critical process in minutes.