Recursion is when a process or structure is defined in terms of itself: a function calls itself, a structure contains a smaller instance of the same structure, or a problem is reduced to a smaller version of the same problem. The recursion has a base case — a stopping condition — so that the chain of self-reference terminates. Without a base case, you get infinite regress or stack overflow. With it, recursion is a compact way to express repetition and hierarchical structure.
In computation, recursion often replaces explicit loops: instead of "do this N times," you say "do this once, then do the same thing on the remainder." The classic examples are factorial (n! = n × (n−1)! with base case 0! = 1), tree traversal (process a node, then recurse on each child), and divide-and-conquer (solve half the problem, recurse, combine). The mental move is to see that the problem at size N can be expressed as one step plus the same problem at size N−1 (or N/2), and to identify the smallest case that doesn't need further reduction.
Outside code, recursion appears in definitions (a sentence contains clauses that can contain sentences), in organisations (a team contains sub-teams of the same structure), and in strategy (a goal decomposes into sub-goals of the same type). The discipline is to spot when a situation is "the same thing at a smaller scale" and to define the base case so the recursion stops. The mistake is recursing without a base case (infinite loop) or confusing levels (treating the base case as if it were the recursive case).
Tail recursion — when the recursive call is the last action and its result is returned directly — can be optimised to a loop by compilers, avoiding stack growth. That's an implementation detail; the mental model is unchanged: reduce to a smaller instance, define the base case, and ensure termination. In design and strategy, the equivalent is "one level of decomposition plus the rule for the next level" with a clear stopping point.
Section 2
How to See It
Look for situations where the same operation or structure repeats at smaller scale — a part that mirrors the whole, or a problem that reduces to a smaller instance of itself. When you can say "to do X, do one step and then do X again on what's left," recursion is the right frame.
Business
You're seeing Recursion when a company's org structure repeats at every level: each division has the same functions (eng, product, sales) as the parent, and each team has the same roles. The structure is recursively defined — same pattern, smaller scale.
Technology
You're seeing Recursion when a data structure (e.g. tree, graph) is processed by "handle this node, then handle each child the same way." The algorithm doesn't list every node; it defines behaviour at one node and recurses. The code is short because the structure is self-similar.
Investing
You're seeing Recursion when a valuation or model is built from smaller units of the same type (e.g. segment value = sum of customer values; customer value = sum of transaction values). The same logic applies at each level; the base case is the smallest unit (e.g. single transaction).
Markets
You're seeing Recursion when a market is analysed as aggregates of sub-markets that share the same structure (e.g. regional markets that each have supply, demand, and price). The analysis recurses until you hit a base level (e.g. individual buyer/seller).
Section 3
How to Use It
Decision filter
"When a problem or structure repeats at smaller scale, define it recursively: what is the one step, and what is the same problem on the remainder? Identify the base case — the smallest instance that doesn't need further reduction — and ensure every path reaches it. Use recursion to simplify: solve the small case, then build up."
As a founder
Decompose goals and orgs recursively. A company goal becomes team goals of the same form; a team goal becomes individual goals. The base case is the unit that can act without further decomposition. Design processes and structure so that the same pattern repeats at each level — it's easier to reason about and to scale. Watch for missing base cases: initiatives that never land because they're always "one more level down."
As an investor
Build models and theses recursively where possible. Value = sum of parts; each part may be the same kind of object (e.g. user, segment, geography). The base case is the unit you can value directly. Recursive thinking helps avoid double-counting and keeps the structure clear. When someone presents a non-recursive pile of assumptions, ask: what's the repeated structure and what's the base case?
As a decision-maker
When analysing a complex system, ask whether it's self-similar: does the same logic apply at each level? If yes, define the rule and the base case. Recursion makes the analysis tractable — you don't have to enumerate every level; you describe one level and the recurrence. Use it for planning (milestones that decompose into sub-milestones) and for debugging (trace the recursion to find where the base case or the step fails).
Common misapplication: Recursing without a base case. In strategy and org design, that means endless decomposition — "we need to go one level deeper" — without ever defining the unit that acts. In code, it means stack overflow. Always specify when the recursion stops.
Second misapplication: Using recursion when iteration is clearer. In some languages and problems, a loop is simpler and more efficient. Recursion is best when the structure is naturally self-similar (trees, nested data, goals that decompose). Don't force recursion where a simple loop does the job.
Bezos's "two-pizza teams" and the idea of small, autonomous units that mirror the whole (ownership, metrics) is a recursive org design. Each team is a smaller instance of the same structure — same accountability, same customer focus. The base case is the team that can ship without depending on another team. Scale is achieved by adding more instances of the same recursive unit.
Jobs's product philosophy — "focus and simplicity" — often meant recursive decomposition: a product is a small set of features, each of which is a small set of sub-features, down to a base level of "one thing done well." The structure of the product (and the org that built it) was self-similar at each level; the base case was the single, shippable element.
Section 6
Visual Explanation
Recursion — Same operation at smaller scale. Each step does one unit of work and recurses on the remainder. Base case (e.g. n=0 or empty list) stops the chain. Value propagates back up.
Section 7
Connected Models
Recursion underlies divide-and-conquer, abstraction, and hierarchical structure. The models below either reinforce it (divide and conquer, algorithms), create tension (feedback loops, abstraction), or extend to practice (modularity, first principles).
Reinforces
Divide and Conquer
Divide and conquer splits a problem into smaller sub-problems of the same type, solves them (often recursively), and combines results. Recursion is the mechanism: the "solve them" step is a recursive call. The reinforcement: divide-and-conquer algorithms are recursive by construction. When you see a problem that splits into smaller versions of itself, recursion is the implementation.
Reinforces
Algorithms
Algorithms are step-by-step procedures. Many fundamental algorithms are recursive: merge sort, quicksort, tree traversal, dynamic programming recurrences. The reinforcement: recursion is a core algorithmic technique. Understanding recursion is necessary to understand a large class of algorithms.
Tension
[Feedback](/mental-models/feedback) Loops
Feedback loops are cycles where output feeds back as input. Recursion is a controlled form of self-reference with a base case; feedback loops can be unbounded (positive feedback) or equilibrium-seeking (negative). The tension: recursion terminates by design; feedback loops may or may not. Use recursion when you want guaranteed termination (smaller instance); use feedback when you're modelling ongoing dynamics.
Tension
Abstraction
hides detail and works at a level of generality. Recursion often relies on abstraction: "do the same thing at the next level" assumes that "the same thing" is well-defined. The tension: recursion can obscure what's happening at each level if you're not careful; abstraction can make the base case unclear. Together they're powerful — abstract the step, recurse, and make the base case explicit.
Section 8
One Key Quote
"Processes that evolve by recursion are characterized by the fact that they are defined in terms of themselves. To understand such processes, we need to distinguish between the shape of the process (the chain of deferred operations) and the shape of the procedure (the syntactic fact that the procedure calls itself)."
— Structure and Interpretation of Computer Programs (SICP), MIT
The quote separates the procedure (the code that calls itself) from the process (the chain of steps). The practical lesson: when you reason recursively, focus on the process — what shrinks, what the base case is, and how results combine. The "calling itself" is just the mechanism; the clarity comes from the recurrence and the base case.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Spot self-similarity. When a problem or structure is "the same thing at a smaller scale," define it recursively. That gives you a single rule and a base case instead of an ad hoc list of levels. Orgs, goals, and many algorithms are naturally recursive.
Always have a base case. In strategy, the base case is the unit that can act — the team, the person, the milestone that doesn't decompose further. Without it, recursion never stops and nothing ships. In code, missing base case means stack overflow. Check: does every path reach the base case?
Use recursion to simplify. Instead of enumerating every level, state the rule and the base case. The rest follows. That's why recursive code is often short and why recursive org design scales — you're not designing every level; you're designing one level and the recurrence.
Don't force it. Some problems are clearer as loops or as flat structures. Use recursion when the structure is genuinely self-similar. When it's not, iteration or explicit hierarchy may be clearer.
Section 10
Test Yourself
Is this mental model at work here?
Scenario 1
A company sets a North Star metric, then each team sets a metric that rolls up to it. Each team's metric is the sum of sub-team metrics that roll up to the team. The structure repeats to the individual contributor.
Scenario 2
A founder keeps saying 'we need to break this down further' and adds more sub-goals and sub-projects but never defines what 'done' looks like at the leaf level.
Scenario 3
A merge-sort implementation splits the array in half, sorts each half (using the same algorithm), then merges the results. The base case is arrays of length 1.
Scenario 4
An org chart shows divisions, each with the same set of functions (eng, product, sales). Each function has the same sub-functions. The pattern repeats to the individual contributor.
Section 11
Summary & Further Reading
Summary: Recursion is defining a process or structure in terms of itself, with a base case that stops the chain. In computation it replaces explicit loops for self-similar problems (trees, divide-and-conquer). In orgs and strategy it appears when the same structure or goal repeats at smaller scale (teams within teams, goals within goals). Use it to simplify: state the recurrence and the base case instead of enumerating every level. Always define the base case so recursion terminates. Connected to divide-and-conquer, algorithms, modularity, and first-principles thinking.
Modularity is decomposing a system into interchangeable parts. Recursive structure is a form of modularity: each level is a module that contains smaller modules of the same type. The connection: when you design recursively, you get modularity — the same pattern at each level. Modularity enables recursion (you can recurse on a module).
Leads-to
First Principles Thinking
First principles thinking breaks a problem down to fundamentals. Recursion is one way to do that: reduce to a smaller instance until you hit the base case — the "first principle" or atomic unit. The connection: recursive decomposition can take you to first principles; the base case is often where the fundamental building block lives.
