Part 0 · 2 chapters · ~12 min
Systems Thinking, Applied
The iceberg model from events to mental models, causal loop diagrams drawn for real engineering problems, system archetypes in organisations (fixes that fail, shifting the burden, limits to growth, tragedy of the commons), and intervening at the right level.
1
Events, patterns, structures, beliefs
Systems Engineering part 7 introduced stocks, flows, loops and leverage. This part applies them to the problems engineers actually argue about.
THE ICEBERG MODEL
events are the visible tip; structure produces them
swipe the figure sideways, or tap expand for full screen
1/4
events
Most conversations stay at events: what happened, who fixed it. Reacting to events fixes today and changes nothing.
what happenedreact and repeat
2
Archetypes you will meet
| archetype | shape | engineering example | way out |
|---|---|---|---|
| fixes that fail | a quick fix relieves the symptom and worsens the cause later | raising timeouts to hide a slow dependency, which then piles up connections | fix the cause; watch for side effects with a delay |
| shifting the burden | a symptomatic solution weakens the fundamental one | a hero engineer fixes every incident, so nobody else learns | invest in the fundamental capability while using the quick fix |
| limits to growth | growth hits a constraint that slows it | hiring more engineers until coordination costs dominate | find and lift the limiting factor before pushing harder |
| tragedy of the commons | shared resource overused by individually rational actors | a shared CI pool or database used by every team without quotas | feedback of usage to users, quotas, ownership |
| success to the successful | winners get more resources and win more | one team gets all the platform attention | deliberate balance of investment |