Expertise in one field does not automatically transfer to another. Domain dependence is the tendency to apply reasoning, heuristics, and judgment effectively within a familiar domain while failing to use the same quality of thinking elsewhere. A brilliant physicist may make elementary errors in investing. A world-class surgeon may fall for obvious consumer scams. The knowledge is domain-specific; the mind does not automatically generalise it. Charlie Munger popularised the term to describe why smart people make stupid decisions outside their circle of competence. The mechanism is not lack of intelligence but the way expertise is stored and retrieved — context-bound, not abstract.
The implication is structural. Skills and mental models attach to situations. Change the situation (domain, framing, or context) and the same person can behave like an expert or a novice. This explains why hiring "smart people" without domain fit often fails: raw cognitive ability does not guarantee transfer. It also explains why cross-domain thinkers — those who deliberately export models from one field to another — are rare and valuable. They do explicitly what most brains do not do by default.
Practical consequences: decisions made outside your domain should be treated with more humility and more structure. Checklists, outside views, and explicit reasoning help compensate. Bringing in people who think from different domains reduces the risk that the whole room is domain-dependent in the same direction. The goal is not to become an expert everywhere but to know where you are not one and to act accordingly.
Section 2
How to See It
Domain dependence shows up when the same person performs very differently across contexts, or when a team applies a successful playbook in a new arena and fails. Look for sharp discontinuities in judgment quality when the subject matter or framing shifts, and for overconfidence in unfamiliar domains.
Business
You're seeing Domain Dependence when a founder who scaled a B2B SaaS company applies the same go-to-market playbook to a consumer app and is surprised when viral loops and brand matter more than sales outreach. The playbook was right for the first domain; the second domain has different rules. Success in one does not transfer without explicit translation.
Technology
You're seeing Domain Dependence when an engineer who designs fault-tolerant systems treats personal productivity the same way — over-optimising routines and tooling while underweighting psychology, energy, and relationships. The mental model (reliability, redundancy) fits infrastructure; it misapplies to human performance.
Investing
You're seeing Domain Dependence when a successful equity investor applies leverage and concentration to real estate or crypto and blows up. The same risk tolerance and position sizing that worked in public equities assume different liquidity, information, and regulatory reality. The domain changed; the approach did not.
Markets
You're seeing Domain Dependence when a policymaker with a macro background designs a product-regulation framework and ignores user behaviour, distribution, and adoption. The models that explain aggregate outcomes do not automatically specify how individuals choose or how products spread.
Section 3
How to Use It
Decision filter
"Before applying a strategy, playbook, or mental model from one area to another, ask: is this domain similar enough that the same rules hold? If you are operating outside your domain, add structure — checklists, outside views, or domain experts — instead of relying on intuition."
As a founder
Know where your experience applies and where it does not. A technical founder may be domain-dependent in product and engineering but weak in distribution or pricing. The fix is not to fake expertise but to get it: hire, partner, or learn with explicit transfer in mind. When you enter a new market or channel, assume your old playbook is wrong until you have evidence it fits. Run small tests. The mistake is assuming that "smart" or "successful here" means "will figure it out there."
As an investor
Back teams that either have domain fit or have deliberately built a cross-domain lens. A founder who has only ever worked in one industry may be domain-dependent when scaling or pivoting. The best investors often have a latticework of models from many domains and apply them consciously. When evaluating a new sector, flag which of your mental models actually transfer and which are domain-specific to your prior experience.
As a decision-maker
Institutionalise checks for domain dependence. When a team proposes extending a winning strategy to a new region, product, or customer segment, require an explicit "domain fit" analysis: what is the same, what is different, and what would have to be true for the old playbook to work? Default to scepticism when the same people who succeeded in domain A are confident in domain B without new evidence.
Common misapplication: Assuming that domain dependence means "stay in your lane" only. The point is to know when you are in a new lane and to adjust — by learning, by delegating, or by using more rigorous process. Avoiding new domains entirely is a different error: missed opportunity.
Second misapplication: Confusing domain expertise with general intelligence. High IQ does not cure domain dependence. Smart people are often more overconfident when they leave their domain because they are used to being right. The correction is process and humility, not more raw brainpower.
Munger treats domain dependence as a core reason smart people fail. He argues for a "latticework of mental models" from many disciplines — physics, biology, psychology, economics — so that the same mind can recognise which model applies in which domain. His practice: borrow models explicitly from one field and apply them in another, rather than assuming intuition will transfer. The discipline is naming the domain and choosing the model instead of defaulting to the one that feels familiar.
Buffett stays within his circle of competence and defines it narrowly — "what we don't understand we don't do." That is domain dependence as strategy: rather than pretending competence transfers, he restricts the set of decisions to domains where his models and experience apply. When he ventures outside (e.g. certain tech), he either learns deeply first or delegates. The lesson is that avoiding domain-dependent errors can mean deliberately not playing in domains where you are dependent.
Section 6
Visual Explanation
Domain dependence can be pictured as a grid: rows are people (or teams), columns are domains. Each cell is performance — strong in some cells, weak in others. The same row can have high and low cells; the variation is across columns (domains), not just across rows (intelligence). Transfer is the exception: most cells stay independent unless someone deliberately builds bridges between domains (principles, checklists, or cross-domain experts).
Section 7
Connected Models
Domain dependence sits between competence, transfer of learning, and specialisation. These models either reinforce why boundaries matter, create tension with generalisation, or extend into how to think across domains.
Reinforces
Circle of Competence
Knowing your circle of competence is the operational response to domain dependence. You map where your judgment is reliable and where it is not. Domain dependence explains why the circle is often smaller than you think and why it does not expand automatically with intelligence.
Reinforces
Curse of Knowledge
Experts struggle to see problems as beginners do. Curse of knowledge is domain-bound: once you know the domain, you cannot unsee it. That makes expertise powerful inside the domain and a blind spot when you assume others (or you in another context) share the same frame.
Tension
Generalist vs Specialist
Specialisation deepens domain-specific skill and can increase domain dependence. Generalists spread across domains but may never reach the depth that creates true expertise. The tension: staying in one domain avoids transfer errors but may miss cross-domain insight; spanning domains requires explicit transfer work.
Tension
Pattern Matching
Pattern matching is how experts act fast in their domain. The same habit can misfire elsewhere when the pattern looks similar but the domain is different. So pattern matching reinforces domain dependence when the matcher does not check whether the domain has changed.
Section 8
One Key Quote
"You've got to have models in your head. And you've got to array your experience — both vicarious and direct — on this latticework of models. You may have noticed students who just try to remember and pound back what is remembered. Well, they fail in school and in life. You've got to hang experience on a latticework of models in your head."
— Charlie Munger
The latticework is the antidote to raw domain dependence: models from many domains, explicitly named and deliberately applied. Experience alone is not enough if it is not organised so that the right model is retrieved in the right context. The discipline is building the lattice and then using it across domains instead of defaulting to the one you know best.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Domain dependence is one of the highest-leverage ideas for decision quality. Most failures in strategy and investing come from applying the right logic in the wrong domain. The fix is not more data or more intelligence; it is mapping domains and matching models. Before you extend a playbook, ask: what is different here? If the answer is "nothing," you are probably wrong.
Founders should audit where they are domain-dependent. Technical founders often underestimate distribution and sales. Sales-led founders underestimate product and retention. The audit is simple: list the key decisions in the next 12 months and tag each with "we have real domain experience here" or "we are extrapolating." The second category needs process or hiring.
Investors often have sector-specific domain dependence. A VC who made money in consumer may apply consumer logic to enterprise and miss the longer cycles, different buyers, and different expansion mechanics. The best investors either restrict to domains they know or build a deliberate transfer practice — e.g. writing down which models apply in a new sector before committing.
Cross-domain thinking is a skill, not a trait. It can be improved by learning models from multiple disciplines and by doing "transfer drills": take a model from physics or biology and apply it to a business problem. The goal is not to become a polymath but to have a small set of models that you can deploy outside their home domain when the structure fits.
Process compensates when domain fit is weak. When you are in a new domain, use more structure: checklists, outside views, premortems, and explicit assumptions. Domain dependence is a failure of intuition in context; structure reduces the load on intuition.
Build transfer into the culture. When hiring or promoting, ask how the person has applied learning from one domain to another. When starting in a new domain, require an explicit "what is the same, what is different?" document. The goal is to make cross-domain transfer a habit rather than an accident.
Section 10
Test Yourself
Is this mental model at work here?
Scenario 1
A hedge fund manager who consistently beats the market in equities starts a venture fund and makes large, conviction-heavy bets in early-stage startups using the same sizing and research approach.
Scenario 2
A design lead who built a beloved consumer app is hired to run product for an enterprise platform. She focuses on polish, onboarding flow, and delight, and is surprised when deals stall in procurement and multi-stakeholder sign-off.
Scenario 3
A CFO with deep experience in manufacturing joins a high-growth SaaS company. She applies strict working-capital and inventory metrics; the board is confused because the business has no inventory and runs on subscription revenue.
Section 11
Summary & Further Reading
Domain dependence is the failure of expertise to transfer across contexts. Smart people make bad decisions outside their domain because knowledge is often context-bound. The response is to know your circle of competence, add structure when you are in a new domain, and build a latticework of models from multiple disciplines so you can choose the right one instead of defaulting to the familiar. Process and humility beat raw intelligence when the domain has changed.
Munger's speeches and essays repeatedly address domain dependence, the latticework of models, and why smart people fail outside their domain. The book is the primary source for his formulation.
Kahneman's treatment of context-dependent judgment, expertise, and when intuition fails supports the idea that performance is domain-specific and that structure helps when intuition is unreliable.
Epstein argues that generalists who transfer knowledge across domains often outperform narrow specialists in complex, changing environments. Complements domain-dependence by showing when and how transfer can be built deliberately.
Leaders who apply this model
Playbooks and public thinking from people closely associated with this idea.
First principles thinking is one way to reduce domain dependence: strip the problem to fundamentals that may hold across domains instead of relying on domain-specific patterns. Rebuilding from first principles in a new domain forces explicit transfer.
Leads-to
[Abstraction](/mental-models/abstraction)
Abstraction is the act of lifting a concept out of one domain so it can apply in another. Good abstractions reduce domain dependence by making the underlying structure visible. The risk is false abstraction — a model that seems universal but is still domain-bound.
