⌘ The Architecture Reference

Path systems thinking · The Architect's Path · Intermediate

Emergence and Complexity

Complex systems produce emergent behavior the parts don't have alone — which makes them counterintuitive, sociotechnical, and best understood through pattern thinking rather than catalog-applying.

Path systems thinking Intermediate ⏱ 5 min read Complete

🏘️ Analogy

A property map shows a neighborhood’s boundaries, houses, school, and police station — and tells you almost nothing about how it actually behaves. A factory closing, gentrification, a traffic change, or a pandemic transforms a neighborhood because of the relationships among its elements, none of which appears on the map. Software systems are the same: the map is not the system.

A system is complex when relationships among the parts generate impacts and behavior the individual parts do not produce on their own. This is emergence — the sum is greater than the parts — and it is why complex systems are not fully predictable or controllable, no matter how well you understand each component.

Relationships produce effects

As Meadows put it, “parts together produce an effect different from the effect of each part on its own.” You must understand not just “one” and “two” but “and.” This makes systems thinking inescapably sociotechnical: “you can’t improve the technology system without improving the people system, and vice versa. From a systems perspective, they are one and the same.”

⚠️ Counterintuitiveness is inescapable

Leverage-point changes don’t match what we already know, so “hardly anybody will believe us” (Meadows). Worse, Forrester observed that organizations often find the leverage point and then push it “in the wrong direction.” Brooks’s law is the classic example: “adding manpower to a late software project makes it later.” Every action in a complex system is, in effect, an experiment.

The same event, different patterns

Because behavior is emergent, the same visible event can stem from radically different underlying patterns — and the right response depends entirely on which:

graph TD
E["Event: a service outage"]
E --> A["Pattern A:<br/>rare third-party cascade"]
E --> B["Pattern B:<br/>'the 32nd time this year'"]
A --> AR["Healthy triage +<br/>small preventive changes"]
B --> BR["Self-reinforcing loop:<br/>blame, burnout, churn,<br/>'10x developer' hunt"]
BR -.->|"until mental models change"| DEAD["whole system stuck<br/>despite constant drama"]

Diagnose the pattern before intervening. An outage that is a one-off cascade calls for calm triage; an outage that is “the 32nd time this year” signals a self-reinforcing pattern of blame culture and churn that no amount of triage will fix until the mental models change.

Pattern thinking

Montalion reframes “patterns” away from the software meaning (design patterns to apply) toward detective work: spotting a recurring pattern, understanding the forces that reinforce it, and noticing how it changes as it repeats. Look in five places:

  • Relationship to time — does it repeat? “The best way of doing things yesterday might be the worst thing to do today” (good practices become tomorrow’s tech debt).
  • Relationship to context — leverage points completely depend on context; what works for Netflix won’t work the same elsewhere or next year.
  • Relationships to other parts — decoupling and modernization are changes to relationships.
  • Relationship to structures — patterns are held by structures (hierarchy, delivery methods, infrastructure).
  • In your own thinking — “the most important place to look. Sometimes the hardest thing to change in a system is your own thinking.”

🔑 Three intersecting pattern types

Patterns come in three kinds: external (beyond the software boundary — UI expectations, hiring practices, funding), technology (layers, reusability, what parts communicate and what they don’t), and process (delivery, decision-making, role boundaries). Systems thinking reasons about how the three intersect to discern where to intervene.

Patterns are the choreography of a system — “patterns you don’t design will emerge anyway.” Use the seven pattern-thinking questions to surface them: How does information flow? What events happen? What are the boundaries? What are the building blocks? What is the delivery process? How are people organized? How is discourse structured?

graph TD
EX["External patterns<br/>UI expectations, hiring, funding"] --> INT["Where to intervene"]
TE["Technology patterns<br/>layers, reusability, coupling"] --> INT
PR["Process patterns<br/>delivery, decisions, roles"] --> INT
PR -.->|"the lever that changes the others"| EX
PR -.->|"the lever that changes the others"| TE

💡 Process patterns are the lever

Montalion stresses process patterns “not because they’re the most important, but because they’re the ones that must change in order to change other types of patterns.” When in doubt, follow the money. And a common root structure beneath chaos is fear — “deliver quickly or we die” rarely delivers faster.

See also

When to use it — and when not

✅ Reach for it when

  • When a system's behavior surprises you and the parts seem fine in isolation.
  • When the same recurring event hides radically different underlying patterns.
  • When you need to diagnose patterns before intervening, rather than reaching for a known fix.

⛔ Think twice when

  • When you treat 'patterns' only as software design patterns to apply from a catalog.
  • When you imagine patterns only along a linear timeline (which keeps you linear).
  • When you trust your first intervention — in complex systems it tends to make things worse.
path-systems-thinkingSystems Thinking Basics

Systems thinking is a practice of nonlinear thinking — seeing stocks, flows, and feedback loops, and using the Iceberg Model to look beneath events to the structures and mental models that cause them.

path-systems-thinkingLeverage Points

Leverage points are places where a small shift produces big change — found by diving the Iceberg to mental models and paradigms, the highest-leverage (and most counterintuitive) places to intervene.

path-systems-thinkingApplying Systems Thinking to Organizations

Organizations are sociotechnical systems — designing software always also designs communication patterns, so leading change means improving knowledge flow through modeling, systemic reasoning, and influence.

Check your understanding

Score: 0 / 4

1. When is a system 'complex' in Montalion's definition?

Complexity is about relationships, not size. Behavior is emergent — the sum is greater than the parts — which is why systems are not fully predictable or controllable.

2. What is 'counterintuitiveness' in systems thinking?

Leverage-point changes feel 'wrong' and provoke disbelief (Meadows). Forrester noted organizations often find the leverage point and then push it 'in the wrong direction'.

3. Why is the same event sometimes caused by completely different patterns?

An outage might be a one-off third-party cascade (healthy triage) or 'the 32nd time this year' driven by burnout and churn — diagnose the pattern before intervening.

4. Why does Montalion emphasize PROCESS patterns above the other types?

Of the three pattern types (external, technology, process), process patterns — delivery, decision-making, role boundaries — are the lever that lets you change the others. 'Follow the money.'

Comments

Sign in with GitHub to join the discussion.