Systems Thinking in Practice

Most engineers learn to decompose problems. Break the system apart, solve each piece, reassemble. This works remarkably well — until it doesn’t.

The failures tend to cluster at interfaces: where one team’s model meets another’s, where software meets physics, where a market assumption meets operational reality. These boundaries are where feedback loops hide, where delays create oscillation, and where local optimizations produce global dysfunction.

Start with the loop, not the component

When I approach a new domain, I resist the urge to catalog parts. Instead, I ask:

• What flows through this system?
• What accumulates?
• What information is delayed?
• Who optimizes for what, and on what timescale?

A battery storage project and a distributed software platform look nothing alike on the surface. But both involve buffers, capacity constraints, and actors making decisions with incomplete information. The vocabulary changes; the structure rhymes.

Models are maps, not territory

Every model is wrong. The useful ones make trade-offs visible before you commit.

I keep sketches — literal notebook sketches — of the systems I’m trying to understand. Not for presentation. For thinking. A diagram forces you to name relationships you’d otherwise hand-wave.

// A trivial example: feedback with delay
function simulate(buffer: number, inflow: number, outflow: number, delay: number) {
  const delayed = buffer; // reality is messier
  return buffer + inflow - outflow * (1 + delay / buffer);
}

The code isn’t the point. The act of writing it is: you discover which variables you don’t actually understand yet.

Teaching as a test of understanding

I have a simple heuristic: if I can’t explain a system to someone outside the domain without jargon, I don’t understand it well enough to build in it.

Teaching — whether formally or in conversation — is the best compression algorithm I know. It reveals which abstractions carry weight and which are decorative.

Closing thought

Systems thinking isn’t a credential. It’s a habit: zoom out before you zoom in, look for loops before you optimize nodes, and stay curious about the problem behind the problem.

The world is full of complex systems. The work is learning to see them clearly enough to build something useful inside them.