A latticework of mental models
TL;DR
A mental model is a compressed, reusable idea about how some part of the world works — opportunity cost, feedback loops, natural selection, margin of safety. The latticework idea, owed to Charlie Munger, says you want a few dozen big models drawn from many disciplines, hung on a mental lattice so a new situation pings several of them at once. First-principles thinking tells you how to reason. The latticework is the material you reason with. A broad lattice is what lets you decompose a problem you've never seen, because some field you borrowed from has already met its cousin.
🎯 For the builder
Why it matters — When all you own is one field's models, every problem gets bent into that field's shape ("to the person with a hammer, everything looks like a nail"). Range of models is range of available decompositions.
What it changes in your decisions — You start recognizing that a hiring problem is partly a queueing problem, a roadmap is partly a portfolio/option problem, and a viral feature is partly an epidemiology problem. You import the field that already solved it.
Ask yourself — "Which other discipline has already faced the structure of this problem, and what did it learn?"
Risk if ignored — You reinvent, badly, models that another field perfected a century ago. You misread situations your single toolkit has no name for.
Why one discipline isn't enough
Four models from four disciplines · each catches what the others miss
Munger's move: hang the problem on many models, not one.
Feedback loops
biology · control theory
Bottlenecks
operations
Incentives
economics
Second-order
systems thinking
Rich decomposition
Each model reveals a blind spot the others miss. One model reduces to one narrative — a latticework triangulates.
Munger's framing, from his talk The Psychology of Human Misjudgment and many since:
"You've got to have models in your head, and you've got to array your experience — both vicarious and direct — onto this latticework of models. … You may have noticed students who try to remember and pound back what they're taught. Well, the first [group] fail and the second one fail. You've got to hang experience on a latticework of models in your head."
The key word is latticework, not list. Models compound when they connect. You understand compounding better once you've seen it in interest, in bacteria, in skill, and in network effects. That cross-field repetition is what makes the idea stick and generalize. A model known in only one context is half-learned.
The reason breadth beats depth here specifically is error correction. Each discipline has characteristic blind spots. Economics underweights psychology. Psychology underweights incentives. Engineering underweights human behavior. A model from one field routinely catches the mistake another field's model would have made. The lattice isn't just more tools. It's a system of mutual checks.
A starter set worth carrying
You don't need hundreds. Munger estimated 80–90 big models carry most of the freight. A high-leverage starter set, by origin discipline:
| Model | One-line idea | Borrowed from |
|---|---|---|
| Inversion | Solve the problem backward: ask how to guarantee failure, then avoid that | Mathematics (Jacobi) |
| Opportunity cost | The true cost of anything is the best thing you gave up for it | Economics |
| Second-order effects | "And then what?" — the consequences of the consequences | Systems thinking |
| Compounding | Small, repeated effects grow non-linearly over time | Math / finance |
| Feedback loops | Outputs loop back as inputs; some stabilize, some explode | Control theory / biology |
| Leverage points | A few places in a system where a small shift moves everything; most effort is spent pushing where it can't matter | Systems thinking (Meadows) |
| Emergence | Wholes have properties none of their parts have — trust, fairness, traffic jams; you can't fix them one component at a time | Systems thinking / biology |
| Margin of safety | Build in slack so you survive the case you didn't predict | Engineering |
| Incentives | "Show me the incentive and I'll show you the outcome" | Economics / psychology |
| Map ≠ territory | The model is not the reality; all models leave things out | Semantics (Korzybski) |
| Bottlenecks / theory of constraints | A system's throughput is set by its single tightest stage | Operations |
| Entropy | Order decays without energy input; things tend toward mess | Thermodynamics |
| Natural selection | Variation + selection + retention produces design without a designer | Biology |
| Probabilistic thinking | Reason in distributions and base rates, not certainties | Statistics |
Two of these deserve a closer look because they recur constantly in real decisions.
Inversion
Most problems are easier solved backward. Instead of "how do I build a great team?" ask "how would I reliably build a miserable team?" The avoid-list writes itself. Inverting turns a vague aspiration into a concrete list of failure modes to design against. It's the same move as the 5 Whys' hunt for root causes, pointed at the future instead of the past.
Second-order effects
First-order thinking stops at the immediate result. Second-order thinking asks "and then what?" You cut prices → sales rise (first order) → competitors cut deeper and the category commoditizes (second order). Almost every "obvious" decision that ages badly was a first-order decision in a second-order world. This is the conceptual cousin of the tradeoff reasoning in Module 06: every choice has consequences you have to chase past the first one.
How the lattice powers first principles
The two halves of this module fit together precisely:
- First-principles method is the operation — deconstruct, challenge, reconstruct.
- The latticework is the material the operation runs on. When you deconstruct a novel problem, the component claims you produce are only as good as the models you have to name them with. More models means finer decomposition means better reconstruction.
Here's a concrete example. Faced with "our growth stalled," a one-model thinker sees a marketing problem. A lattice thinker simultaneously checks feedback loops (did a flywheel break?), bottlenecks (is one stage capping throughput?), incentives (did we reward the wrong behavior?), and second-order effects (did last quarter's win cause this quarter's stall?). Same problem, far richer decomposition — and that's exactly what the polymath posture is built to supply.
Building your own lattice
- Learn the big idea of each major field, not the field. You don't need to be an economist. You need opportunity cost, incentives, and supply/demand — the 20% of each discipline that does 80% of the explaining.
- Learn each model to fluency, not familiarity. A model you can only recite doesn't fire when you need it. Learn it by teaching it and using it until it's automatic.
- Collect the model's failure conditions too. Every model has a domain where it breaks (map ≠ territory). A model without its limits is a trap — the warning of the next lesson.
- Look for the same model across fields. When you spot compounding in finance and bacteria and skill, you've actually learned it.
📦 Mini-case — the churn diagnosis. A subscription team spent two quarters treating rising churn as a pricing problem, their home discipline. A lattice pass reframed it in one meeting: bottleneck — churn concentrated in users who never reached the aha moment. Incentive — sales was paid on signups, not activations, so it sold to poor-fit accounts. Second-order — last year's discount campaign had pulled in exactly those accounts. Three models, three fixes, none of them a price change. One discipline saw one lever; the lattice saw the system.
Failure modes
- Man-with-a-hammer syndrome — Forcing every problem into your favorite model. Diagnostic: if you reach for the same model every time, you have one model, not a lattice.
- Model collection as trivia — Knowing the names of fifty models you never actually deploy. Fluency, not vocabulary.
- Forgetting map ≠ territory — Mistaking the model for reality and defending it past the point where it stopped fitting.
- Single-discipline lattice — Fifty models all from one field share that field's blind spots. The error-correction benefit is gone.
Practitioner checklist
- Can I name the origin discipline of my favorite models — and is it more than one?
- For the problem in front of me, did I check it against several models, not just the first that fired?
- Do I know the failure conditions of each model I'm leaning on?
- Have I tried inverting the problem and chasing at least one second-order effect?
- Have I seen this model in more than one field, or do I only half-know it?
Related lessons
- The method: deconstruct, challenge, reconstruct
- Becoming a polymath
- Traps & limits
- Strategy & tradeoffs
- How systems are built — an engineer's model of the machine, one more lattice to borrow from.
- Ontologies & data modeling — turning a fuzzy domain into crisp entities is model-building in practice.