Section 5: Leverage Points & Mental Models for Better Decisions

By Pritesh Yadav 14 min read

Most people try to fix problems by turning the most obvious knob — raising a price, hiring one more person, sending one more email. These changes rarely work because they touch the surface, not the root. This section introduces two complementary ideas: leverage points (where in a system a small push creates a big lasting shift) and mental models (thinking tools that let you see reality more clearly so you pick the right push). Together, they are the toolkit of people who consistently make better decisions than everyone else.

1. Leverage Points — Donella Meadows

In 1997, systems thinker Donella Meadows published an essay called "Leverage Points: Places to Intervene in a System." She had attended a conference on the North American Free Trade Agreement (NAFTA) and noticed that the people designing an enormous economic system were only arguing about small numbers — tariff rates, quotas — while ignoring far more powerful levers. Her essay listed twelve places you can intervene in any system, ranked from weakest to strongest.

Analogy: Think of a thermostat-controlled room. You could argue all day about whether to set 68°F or 70°F (a parameter). But if you rewire the thermostat so it reads the outdoor temperature instead of the indoor temperature, you have changed the information flow — a far more powerful lever. And if you convince everyone in the building that comfort means "fresh air, not heat," you have changed the paradigm — the most powerful lever of all.

The Three Tiers (simplified from Meadows' twelve)

Meadows organized her twelve points into a rough hierarchy. For practical use, think of three tiers:

Tier What you change Power level Example
Numbers (weakest) Constants, parameters, sizes Low — effects are usually small and reversible Raising a tax rate by 2%; cutting a budget line
Structure (medium) Information flows, feedback loops, rules, goals Medium to high — shapes what the system does over time Publishing emissions data publicly; changing a quota to a tradeable permit
Paradigms (strongest) The shared beliefs and goals that built the system Very high — everything else grows out of the paradigm Shifting from "growth is always good" to "sustainable profit"; from "bugs are the programmer's fault" to "systems fail"

The four most practical leverage points for builders

  1. Information flows. Who sees what data, and when? Meadows wrote that "missing feedback is one of the most common causes of system malfunction." Adding a real-time dashboard for customer churn — when before you only saw it quarterly — is a leverage-point intervention, not a cosmetic one.
  2. Rules of the system. Incentives, constraints, and policies drive behavior far more than exhortation. Changing a sales commission from "units sold" to "customer retained after 90 days" changes behavior across thousands of interactions automatically.
  3. Goals of the system. What the system is optimizing for is a very deep lever. A hospital that measures success as "beds filled" behaves completely differently from one that measures "patients discharged healthy." Same staff, same building, different goal — different system.
  4. Paradigms. The shared mental model held by the people inside the system. This is the hardest to shift and the most powerful. When Amazon shifted from "we sell books" to "we are a logistics and infrastructure company," everything else — hiring, product decisions, capital allocation — changed.
Common mistake: Most organizations spend 90% of their change effort on numbers (cut costs by 5%, increase headcount by 3) and almost nothing on information flows or goals. The result is lots of activity and little lasting change. Next time you try to fix something, ask: am I tweaking a number, or am I changing a feedback loop?
Key takeaway: Meadows showed that where you intervene matters more than how hard you push. Changing a paradigm or a goal moves the whole system; changing a parameter barely nudges it. Always ask, "Am I at a high-leverage point or a low one?"

2. A Curated Latticework of Mental Models

Investor Charlie Munger spent decades arguing that the best thinkers do not rely on one discipline — they build what he called a "latticework of mental models" drawn from many fields: psychology, economics, biology, physics, history. Each model is a lens. No single lens shows you everything. But when you look at a problem through several lenses at once, the picture becomes surprisingly clear. Munger estimated that 80–90 thinking tools handle the bulk of the mental work behind wise decisions.

Below are the highest-value models for builders and decision-makers, each with a tight definition and one concrete example.

2.1 Second-Order Thinking ("And then what?")

Definition: First-order thinking asks, "What happens next?" Second-order thinking asks, "What happens after that — and after that?" Most people stop at the first obvious consequence. Second-order thinkers trace the chain of reactions that follow.

Example: A city bans cars from the center to reduce pollution (first order: less car exhaust). Second-order: more people take the bus → buses get overcrowded → bus quality drops → people buy scooters → scooter accidents rise. Planners who only thought first-order were blindsided. Planners who thought second-order built park-and-ride infrastructure in advance.
Best practice: After any important decision, write out at least two levels of consequence. Ask "and then what?" twice. The second answer is usually the one that bites you.

2.2 Inversion ("Work backwards from failure")

Definition: Instead of asking "How do I succeed?" ask "What would guarantee failure?" Then avoid those things. Munger credited the 19th-century mathematician Carl Jacobi with the original insight: "Invert, always invert." Munger applied it relentlessly — rather than asking how to get rich, he listed every reliable way to become poor and avoided them.

Example: A startup wants to build a loyal user base. Inversion: What destroys user trust? Hidden charges, slow support, data leaks, and features that break without warning. Fix those first. The positive goal ("be trustworthy") is vague; the inverted list is actionable.
Analogy: A pilot runs a pre-flight checklist not to ensure success but to eliminate known failure modes. Aviation's safety record comes from inversion — systematically ruling out everything that crashes planes.
Key takeaway: Avoiding stupidity is often more reliable than pursuing brilliance. Inversion finds the landmines before you step on them.

2.3 Opportunity Cost ("Every yes is a no to something else")

Definition: Opportunity cost is the value of the best alternative you give up when you make a choice. Every resource — money, time, attention — spent on one thing cannot be spent on another. Economists define it as "the value of the next-best forgone alternative."

Example: You spend six months building a new feature your top customer asked for. Opportunity cost: you did not spend those six months acquiring ten new customers. The feature may be worth it — but only after you've consciously compared the two, not by default.
Common mistake: People compare a decision to doing nothing ("is this better than zero?") instead of comparing it to the next-best real option. Opportunity cost thinking forces the real comparison.

2.4 Margin of Safety

Definition: Build in a buffer between what you expect and what you need to survive. The term comes from engineering (and was popularized in investing by Benjamin Graham and then Warren Buffett): if a bridge must support 10,000 pounds, you build it to hold 30,000 pounds. That 20,000-pound buffer is the margin of safety.

Example: You estimate a product launch needs $50,000. A margin-of-safety thinker budgets $75,000. When the packaging supplier raises prices mid-run — as they almost always do — the project survives. Without a buffer, the project fails not because the idea was wrong, but because there was no room for any surprise.
Expected outcome ----[buffer zone]---- Danger zone
       |                  |                |
  Best case         Actual result      Break point

The buffer = margin of safety. It keeps "worse than expected"
from becoming "catastrophic."

2.5 Circle of Competence

Definition: The set of topics and domains where you genuinely understand cause and effect — not just surface knowledge, but deep understanding. Warren Buffett and Charlie Munger built Berkshire Hathaway by staying relentlessly inside their circle and admitting clearly where the circle ended. Buffett's line: "The size of your circle is not very important; knowing its boundaries, however, is vital."

Example: Buffett avoided technology stocks for decades — not because they were bad investments, but because he could not reliably predict which companies would win. When he finally bought Apple, it was after years of studying consumer behavior and brand loyalty, domains he did understand. He expanded the circle through genuine learning, not wishful thinking.
Best practice: Keep a list of three columns: things you know well, things you are learning, things you should admit you do not know. The third column protects you from confident ignorance.

2.6 Map vs. Territory

Definition: In 1931, the Polish-American thinker Alfred Korzybski stated: "The map is not the territory." Any model, plan, spreadsheet, or belief is a simplified representation of reality — not reality itself. Maps are useful precisely because they leave things out. But they can mislead if you forget that they are abstractions.

Example: A financial model says a new market will be worth $500M by 2028. The model is a map — it was built with assumptions about growth rates, customer behavior, and competitive response, all of which could be wrong. Founders who treat the model as the territory bet the company on it. Founders who treat it as a map use it to navigate while staying alert for terrain that does not match the paper.
Common mistake: Confusing the org chart (a map of authority) with how decisions actually get made (the territory). The real power structure is almost never the org chart.
Key takeaway: Every mental model, plan, and belief is a map. Update the map when the territory contradicts it — do not update the territory to match the map.

2.7 Occam's Razor

Definition: Among competing explanations, prefer the one that requires the fewest assumptions. Named after William of Ockham, a 14th-century English friar and logician, this principle is also called the "law of parsimony." Complexity is not free — each additional assumption is another place where an explanation can break down.

Example: Your app's conversion rate drops 30% overnight. Possible explanations: (A) a major competitor launched a better product AND your ad spend algorithm shifted AND there was a national mood change — or (B) a bug broke the checkout page. Occam's Razor says: check B first. The simplest explanation consistent with the facts is usually correct.
Common mistake: Occam's Razor does not say "the simplest story is always true." It says, start there, and only add complexity when the evidence demands it. Reality is sometimes genuinely complex — the tool is about where to begin, not where to stop.

2.8 Hanlon's Razor

Definition: "Never attribute to malice that which can be adequately explained by negligence, ignorance, or incompetence." This principle helps you interpret other people's behavior without immediately assuming bad intent. It is closely related to Occam's Razor applied to human motivation.

Example: A co-founder misses three important deadlines. You could conclude they are sabotaging the project (malice). Hanlon's Razor suggests first checking whether they are overwhelmed, confused about priorities, or struggling personally (incompetence or ignorance). The Hanlon interpretation is almost always right — and it preserves the relationship long enough to find out.
Best practice: When someone's action hurts you, run through this sequence before reacting: Could this be an error? Could this be ignorance? Could this be poor judgment? Only if none of these fit should you consider intent.

2.9 Base Rates ("What usually happens?")

Definition: A base rate is the historical average outcome for a class of events. It tells you what usually happens before you factor in any specific detail about your situation. Daniel Kahneman and Amos Tversky showed in their research that people chronically ignore base rates — they call this base rate neglect — and instead focus on the vivid story in front of them.

Kahneman described the fix as taking the "outside view": look at what happened to a hundred similar projects before you forecast your own. The inside view — your specific plan, your specific team, your optimism — is the map. The base rate is the territory.

Example: A team estimates their software project will take four months. A colleague who has seen many similar projects points out that projects of this type typically take seven to nine months. Kahneman's research documented exactly this pattern: teams were consistently overoptimistic until they consulted the outside-view base rate. Starting with the historical average and adjusting from there produces far better forecasts.
Analogy: Before you bet on a horse, check its racing record — not just how good it looked in the warm-up. The record is the base rate. Your impression of the warm-up is the inside view. Bet with the record first.
Key takeaway: Whenever you make a forecast, your first question should be: "What is the base rate for situations like mine?" That number is your anchor. Only move away from it when you have strong, specific evidence that your situation is genuinely different.

3. Building Your Personal Latticework

Munger did not just collect models — he wired them together. A latticework, not a list. Here is how to build one in practice:

  1. Learn one model at a time, deeply. Read the original source (Meadows on leverage points, Kahneman on base rates). A shallow understanding of ten models is weaker than a deep understanding of three.
  2. Apply it to a real decision within a week. A model that has never touched a real situation stays inert. Force yourself to use it once before moving on.
  3. Notice where models conflict. Occam's Razor says prefer the simple explanation. Second-order thinking says dig deeper into consequences. The tension is real — and navigating it is where judgment lives. The conflict means you are thinking, not just following a script.
  4. Build a "decision journal." Write down what model you applied, what you predicted, and what actually happened. Review it quarterly. You will quickly see which models you overuse, which you forget, and where your blind spots are.
  5. Steal from every discipline. Munger drew on economics, biology, psychology, physics, and history. The models that come from outside your field are often the most powerful — precisely because none of your competitors are using them.
         LEVERAGE POINTS
         (where to push)
               |
    +----------+----------+
    |                     |
  Paradigms           Numbers
  (strongest)         (weakest)
               |
         MENTAL MODELS
         (how to see clearly)
               |
   +-----------+-----------+
   |           |           |
Second-    Inversion   Base rates
order      (avoid      (outside
thinking   failure)    view)
   |           |           |
Map vs    Occam /    Opportunity
territory Hanlon's   cost /
          Razor      Margin of
                     safety

Each model is a lens. The latticework
uses several at once.
Best practice: When facing any significant decision, run it through at least three lenses before acting. Try: (1) What is the base rate? (2) What does inversion say — how could this fail? (3) What is the opportunity cost of saying yes? Three models, one decision. You will catch things a single-lens view misses every time.
Key takeaway: Meadows showed that pushing at the right point in a system beats pushing harder at the wrong one. Munger showed that seeing the right point requires many different lenses — not one. Together: find the leverage point using your latticework of models, and small, well-aimed effort compounds into large, lasting results.

Continue reading