Systems Thinking: Every Problem Is a Graph

A business is not a list of tasks. It is a graph. Customers, products, channels, costs, feedback loops — every node depends on others, often in non-obvious ways. The founder's job is to see the graph clearly enough to know which edge, if perturbed, moves the entire structure.

Most operational work fails because it treats symptoms — nodes — instead of structure — edges. You can hire harder, ship faster, post more, and still go nowhere, because the underlying graph guarantees the outcome you are getting.

First-order thinking asks: what happens if I do X? Second-order thinking asks: and then what? And then what after that?

A founder who can hold three or four steps of consequence in their head at once will routinely make decisions that look strange in the short term and obvious in retrospect. This is the same instinct that drives good long-term infrastructure choices — choosing the option that is worse this quarter and better for the next decade.

Every meaningful business is, at its core, a small number of feedback loops. A customer uses the product, gets value, refers another customer. Content goes out, builds trust, brings inbound. Data comes in, sharpens the model, improves the output, attracts more data.

Find the loops. Strengthen the loops. Remove friction from the loops. Almost every other optimisation is a rounding error compared to that.

This is why agentic workflows matter so much right now. They are, structurally, loop accelerators. They let a small team run more iterations of the same feedback cycle per unit of time than was previously possible.

Every system has, at any given moment, exactly one binding constraint. One bottleneck that determines the throughput of the whole. Everything else is, by definition, slack.

Founders who think in systems spend an unusual amount of time identifying the current bottleneck and an unusual amount of energy attacking it. Everyone else spreads effort evenly across the system and wonders why nothing moves.

A robust system is not one that never fails. It is one that fails in known, contained ways. Good founders design with the assumption that pieces will break — vendors will churn, channels will die, key people will leave — and that the graph should keep functioning anyway.

This is why redundancy, documentation, and clean interfaces between components are not bureaucratic overhead. They are the connective tissue that lets a system survive its own growth.

The more you read across disciplines, the more pattern libraries you have for recognising graphs. Biology, economics, software, physics — they all keep rhyming. Which is, again, why self-education sits at the root of everything else on this site.

A founder with deep cross-disciplinary fluency does not need to invent new mental models. They just need to recognise which existing one fits the problem in front of them.