An algorithm is a finite, unambiguous sequence of steps that transforms inputs into outputs. No ambiguity, no infinite loops in the intended design — given the same input, the same steps produce the same result. The power of the mental model is not code syntax but the habit of decomposing problems into repeatable procedures whose correctness and cost you can reason about.
Algorithms force clarity. You must specify the order of operations, the branching logic, and the stopping condition. That discipline transfers: strategy becomes a set of decision rules; process becomes a procedure; diagnosis becomes a flowchart. The alternative is ad hoc reaction — no guarantee of consistency or optimality.
Complexity matters. An O(n²) process that works on 100 items may collapse on 10 million. Linear scaling beats quadratic when data grows. Founders and operators who think algorithmically ask: what is the bottleneck step? How does runtime or cost scale with size? When does this procedure break?
The model has roots in formal logic and early computing — Al-Khwarizmi's name gave us the word — but the mental-model use is broader: any domain where you want repeatable, improvable procedures. Business processes, hiring funnels, and investment checklists are algorithms in disguise. Making them explicit lets you debug and optimise them.
Section 2
How to See It
You see algorithms wherever a fixed sequence of steps is applied to get a result. The diagnostic: inputs in, steps executed in order, outputs out. When someone says "we always do X then Y then Z," they are describing an algorithm. When a system scales poorly as load grows, the underlying procedure likely has the wrong complexity.
Business
You're seeing Algorithms when a support team follows a triage flowchart: severity tag → routing rule → SLA timer → escalation path. The same inputs (ticket type, customer tier) produce the same routing. Changing one step changes outcomes predictably. The procedure is the product.
Technology
You're seeing Algorithms when a recommendation engine ranks items by a scoring function (clicks, recency, diversity). The steps are fixed; the output depends only on input features. Optimising the algorithm means changing weights or order of operations, not ad hoc overrides.
Investing
You're seeing Algorithms when a quant fund runs a defined set of signals and position rules on every bar. No discretion on the rule set — only on which algorithms run. The edge is in the procedure's design and its behaviour under different regimes.
Markets
You're seeing Algorithms when matching engines execute orders by price-time priority or other deterministic rules. Market structure is literally algorithmic; understanding it means understanding the sequence of steps that clears trades.
Section 3
How to Use It
Decision filter
"Before building a process or system, write the algorithm: inputs, steps, stopping condition, and how cost scales with size. If you can't write it, you don't understand it. Then improve the bottleneck step first."
As a founder
Make critical processes algorithmic. Onboarding, qualification, pricing, support escalation — define the steps so they are repeatable and debuggable. The benefit is not rigidity; it's that you can change one step and see the effect. Avoid the trap of "we use judgment" where judgment means no written procedure — you can't improve what isn't specified.
As an investor
Evaluate companies by the quality of their key algorithms: matching, ranking, allocation, risk. When a founder says "our secret sauce is data," ask: what exact procedure turns data into decisions? If the answer is vague, the edge may be fragile. Scalable advantages often sit in procedures that compound with data and distribution.
As a decision-maker
Use algorithmic thinking to stress-test decisions. What is the worst-case input? What is the step that dominates cost or time? When would this procedure produce a wrong or dangerous output? Making the steps explicit exposes hidden assumptions and failure modes.
Common misapplication: Treating algorithms as replacing judgment. They encode repeatable logic; they don't handle unanticipated inputs or regime changes. The right move is to bound where the algorithm applies and where humans override. Second misapplication: Optimising the wrong step. Measure which step dominates cost or latency before optimising; otherwise you polish a non-bottleneck.
Bezos pushed Amazon to make operations algorithmic: fulfilment centre workflows, demand forecasting, and pricing are driven by explicit procedures and metrics. The "two-pizza team" and "single-threaded owner" rules are organisational algorithms — repeatable steps for how teams form and who owns what. Scaling required turning judgment into systems that could be improved incrementally.
Renaissance's edge is algorithmic. Trading signals and risk rules are encoded in procedures that run without discretionary override on each bar. Simons' contribution was insisting on mathematical clarity: every step specified, every assumption testable. The result is repeatable performance that scales with data and compute rather than human intuition.
Section 6
Visual Explanation
Algorithms: inputs → finite steps (sequence, branch, loop) → outputs. Complexity (e.g. time vs input size) determines scalability.
Section 7
Connected Models
Algorithms sit alongside other models that deal with structure, scaling, and clarity of process. The connections below either reinforce procedural thinking, extend it to design patterns, or create tension with judgment and adaptability.
Reinforces
Divide and Conquer
Breaking a problem into subproblems, solving each, and combining results is the classic algorithmic strategy. It reinforces the habit of specifying steps and understanding how complexity compounds or reduces.
Reinforces
First Principles Thinking
First principles reduce a domain to basic truths; algorithms turn those truths into executable steps. Both demand explicit reasoning instead of copying existing solutions.
Tension
Bottlenecks
Bottlenecks are the steps that limit throughput. Algorithmic thinking identifies them; optimisation focuses there. The tension: improving a non-bottleneck step wastes effort — you must analyse before optimising.
Tension
Bounded Rationality
Humans have limited computation. Algorithms can extend reach but may assume perfect information or stable environments. The tension is between procedural rigor and the need to adapt when the world doesn't match the spec.
Leads-to
Optimization
Section 8
One Key Quote
"An algorithm must be seen to be believed."
— Donald Knuth
Until the procedure is written down or implemented, it's a claim, not a shared reality. Making it visible is the first step to debugging, improving, and scaling it.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Treat your key business processes as algorithms. If you can't write the steps, you can't reliably improve them. Onboarding, pricing, support, and go-to-market all have inputs, steps, and outputs. Document them. Then attack the step that dominates cost or time.
Complexity scales. A process that works at 100 customers may break at 100,000. Ask how each step scales with volume, and design for the size you're targeting. Linear beats quadratic; constant beats linear where you can get it.
Specify the domain of applicability. Algorithms assume well-defined inputs. When reality is messy or regime shifts, build in exit conditions: when to escalate, when to stop, when to hand off. The best systems combine clear procedures with clear boundaries.
Section 10
Test Yourself
Is this mental model at work here?
Scenario 1
A company uses a fixed checklist for every sales qualification call: budget, authority, need, timeline. Same questions, same order, same pass/fail criteria.
Scenario 2
A fund manager says they 'use judgment' to pick stocks and have no fixed criteria.
Scenario 3
A fulfilment centre processes orders with a fixed sequence: receive → pick → pack → ship. Each step has defined inputs and handoffs.
Scenario 4
A team 'feels out' which deals to prioritise each week with no written criteria.
Section 11
Summary & Further Reading
Summary: An algorithm is a finite, unambiguous procedure that turns inputs into outputs. Use it to make processes explicit, find bottlenecks, and reason about scaling. Apply it to strategy, operations, and product — and specify where the procedure stops and judgment takes over.
Rigorous treatment of what procedures can and cannot compute. Clarifies the boundary between algorithmic and non-algorithmic problems.
Once a procedure is explicit, you can optimise it — fewer steps, better complexity, clearer branching. Optimization is the natural next step after algorithm design.
Leads-to
[Abstraction](/mental-models/abstraction)
Algorithms abstract away implementation detail; you reason about inputs, steps, and outputs. Abstraction lets you reuse the same structure across domains (e.g. "sort" in data, "prioritise" in strategy).
