Knowledge Writing Explained: Capturing Expertise That Outlasts the Expert
When Ray Dalio, founder of Bridgewater Associates, began writing down the principles that guided his decision-making, he did not intend to create a book. He started with short memos to his team explaining why he made specific investment decisions, what factors he weighed, and what patterns he had observed across decades of managing the world's largest hedge fund. Over years, these memos accumulated into a comprehensive framework for decision-making that could be studied, debated, and applied by anyone at the firm -- not just Dalio himself. When he eventually published Principles in 2017, it became a bestseller not because of elegant prose but because it represented something rare: tacit expertise made explicit and transferable.
Most organizational knowledge never makes this journey. A 2018 study by Panopto estimated that U.S. businesses lose $47 billion annually in productivity due to inefficient knowledge sharing. When experts leave organizations, their accumulated wisdom -- the judgment calls, pattern recognition, and contextual understanding built over years -- typically walks out the door with them. Knowledge writing is the practice of capturing this expertise in written form that allows others to learn from, apply, and build upon it. Unlike regular documentation that records facts and procedures, knowledge writing captures the reasoning, context, and judgment that transform information into understanding.
This article explores how knowledge writing differs from other forms of professional writing, techniques for extracting tacit knowledge from experts, effective structures for different knowledge types, personal knowledge management systems, and common mistakes that prevent knowledge from successfully transferring through writing. Understanding knowledge writing is essential for anyone who wants to preserve institutional knowledge, build on others' expertise, or develop their own thinking through the act of writing.
What Makes Knowledge Writing Different
Beyond Information Transfer
1. Regular writing communicates information the writer already knows how to articulate. Knowledge writing involves extracting and structuring expertise that may be tacit, implicit, or difficult to articulate. The writer often does not fully understand what they know until they try to write it down. The act of writing becomes an act of discovery.
2. Knowledge writing serves as external memory and learning tool, not just communication. It must be structured for retrieval and building understanding over time. This means including context (when this applies), limitations (when this does not work), and reasoning (why this matters) alongside the knowledge itself.
Example: When Amazon engineers write design documents for new systems, they are required to include not just what they propose to build but why they chose this approach over alternatives, what tradeoffs they are making, and what assumptions might prove wrong. These documents capture decision-making knowledge that remains valuable long after the system is built.
3. Knowledge writing is iterative. You often cannot write it completely in one session because articulating tacit knowledge requires reflection, revision, and testing whether your articulation actually captures the insight. The test of good knowledge writing is not whether it sounds good but whether someone can read it and actually use the knowledge -- whether it transfers expertise, not just information.
Explicit Knowledge Versus Tacit Knowledge
1. Explicit knowledge can be codified and communicated in formal language: procedures, formulas, specifications, facts. Writing explicit knowledge is relatively straightforward because it involves recording what can be stated clearly. Step-by-step instructions, reference guides, and policy documents capture explicit knowledge.
2. Tacit knowledge is the expertise that people demonstrate but struggle to explain: the experienced doctor's intuition about a diagnosis, the veteran engineer's sense that a system design will not scale, the skilled negotiator's ability to read a room. Tacit knowledge involves pattern recognition, judgment, and contextual reasoning that experts apply unconsciously.
3. Most organizational value lies in tacit knowledge, but most documentation captures only explicit knowledge. The gap between what organizations document and what organizations know is where knowledge writing makes its greatest contribution.
Example: Toyota's production system documentation captures not just the procedures (explicit knowledge) but the reasoning behind them (tacit knowledge). When documenting why a particular quality check happens at a specific point in the production line, Toyota engineers explain the types of defects it catches, why those defects are more likely at that stage, and what would happen if the check were moved or eliminated. This reasoning is more valuable than the procedure itself because it enables intelligent adaptation.
The Knowledge Spectrum
| Knowledge Type | Characteristics | Writing Challenge | Best Format |
|---|---|---|---|
| Procedural | How to do something step by step | Capturing all steps, including "obvious" ones | Numbered instructions with prerequisites |
| Conceptual | How something works or why it matters | Making abstract ideas concrete | Explanations with analogies and examples |
| Decision-making | How experts choose between options | Extracting unconscious criteria | Decision trees, criteria matrices |
| Troubleshooting | How to diagnose and fix problems | Capturing pattern recognition | Symptom-diagnosis-solution format |
| Strategic | When to apply different approaches | Encoding context-dependent judgment | Case-based scenarios |
Capturing Tacit Knowledge
Techniques for Knowledge Extraction
1. The most effective technique for extracting tacit knowledge is think-aloud protocol: having experts narrate their thought process while solving a real problem or reviewing actual work. "I'm checking the error logs first because this type of failure usually indicates a database connection issue, but if the logs look clean, I'll check the load balancer configuration because we've seen similar symptoms when traffic patterns change." Recording and transcribing these sessions reveals decision-making patterns that experts cannot articulate when asked abstractly.
2. The contrast cases method involves showing experts pairs of examples -- one good, one problematic -- and asking what differences they notice. Experts can often articulate criteria through comparison even when they cannot define standards abstractly. "This code review is good because it addresses the edge case where the input is null, while this one ignores it" reveals quality criteria the expert applies automatically.
Example: When Google wanted to capture senior engineers' code review expertise, they studied thousands of code reviews and interviewed reviewers about what they looked for. The result was a set of documented review criteria that junior engineers could apply, significantly improving review quality across the organization.
3. The novice questions technique involves having someone unfamiliar with the domain ask basic questions that force experts to unpack assumptions. "Why do you always check that first?" "How do you know when to escalate?" "What would a junior person miss here?" These questions target exactly the tacit knowledge that experts have internalized and no longer consciously access.
4. Interview about specific incidents: "Tell me about a time when you had to make a difficult technical decision" yields concrete stories that reveal decision-making principles. Abstract questions like "How do you make technical decisions?" produce vague generalities. Specific incidents produce specific knowledge.
Building Knowledge Progressively
1. Knowledge writing is best built through iteration: write an initial draft based on interviews or observation, have the expert review and refine, then test it with a novice to see what is missing. The novice test is critical because experts reviewing their own knowledge documentation will always fill gaps mentally without noticing them.
2. Look for phrases in expert conversations that signal tacit knowledge needing unpacking: "you just know," "it's intuition," "it depends," "you get a feel for it." These phrases mark exactly the points where conscious reasoning has been compressed into unconscious competence and needs to be expanded.
3. Ask experts "what mistakes do newcomers make?" or "what would a junior person miss?" Experts can often articulate what not to do even when they struggle to explain what to do. Mistakes and anti-patterns are a productive entry point for knowledge extraction because they connect to memorable experiences.
"We can know more than we can tell." -- Michael Polanyi
Structures for Different Knowledge Types
Procedural Knowledge: Step-by-Step with Context
1. Procedural knowledge is the most commonly documented type but often poorly done. Effective procedural writing includes not just the steps but prerequisites (what must be true before starting), expected outcomes at each step (how to verify progress), and common errors (what goes wrong and how to recover).
2. Number steps sequentially because they must be executed in order. Include decision points where the procedure branches: "If the test passes, continue to step 5. If it fails, see Troubleshooting section." Do not assume steps are obvious -- what is obvious to the expert is often the exact point where novices get stuck.
Example: DigitalOcean's tutorials are widely praised for their procedural knowledge quality. Each tutorial includes prerequisites, numbered steps with expected output at each stage, common errors with solutions, and a verification section confirming the procedure succeeded. This completeness makes tutorials usable by genuine beginners rather than only those who already know most of the process.
3. Test procedures by having someone follow them literally. Instructions that an expert reads as "do X" may leave a novice wondering "how exactly do I do X?" Every point where the test reader hesitates or asks for clarification identifies a gap in the procedure.
Conceptual Knowledge: Layered Explanations
1. Conceptual knowledge explains how things work and why they matter. Effective conceptual writing uses progressive disclosure: start with the simplest accurate version of the concept, then add layers of nuance, exceptions, and technical detail. This gives readers a mental framework to hang additional information on.
2. Use analogies to connect unfamiliar concepts to familiar ones, but be explicit about where the analogy breaks down to avoid creating misconceptions. "A database index works like a book's index -- it helps you find specific information quickly without reading every page. Unlike a book index, a database index updates automatically but consumes storage space."
3. Include both what something is AND what it is not. Boundary definitions prevent the common failure where readers over-generalize a concept. "Agile development is a set of principles for iterative, adaptive project management. It is not an excuse to skip planning, ignore documentation, or avoid commitments."
Decision-Making Knowledge: Criteria and Context
1. Decision-making knowledge is the most valuable and hardest to capture because it involves judgment that varies with context. The best format is criteria matrices or decision trees that encode how experts choose between options based on situational factors.
2. Use "when X, do Y; when Z, do W" structures that make context-dependent advice explicit. "Use a relational database when data has clear relationships and you need ACID transactions. Use a document database when data structures vary and you prioritize read performance over write consistency."
3. Include the reasoning behind criteria, not just the criteria themselves. "We prefer relational databases for financial data because ACID transactions prevent the partial writes that could cause accounting discrepancies" transfers the principle, not just the rule.
Troubleshooting Knowledge: Symptom-First Organization
1. Troubleshooting knowledge should be organized by what the person observes first (symptoms), not by what is technically wrong (causes). Users experiencing a problem know their symptoms; they do not yet know the cause. A troubleshooting guide organized by cause forces users to diagnose before they can find help.
2. For each symptom, provide a diagnostic sequence: "If you see error X, check A first. If A looks normal, check B. If B shows Y, the cause is likely Z and the fix is..." This mirrors how experts actually troubleshoot -- through systematic elimination -- and teaches the diagnostic process alongside the solutions.
3. Include red herring warnings where appropriate: "Error message X sometimes appears when the actual problem is Y. Before investigating X, verify that Y is not the real cause by..." This captures the expert's knowledge of misleading symptoms that novices waste time chasing.
Personal Knowledge Systems
Building a Knowledge System That Grows
1. Personal knowledge systems serve two purposes: capturing information efficiently and retrieving it when needed. Many systems optimize for capture (everything gets saved) but fail at retrieval (finding specific information requires remembering where you put it).
2. Effective personal knowledge systems use both hierarchical organization (categories and folders for browsing) and non-hierarchical connections (tags, links, and search for finding). The PARA method, developed by Tiago Forte, organizes by Projects (current work), Areas (ongoing responsibilities), Resources (reference material), and Archives (completed items).
Example: Niklas Luhmann, the German sociologist, maintained a physical index card system (Zettelkasten) of over 90,000 interlinked notes that he used to write over 70 books and 400 scholarly articles. The system's power came not from storage but from cross-referencing -- each note was connected to related notes through numbered references, creating a knowledge network that generated insights through unexpected connections.
3. The key principles for personal knowledge systems are: low friction for capture (if adding information is hard, you won't do it consistently), multiple retrieval paths (search, browse, and follow links), and regular review (periodically revisiting and connecting existing notes builds understanding).
Progressive Summarization
1. Progressive summarization, developed by Tiago Forte, involves processing captured information through multiple layers: first capture the full source, then highlight key passages, then bold the most critical points, then distill a summary, then extract insights. Each layer creates a more compressed version that is faster to retrieve and review.
2. This approach acknowledges that most captured information will never be revisited. Full processing of every note is wasteful. Progressive summarization invests processing effort proportional to how often and how urgently you need the information.
3. The system works because each layer serves a different purpose: full text for deep reference, highlights for quick review, bold points for scanning, summaries for decision-making, and insights for application. Different retrieval needs access different layers.
Common Knowledge Writing Mistakes
Writing from Expert Perspective Without Scaffolding
1. The most common knowledge writing mistake is presenting information at the level the expert currently thinks about it rather than at the level a learner can absorb it. Experts organize knowledge by deep principles; learners need progressive disclosure from simple to complex.
2. Experts skip steps that seem obvious, use terminology without definition, and organize by logical structure rather than learning sequence. The fix is to have novices review knowledge documents and mark every point where they must guess, assume, or look up something the document did not provide.
3. Knowledge writing should include scaffolding: the supporting structures that help readers build understanding incrementally. Scaffolding includes definitions, examples, analogies, prerequisites, and explicit connections to prior knowledge.
Focusing on What Without Why
1. Knowledge writing that provides facts, procedures, or specifications without explaining rationale, tradeoffs, or conditions of applicability is less transferable than knowledge writing that includes the "why." "Do X" is a rule; "Do X because Y; in cases where Z, do W instead" is knowledge that can be adapted to novel situations.
2. The "why" helps readers adapt knowledge to new situations rather than just following recipes. When circumstances change, someone who understands the reasoning can adapt; someone who only knows the procedure is stuck.
Example: Stripe's documentation explains not just how to implement payment features but why certain implementation patterns exist. When documenting idempotency keys, Stripe explains the race conditions and duplicate charge problems that idempotency prevents, helping developers understand when and why to use them rather than just mechanically following instructions.
3. Include the context under which knowledge applies and the boundaries where it breaks down. "This approach works well for teams of 5-15 people working on a single product. For larger teams or multiple products, consider..." makes knowledge situationally useful rather than falsely universal.
Concise Synthesis
Knowledge writing captures expertise that would otherwise exist only in individuals' minds, making it available for others to learn from, apply, and build upon. It differs from regular documentation by targeting tacit knowledge -- the judgment, pattern recognition, and contextual reasoning that experts use unconsciously but struggle to articulate. Effective knowledge extraction uses techniques like think-aloud protocols, contrast cases, and novice questioning to surface expertise that direct questioning misses. Different knowledge types demand different structures: procedural knowledge needs step-by-step instructions with context, conceptual knowledge needs layered explanations with analogies, decision-making knowledge needs criteria matrices that encode situational judgment, and troubleshooting knowledge needs symptom-first organization. The common mistakes -- writing at expert level without scaffolding, omitting the "why" behind the "what," and treating knowledge as static rather than contextual -- are all variations of failing to bridge the gap between what the expert knows and what the reader needs to build genuine understanding.
References
- Polanyi, Michael. "The Tacit Dimension." University of Chicago Press, 1966.
- Nonaka, Ikujiro, and Hirotaka Takeuchi. "The Knowledge-Creating Company." Oxford University Press, 1995.
- Dalio, Ray. "Principles: Life and Work." Simon & Schuster, 2017.
- Forte, Tiago. "Building a Second Brain." Atria Books, 2022.
- Ahrens, Sonke. "How to Take Smart Notes: One Simple Technique to Boost Writing, Learning and Thinking." 2017.
- Panopto. "Workplace Knowledge and Productivity Report." 2018.
- Dreyfus, Hubert L., and Stuart E. Dreyfus. "Mind Over Machine: The Power of Human Intuition and Expertise in the Era of the Computer." Free Press, 1986.
- Ericsson, K. Anders, and Robert Pool. "Peak: Secrets from the New Science of Expertise." Houghton Mifflin Harcourt, 2016.
- Liker, Jeffrey K. "The Toyota Way." McGraw-Hill, 2004.
- Chi, Michelene T. H. "Two Approaches to the Study of Experts' Characteristics." Cambridge Handbook of Expertise, 2006.
- Google Engineering Practices Documentation. google.github.io/eng-practices, 2023.