Leif P. HeaneyAI/ML & Systems Engineer
Schedule Meeting

Field guide 01 / Lesson 01

Systems Thinking

Move beyond isolated events to understand boundaries, accumulation, feedback, delay, and emergence.

42 minutes10 sections10 questionsUpdated
On this page
  1. 1. What is a system?
  2. 2. Events, patterns, structures, and mental models
  3. 3. Stocks and flows
  4. 4. Feedback loops
  5. 5. Emergence and unintended consequences
  6. 6. Boundaries and perspectives
  7. 7. Build a causal-loop diagram
  8. 8. Leverage points
  9. 9. Worked case: a recurring support backlog
  10. 10. From seeing systems to shaping them
  11. Worked example
  12. Misconceptions
  13. Glossary
  14. Knowledge check
  15. References

Your destination

Learning objectives

  • Define a system in practical terms and identify its elements, relationships, purpose, environment, and boundary.
  • Distinguish a visible event from patterns, structural relationships, and assumptions beneath it.
  • Explain stocks, flows, delays, reinforcing feedback, and balancing feedback.
  • Recognize emergence and anticipate unintended consequences.
  • Read and create a basic causal-loop diagram.
  • Frame a system of interest from more than one stakeholder perspective.
  • Identify possible leverage points without treating them as guaranteed fixes.
  • Apply systems thinking to a recurring operational problem.

Before you begin

  • No prior systems engineering experience is required.

1. What is a system?

Start by deciding what you are trying to understand—not by cataloging every object you can see.

The parts matter, but the relationships among them often explain the behavior we care about. A help desk, for example, includes people, ticketing tools, policies, requesters, information, and the handoffs that connect them. Removing those relationships leaves a list, not an explanation of service performance. (SEBoK, 2026)

  • Elements: the people, technologies, resources, or ideas involved.
  • Relationships: exchanges of matter, energy, information, money, authority, or influence.
  • Purpose or function: what the system accomplishes or is expected to accomplish.
  • Inputs and outputs: what crosses the selected boundary.
  • Stakeholders: people or organizations affected by, operating, funding, regulating, or depending on the system.
(International Organization for Standardization, 2023; SEBoK, 2026)

Interactive boundary lab

Frame a customer-support system

Choose whether each item belongs inside your system of interest. There is no universal answer; your stated purpose is “understand durable ticket resolution.”

Candidate elements

System of interest

Inside the selected boundary

No elements selected yet.

Select elements, then explain which exchanges cross your boundary.

Text alternative and reflection

A useful boundary for durable resolution could include requesters, support work, the ticket queue, recurring product defects, and the product roadmap. A narrower operational boundary may exclude roadmap decisions but must still show defect information crossing into and out of the system.

2. Events, patterns, structures, and mental models

A single incident tells you what happened once. Systems thinking asks what keeps making similar incidents possible.

What is visible

  • Event: the checkout API failed Friday.
  • Pattern: failures cluster after promotional releases.

What may be underneath

  • Structure: promotion traffic, deployment timing, dependency limits, and on-call handoffs interact.
  • Mental model: “capacity is an infrastructure problem” keeps product scheduling outside the investigation.
(Adcock et al., 2026)

Looking across time helps separate a one-off disturbance from recurring behavior. Looking for structure then shifts attention from blame toward relationships, incentives, information delays, decision rules, and constraints that reproduce the pattern. (Adcock et al., 2026; Meadows, 2008)

3. Stocks and flows

Accumulations create memory: what is in the system now depends on what entered and left before.

Inventory, cash, trained staff, unresolved defects, and open support tickets can all be modeled as stocks. Orders received per hour and tickets resolved per hour are flows. If inflow exceeds outflow, the stock grows even when the outflow is increasing. (Meadows, 2008)

Interactive simulation

Support-ticket stock over 12 hours

Text alternative

The queue begins with 10 tickets. During the delay, arrivals accumulate before resolution starts. After that point, the stock changes each hour by arrivals minus resolutions and cannot fall below zero.

4. Feedback loops

Feedback exists when a change travels through a chain of relationships and eventually influences its own source.

Reinforcing loop (R)

  • More adoption → more user contributions
  • More contributions → more usefulness
  • More usefulness → more adoption

Balancing loop (B)

  • More open tickets → more staffing attention
  • More staffing attention → more resolutions
  • More resolutions → fewer open tickets
(Meadows, 2008)

In feedback, reinforcing does not mean beneficial, and balancing does not mean harmful. Those words describe loop behavior: reinforcing loops amplify change; balancing loops counter change in relation to a goal or constraint. (Meadows, 2008)

A causal-loop arrow marked “+” means the receiving variable changes in the same direction as the source, all else equal. A “−” means it changes in the opposite direction. The signs describe causal direction, not moral value. (Meadows, 2008)

5. Emergence and unintended consequences

Whole-system behavior can arise from interactions even when no single element contains or intends that behavior.

Technical example: independently reasonable retry policies can synchronize after an outage and overload a recovering dependency. Everyday example: each driver selecting the currently fastest route can shift congestion onto the same alternate road. These examples are models for reasoning; their exact outcome depends on timing, capacity, information, and local rules.

Unintended does not mean unpredictable in principle. Mapping relationships, delays, constraints, and feedback can expose plausible consequences before an intervention is deployed. (Adcock et al., 2026; Meadows, 2008)

6. Boundaries and perspectives

A boundary is an analytical choice, not merely a wall drawn around physical equipment.

A commuter may define a transit system around trip reliability. An operator may include fleet maintenance, staffing, signaling, and fare operations. A city planner may also include land use, accessibility, emissions, and connections to housing. None of these boundaries is automatically correct for every decision. (Adcock et al., 2026)

  1. Name the decision or behavior you need to understand.
  2. Choose the time horizon.
  3. Identify stakeholders whose outcomes may change.
  4. Draw an initial boundary and label important exchanges across it.
  5. Test what changes when you widen, narrow, or shift the boundary.
(SEBoK, 2026)

7. Build a causal-loop diagram

A small causal-loop diagram should communicate a hypothesis clearly enough to question and improve it.

  1. Write variables as quantities that can rise or fall.
  2. Connect only relationships you can explain.
  3. Mark each arrow with same-direction (+) or opposite-direction (−) polarity.
  4. Close loops and label them reinforcing (R) or balancing (B).
  5. Mark important delays.
  6. Read the loop aloud and challenge missing conditions.
(Meadows, 2008)

8. Leverage points

Some interventions change a parameter; others change information, rules, goals, or the ability of the system to reorganize.

Meadows organized possible intervention points from parameters and buffer sizes through delays, feedback strength, information flows, rules, goals, and paradigms. She presented the list as an invitation to think more broadly—not as a universal recipe. (Meadows, 1999)

Lower structural reach

  • Add two support agents.
  • Raise a queue alert threshold.
  • Increase a cache size.

Higher structural reach

  • Give teams earlier demand information.
  • Change incentives that create avoidable work.
  • Change the goal from ticket closure to durable issue prevention.
(Meadows, 1999)

9. Worked case: a recurring support backlog

Use the same sequence on a familiar operational problem.

The visible event is a missed service target. The pattern is a backlog that falls after staffing surges and returns several weeks later. A stock-and-flow view represents open tickets as the stock, incoming requests as inflow, and durable resolutions as outflow. (Meadows, 2008)

A plausible reinforcing loop connects backlog pressure, rushed resolutions, repeat requests, and additional backlog. A balancing loop connects backlog, staffing attention, resolution rate, and backlog reduction. Hiring and training delays mean the balancing response arrives after pressure has already changed.

10. From seeing systems to shaping them

Systems thinking improves the questions you ask; architecture turns some of those questions into boundaries and interfaces you can design.

The next lesson examines decomposition. You will use the same attention to purpose, relationships, and consequences to decide which responsibilities belong together, where interfaces should exist, and when modularity adds more coordination cost than value. (Parnas, 1972; Simon, 1962)

Put it together

Frame a support backlog as a system

A product team repeatedly adds people when its support queue exceeds the target, but the queue returns after each temporary improvement. (Meadows, 2008; Adcock et al., 2026)

  1. System of interest: request intake through durable resolution.
  2. Boundary: include product defects, documentation, staffing, triage, escalation, and requester follow-up.
  3. Stakeholders: requesters, support agents, product teams, service owners, and leaders.
  4. Feedback: backlog pressure can increase rushed work, which can increase repeat requests.
  5. Delay: recruiting, onboarding, learning, and product fixes take time.
  6. Intervention hypothesis: improve issue classification and feed recurring causes into product planning.
  7. Tradeoff: diagnosis time may temporarily reduce resolution throughput while lowering future inflow.
Reflect: What important behavior disappears if the boundary includes only the support team?

Check the mental model

Common misconceptions

Myth: A system is merely a collection of components.

Relationships and whole-system behavior are essential to the concept. (SEBoK, 2026)

Myth: The largest component must be the most important.

A small interface, delay, rule, or information path can shape system behavior.

Myth: Every recurring problem has one root cause.

Several feedback loops, constraints, and decisions can jointly sustain a pattern. (Meadows, 2008)

Myth: Optimizing every component optimizes the system.

Local improvements can move cost, risk, or delay elsewhere and degrade the whole.

Myth: Feedback means comments from people.

In systems work, feedback is circular influence through a chain of relationships. (Meadows, 2008)

Myth: More data automatically produces better understanding.

Data becomes useful when paired with a relevant boundary, time horizon, model, and decision.

Remember this

Lesson summary

  • Choose the system of interest and boundary for a specific purpose.
  • Look beneath events for patterns, structures, assumptions, and delays.
  • Stocks accumulate; flows change them.
  • Reinforcing loops amplify change; balancing loops oppose change relative to a goal.
  • Emergent behavior belongs to the whole created by interactions.
  • Treat leverage points as hypotheses to test, not guaranteed fixes.

Key language

Glossary

System
An arrangement of interacting elements that together exhibit behavior or meaning not provided by the elements separately. (SEBoK, 2026)
System of interest
The system selected as the focus of an analysis, design, or decision, together with a boundary chosen for that purpose. (International Organization for Standardization, 2023; SEBoK, 2026)
Boundary
The analytical separation between the system of interest and its environment; it identifies what is treated as inside, outside, and crossing between them. (SEBoK, 2026)
Environment
The external conditions and entities that interact with or influence the system of interest. (SEBoK, 2026)
Stock
An accumulation that changes over time through its inflows and outflows. (Meadows, 2008)
Flow
A rate that increases or decreases a stock over a period of time. (Meadows, 2008)
Feedback
Circular causation in which a change travels through relationships and eventually influences its own source. (Meadows, 2008)
Reinforcing feedback
A closed chain of influence that amplifies change in the same direction, producing growth or decline until another limit becomes dominant. (Meadows, 2008)
Balancing feedback
A closed chain of influence that acts against a change and tends to move a stock or condition toward a target or constraint. (Meadows, 2008)
Emergence
Behavior or meaning attributable to a whole that is not attributable to its individual elements in isolation. (SEBoK, 2026)

Apply what you learned

Knowledge check

Answer all 10 questions, then submit for explanations and a score. You can retry as often as you like.

Question 1Which description best distinguishes a system from a collection?
Question 2A team reports that outages recur after major promotions. Which observation is a pattern rather than an event?
Question 3Which changes directly reduce a support-ticket stock?
Question 4If ticket arrivals fall, the backlog must immediately fall.
Question 5Which loop is reinforcing?
Question 6What does a “−” arrow mean in a causal-loop diagram?
Question 7Why might different stakeholders choose different boundaries for the same transit service?
Question 8Order the investigation from visible to deeper explanation.
Question 9Which statement about emergence is most accurate?
Question 10Before adopting a proposed leverage point, what is the strongest next question?

Evidence

References

References are formatted to the project’s APA 7 conventions from structured source data.

  1. Adcock, R., Wells, B., & Lawson, B. (2026). What is systems thinking?. Guide to the Systems Engineering Body of Knowledge (SEBoK), version 2.14. SEBoK. Retrieved July 16, 2026, from https://sebokwiki.org/wiki/What_is_Systems_Thinking%3F
  2. Systems Engineering Body of Knowledge authors. (2026). Introduction to systems engineering fundamentals. Guide to the Systems Engineering Body of Knowledge (SEBoK), version 2.14. SEBoK. Retrieved July 16, 2026, from https://sebokwiki.org/wiki/Introduction_to_Systems_Engineering_Fundamentals
  3. Meadows, D. H. (2008). Thinking in systems: A primer. Chelsea Green Publishing. https://www.chelseagreen.com/product/thinking-in-systems/
  4. Meadows, D. H. (1999). Leverage points: Places to intervene in a system. Sustainability Institute. https://www.donellameadows.org/wp-content/userfiles/Leverage_Points.pdf
  5. International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2023). Systems and software engineering — System life cycle processes. (ISO/IEC/IEEE 15288:2023). International Organization for Standardization. https://www.iso.org/standard/81702.html
  6. Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. Association for Computing Machinery. https://doi.org/10.1145/361598.361623
  7. Simon, H. A. (1962). The architecture of complexity. Proceedings of the American Philosophical Society, 106(6), 467–482. https://www.sfipress.org/21-simon-1962

Save your place

Finished this lesson?

Progress stays on this device. No account or tracking service is required.