Building a Model Toolkit
You do not need 100 mental models. You need 5 to 10 that you actually use. The difference between someone who has read about mental models and someone who uses them is the difference between owning a gym membership and being fit. The work is in the daily application, not the initial acquisition.
Start Small
The most common mistake is trying to learn too many models at once. You read a book that lists 50 models, feel inspired for a week, and then forget all of them. This happens because learning a model is not a single event — it is a process that requires repeated application before the model becomes automatic.
Start with 5 models. Use them for a month. Add more only when the first batch is second nature.
A reasonable starter kit:
1. First principles thinking — break problems to fundamentals
2. Second-order effects — ask "and then what?"
3. Inversion — ask "what would guarantee failure?"
4. Opportunity cost — ask "what am I giving up?"
5. Feedback loops — ask "what reinforces or balances this?"
These five cover a surprising range of engineering decisions. First principles helps you question assumptions. Second-order effects helps you anticipate consequences. Inversion helps you avoid catastrophic mistakes. Opportunity cost helps you prioritize. Feedback loops help you understand systems.
The Compounding Effect
Each new model you learn becomes more valuable because it connects to models you already know. This is the latticework that Munger describes — models do not exist in isolation. They reinforce each other.
Situation: Your team wants to rewrite the monolith in microservices.
First principles: Why? What fundamental problem are we solving?
Second-order effects: If we split into 12 services, what happens to
deployment complexity? On-call burden? Debugging?
Inversion: What would make this rewrite fail? Loss of team
knowledge? No clear service boundaries? Doing it
while also shipping features?
Opportunity cost: If we spend 6 months rewriting, what features do
we not build? What customers do we not serve?
Feedback loops: Will splitting the monolith create a reinforcing
loop (faster deploys → more deploys → faster
iteration)? Or a balancing loop (more services →
more coordination → slower iteration)?
No single model gives you the full picture. But five models together give you a thorough analysis in twenty minutes that would otherwise take a week of debate. And the more models you have, the richer the connections become.
How to Learn a Model
There is a four-step process that works reliably for internalizing mental models.
Step 1: Understand It
Read about the model from its original source when possible. Understand not just what it says but why it works. What assumptions does it make? What domain did it come from? What are its boundaries?
Bad understanding: "Opportunity cost means there are tradeoffs."
Good understanding: "Opportunity cost is the value of the next-best
alternative you forgo when making a choice. It
comes from economics. It assumes resources are
finite and choices are mutually exclusive."
Step 2: Find Engineering Examples
Translate the model into your domain. The model is abstract. Your work is concrete. Bridge the gap by finding three to five examples from your engineering experience where the model would have applied.
Opportunity cost in engineering:
- Choosing to refactor now means not shipping the feature this sprint.
- Attending that meeting means not writing the design doc.
- Learning Rust means not deepening your Go expertise.
- Hiring a specialist means not hiring a generalist.
- Building custom tooling means not using an off-the-shelf solution.
If you cannot find examples, either you do not understand the model well enough or it does not apply to your work. Both are useful signals.
Step 3: Apply It
Use the model actively in your next engineering decision. When you are in a design review, ask yourself: "What would first principles say about this?" When you are prioritizing the backlog, ask: "What is the opportunity cost of each choice?"
Write down the model you applied and what it told you. This is not journaling for fun — it is deliberate practice.
Decision journal entry:
Date: 2026-03-15
Decision: Whether to adopt a new ORM vs raw SQL
Model applied: Satisficing
Analysis: All three ORM options are good enough. The performance
difference between them is smaller than the cost of
evaluating them further. Picked the one our team already
knows.
Outcome: Saved 2 weeks of evaluation. Shipped on time. No regrets.
Step 4: Teach It
Explaining a model to someone else is the strongest test of whether you understand it. If you can explain inversion to a colleague and give them a concrete engineering example they relate to, you own the model.
Teaching does not require a formal setting. Drop the model name in a design review: "Let's invert this — what would guarantee this migration fails?" Mention it in a pull request comment: "This feels like a case where second-order effects matter — if we add this cache, what happens when the cache goes stale?" Use it in a 1:1 with your manager: "I'm thinking about opportunity cost here — spending two sprints on this means we skip the API redesign."
Making Models Automatic
A model you have to consciously remember to use is only half-learned. The goal is to make models automatic — the way you automatically think in Big O when someone proposes a nested loop over a large dataset.
The path from conscious to automatic follows a predictable curve:
Stage 1: Conscious incompetence
You know the model exists but forget to use it.
Stage 2: Conscious competence
You remember to apply it but it takes effort.
Stage 3: Unconscious competence
You apply it without thinking. It shapes your
questions and instincts automatically.
Most people stall at Stage 1. They read about models, nod along, and never apply them. The transition from Stage 1 to Stage 2 requires deliberate effort: put the model names on a sticky note on your monitor. Review your list before design reviews. Explicitly name the model when you use it in conversation.
The transition from Stage 2 to Stage 3 requires volume. You need to apply the model dozens of times before it becomes instinct. This is why starting with 5 models instead of 50 matters — you need enough repetition with each one.
The Models in This Subject
The models covered in this subject are a deliberately chosen starter kit. They were selected because they are broadly applicable to engineering work, they come from multiple disciplines, and they complement each other well.
Topic Primary discipline Engineering use
--- --- ---
First principles thinking Philosophy Questioning assumptions
Systems & feedback loops Systems dynamics Understanding complex behavior
Trade-offs & decision-making Economics/Psychology Making better choices
Second-order effects Systems thinking Anticipating consequences
Inversion Mathematics Avoiding failure
Map vs territory Epistemology Knowing model limits
Leverage & bottlenecks Systems/Operations Focusing effort
Probabilistic thinking Statistics Reasoning under uncertainty
Cognitive biases Psychology Compensating for bad instincts
You do not need to master all of them at once. Pick the three that resonate most with your current work. Use them for a month. Then add more.
Building the Habit
The hardest part is not learning models. It is remembering to use them. Here are concrete tactics that work:
Tactic When to use it
--- ---
Pre-meeting review Before a design review, pick 2 models
to apply deliberately.
Post-decision audit After a major decision, ask: which
models did I use? Which should I have?
Weekly reflection Spend 10 minutes reviewing the week's
decisions through a model lens.
Pair with a colleague Find someone else learning models.
Hold each other accountable.
Label out loud In meetings, name the model: "I think
this is a reversible decision, so let's
move fast."
The labeling tactic is especially powerful. When you say "this is a two-way door" in a meeting, you give the entire room a shared model. Now everyone can reason about the decision using the same framework. This is how models spread through teams.
When to Add New Models
Add a new model when you encounter a problem that your existing models do not handle well. This is the natural signal. If you keep running into situations where you feel lost, that is a gap in your toolkit.
Signal Model to add
--- ---
"I keep underestimating projects" Planning fallacy, reference class forecasting
"Our system has weird emergent Stocks, flows, and delays
behavior I can't predict"
"I struggle to convince leadership" Audience/intent models, Cialdini's influence
"I optimize the wrong things" Goodhart's Law, local vs global optima
"I keep repeating mistakes" Decision journals, pre-mortems
Do not add models proactively "just in case." Add them when you feel the pain of not having them. Pain is the best teacher.
Common Pitfalls
- Collector's fallacy — reading about 50 models and internalizing zero. Breadth without depth is useless. Five models you can apply under pressure are worth more than 50 you can name.
- Tool fixation — using a model when it does not apply because it is the one you know best. If you just learned inversion, not every problem needs inverting.
- Skipping the application step — understanding a model intellectually and assuming that means you can use it. You cannot. Application under real conditions is a different skill.
- Teaching before learning — explaining models to others before you have applied them yourself. You will give bad examples and create confusion.
- Expecting instant results — models compound over time. You will not see dramatic improvement in week one. You will see it in month six.
Key Takeaways
- Start with 5 to 10 models, not 100. Depth beats breadth.
- The four-step learning process: understand, find examples, apply, teach.
- Models compound — each new model connects to existing ones, making all of them more powerful.
- The goal is unconscious competence: automatic application without deliberate effort. This requires volume.
- Add new models when you feel the pain of not having them, not proactively.
- The models in this subject are a starter kit. Your toolkit will grow over your entire career.
- Label models out loud in meetings. This spreads them through your team and reinforces your own understanding.