Frequently asked questions about thinking, epistemology, and cognitive tools. 9,738 answers
Create a knowledge map for your team. List the five to ten most critical knowledge domains for your team's work. For each domain, list every team member and rate their knowledge level: 'can teach' (4), 'independent' (3), 'with documentation' (2), 'no knowledge' (1). Sum each domain's scores and divide by the number of team members to get an average knowledge density.
Confusing documented knowledge with operational knowledge. An organization can have extensive documentation — wikis, runbooks, architecture diagrams — and still have a fragile knowledge graph if no one has internalized the documented knowledge well enough to act on it under pressure. Documentation is a node in the knowledge graph, not a substitute for the graph itself.
Every organization has a knowledge graph — a network of expertise, institutional memory, relationships, and documented information that its schemas operate on. Mapping this graph reveals where knowledge is concentrated, where it is fragile (held by a single person), where it is redundant, and where critical gaps exist.
Identify the three people on your team or in your organization whose departure would cause the most knowledge disruption. For each person, list their unique knowledge — the things they know that no one else knows. Then assess: How much of that knowledge is documented? How much is externalized in any form (code comments, architecture decision records, tribal knowledge sessions)?
Treating knowledge transfer as a departure event rather than an ongoing practice. When an employee gives notice, organizations often schedule a two-week knowledge transfer period. But two weeks is not enough to transfer years of accumulated knowledge — especially the tacit knowledge that cannot be captured in documents or handoff sessions.
When people leave organizations, their schemas often leave with them — the tacit knowledge of why systems were designed a certain way, how processes actually work (versus how they are documented), and who to call when things break. This knowledge loss is invisible until the moment the knowledge is needed and no one has it.
Choose one important system, process, or decision that your team is responsible for. Check the existing documentation. Does it capture only what (current state, procedures, configurations) or does it also capture why (design rationale, alternatives considered, tradeoffs accepted)? If the documentation is facts-only, write a one-page schema supplement: 'This system was designed to solve [problem].
Two opposing failures. The first is documentation as archaeology — creating documentation that is so detailed and comprehensive that it becomes impenetrable. A fifty-page document that captures every nuance of a system's history but cannot be navigated or searched effectively preserves knowledge in theory but not in practice.
Documentation is not just a record of what exists. It is a preservation mechanism for organizational schemas — the shared mental models that explain why things are the way they are, not just what they are. Documentation that captures schemas (the reasoning, the context, the tradeoffs) preserves the organization's cognitive capacity.
Identify one persistent problem in your team or organization — an issue that has been addressed multiple times without lasting resolution. For this problem, distinguish between single-loop and double-loop responses. Single-loop: What actions has the organization taken to address the problem within its existing understanding?
Confusing learning by individuals with organizational learning. When a team member learns a better approach through personal experience, the organization has not learned — a person has learned. Organizational learning occurs only when the new knowledge is embedded in the organization's schemas, processes, or documented practices in a way that persists beyond the individual.
An organization that cannot update its schemas in response to feedback is dying — it is operating from an increasingly inaccurate model of reality. Organizational learning is the process through which the organization revises its shared mental models based on experience. Single-loop learning adjusts actions within existing schemas.
Conduct a schema debt audit for your team or organization. List five to seven core assumptions the organization operates from (use the schema surfacing methods from L-1623 if needed). For each assumption, answer: (1) When was this assumption formed? (2) What were the conditions when it formed? (3) Have those conditions changed?
Attempting to pay down all schema debt at once. Organizations that discover their accumulated schema debt often try to update everything simultaneously — new strategy, new processes, new values, new culture. This produces change fatigue, resistance, and the failure of all changes rather than the success of any.
Outdated schemas that no one updates create a growing liability — organizational schema debt. Like technical debt, schema debt accumulates silently: each outdated assumption imposes a small cost on every decision it influences, and the costs compound as the gap between the organization's mental models and reality widens.
Choose one strategic concept that your organization's leadership discusses regularly (a strategic priority, a cultural value, or a competitive positioning). Ask people at three different levels — executive, middle management, and individual contributor — to explain this concept in their own words and describe how it affects their daily work.
Assuming that vertical schema misalignment is a communication problem that can be solved by more or better communication. When the CEO's strategy schema has not reached the front line, the typical response is more all-hands meetings, more strategy documents, more town halls. But communication transmits words, not schemas.
Leaders and front-line workers often hold different schemas about the same reality — different mental models of what the organization does, why it does it, and what matters most. This vertical misalignment is not a communication failure. It is a structural consequence of the different information environments that each level inhabits.
Choose a request or proposal you need to make to a different function. Before presenting it, identify the receiving function's schema: What do they optimize for? What do they measure? What do they consider high-quality work? Then translate your request into their schema. If you are asking engineering for a feature, express the request in terms of technical quality, system health, and engineering challenges — not just business impact.
Expecting one function to adopt another function's schema rather than translating between them. When engineering and marketing disagree, the typical response is to escalate to a leader who picks one side. This forces one function to adopt a schema that does not fit its context. The result is compliance without understanding: the function follows the directive but does not internalize the reasoning, which means the same conflict will recur in every future interaction.
Different functions speak different cognitive languages — not just different jargon, but different schemas for what matters, what quality means, and how success is measured. Cross-functional collaboration requires translation between these schemas: the ability to understand another function's mental model well enough to express your concerns in their terms and to interpret their concerns in yours.
Conduct a schema audit using this eight-dimension framework. Rate each 1-5 (1 = severely outdated or broken, 3 = functional but inconsistent, 5 = current and well-maintained). (1) Identity schema — Does the organization's self-concept match its current reality? (2) Strategy schema — Is the strategy understood and actionable at all levels?
Conducting the audit without the authority or commitment to act on the results. A schema audit that produces scores but no interventions is worse than no audit: it creates awareness of problems without addressing them, which produces cynicism. Every schema audit should conclude with a prioritized action plan: which schemas will be updated, who is responsible, what is the timeline, and how will improvement be measured.
Regularly assess whether organizational schemas match current reality — across all dimensions: currency, alignment, propagation, documentation, and debt. The schema audit is the organizational equivalent of the team cognitive audit from L-1619, scaled to examine the shared mental models that shape the entire organization's behavior.