Feedback and Delayed Consequences

By the end of this lesson, you will be able to...

• Trace how an action changes the future state of a situation.

• Distinguish a balancing loop from a reinforcing loop in a small model.

• Identify a delay that can make a reasonable intervention arrive too late or overshoot.

Idea in one sentence: A decision can become part of the situation it is trying to change, so the next observation may be different because of the decision itself.

Core Insight

Imagine a support team responsible for a cloud service. On Monday, its unresolved ticket backlog is 40. Twelve new tickets arrive each day, but the team resolves only ten. The dashboard turns yellow.

The manager chooses an obvious action: interrupt an engineer from planned work and ask them to clear tickets until the backlog falls below 25.

On Tuesday, the engineer joins the queue. The backlog still rises. The engineer is answering tickets, but the interruptions also break focused work on an automation fix. That fix would have prevented many future tickets.

By Friday, the team is working harder and the backlog is larger. The manager's action did not happen outside the problem. It changed the problem's future state.

This is the pressure behind the lesson:

A model that shows only “action -> immediate result” misses the loop through which the result changes later conditions.

The Situation Has a State

To see feedback, start with a small state description. A state is the information needed to describe where the situation is now.

For the support team, useful state variables include:

• unresolved backlog;
• new tickets arriving each day;
• tickets resolved each day;
• focused engineering time;
• interruptions and rework;
• automation work that could reduce future arrivals.

The previous lesson taught us to separate targets, signals, proxies, and decision rules. Here we use those pieces to trace movement:

• target: a support service that responds within a reasonable time;
• signal: the dashboard's backlog and waiting-time measurements;
• proxy: backlog size as a quick stand-in for pressure;
• decision rule: move someone to support when backlog exceeds 35.

The decision rule changes staffing. Staffing changes resolution capacity and focused work. Those changes affect tomorrow's backlog and ticket arrivals.

Plain meaning:

Feedback happens when an output of the situation returns and changes a later input, condition, or action.

In this scenario:

The backlog triggers an intervention. The intervention changes how quickly tickets are resolved and how many new tickets appear later.

Technical name:

This is a feedback loop. A loop is reinforcing when its changes amplify one direction. It is balancing when its changes push against the original disturbance.

The labels do not mean “good” and “bad.” A reinforcing loop can grow useful adoption or harmful overload. A balancing loop can stabilize a system or suppress a useful change.

The Naive Model: Every Day Is Independent

The manager's first spreadsheet is simple:

tomorrow's backlog = today's backlog + new tickets - resolved tickets

It is a useful starting point. But the spreadsheet treats new tickets and resolved tickets as independent inputs. It does not ask how today's action changes tomorrow's values.

This creates two blind spots:

1. moving an engineer may increase resolved tickets now but reduce focused automation work;
2. unresolved tickets may create more interruptions, which reduce the team's effective resolution rate.

The simple equation is not wrong. It is incomplete as soon as the terms depend on the backlog and on the intervention.

Two Loops in the Same Team

The support team contains at least two different loops.

A balancing loop: extra capacity reduces backlog

The intended loop is:

backlog rises
-> manager assigns more support capacity
-> tickets resolved per day rises
-> backlog falls

The loop balances the initial increase. It is useful when the added person can contribute quickly and the queue is the main constraint.

A reinforcing loop: backlog creates more backlog

The hidden loop is:

backlog rises
-> urgent interruptions rise
-> focused engineering time falls
-> automation work is delayed
-> preventable tickets continue arriving
-> backlog rises again

This loop amplifies the original pressure. It does not require anyone to make a foolish decision. The team can work harder and still lose future capacity.

The same action can participate in both loops. Moving an engineer may strengthen the balancing loop immediately while strengthening the reinforcing overload loop later. A model that counts only tickets resolved today will see only the first effect.

Worked Trace: Why the Response Arrives Late

Let us trace five days with deliberately small numbers.

Starting state

On Monday morning:

backlog: 40 tickets
new tickets per day: 12
normal resolution capacity: 10 per day
automation project: expected to reduce arrivals in two weeks

The manager's threshold is 35 tickets. The rule activates.

Day 1: the action begins

The engineer moves to support, but needs time to learn the queue. The team resolves 10 tickets. Twelve arrive.

40 + 12 - 10 = 42 tickets

The backlog has risen, even though the intervention started.

Day 2: the signal worsens

The engineer now resolves two extra tickets. However, interruptions delay the automation project. Resolution rises to 12, while arrivals remain 12.

42 + 12 - 12 = 42 tickets

The dashboard looks flat. That is not yet recovery. The team has bought time by spending future improvement.

Day 3: the reinforcing loop appears

More urgent tickets create more context switching. The original team resolves only 9 tickets, and the new engineer handles 3. The total is still 12, but one preventable class of ticket begins appearing more often.

42 + 14 - 12 = 44 tickets

The arrival rate has changed because the delayed automation work has not shipped.

Day 5: the delayed benefit finally arrives

The team finishes a small automation change. New arrivals fall to 9. Resolution remains 12 for the moment.

44 + 9 - 12 = 41 tickets

The backlog begins to fall, but it is still above the starting point. A weekly review that looked only at the first two days might conclude that the staffing move had no effect. A review that looked only at day five might conclude that extra staffing solved the problem. The trace shows both immediate and delayed effects.

So far, the important mechanism is visible:

state
-> signal
-> decision
-> changed capacity or behavior
-> changed future arrivals and resolution
-> new state

The state is not a passive score. It is part of the cause of the next state.

Delay Changes the Shape of a Decision

A delay is the time between an action and the time its relevant effect becomes visible.

In this example:

• an engineer can join a queue in minutes;
• learning the service can take days;
• an automation fix can take two weeks;
• a staffing plan may be changed only once per month.

These are different delays. Treating them as one “response time” hides important behavior.

When a decision-maker sees only the current signal, they may repeat an intervention before the previous one has had time to work. The result can oscillate:

backlog high -> add capacity -> backlog appears lower -> remove capacity
-> delayed work arrives -> backlog high again

Or the manager may keep adding capacity until the delayed automation finally reduces arrivals. Then the system has more staff than the ordinary workload needs. The intervention overshoots because the decision ignored timing.

The practical question is not simply “Does this action help?” It is:

Which effect should appear first, which effect arrives later, and what will we observe while waiting?

What a Loop Diagram Must Say

Drawing arrows is not enough. Each arrow should name a relationship and a time direction.

Weak diagram:

backlog -> staffing -> quality -> backlog

Better explanation:

backlog rises
-> more interruptions (same day)
-> focused automation time falls (same day)
-> preventable ticket arrivals rise (over two weeks)
-> backlog rises

The better version tells us what changes, when it changes, and why the loop exists. It also suggests signals: interruptions per engineer, automation hours completed, preventable-ticket rate, and backlog age.

Use a loop as a hypothesis about behavior, not as proof that the behavior is causal. Compare it with observations and ask which link could be wrong.

What This Changes

Before seeing feedback, the manager may ask:

How many people should we add today?

After seeing the loops, the questions improve:

1. Which loop is currently dominating: backlog reduction or overload?
2. Which intervention affects the state soon enough to matter?
3. What future capacity is being consumed by the immediate response?
4. Which signal would show that the delayed fix is working?
5. When should we review the decision again?

This does not eliminate judgment. It gives judgment a traceable structure.

Trade-offs and Limits

The central trade-off is that tracing feedback reveals second-order effects, but it costs more attention than treating each action as a one-time fix.

Adding capacity can reduce a queue quickly, but it may cost planned work, money, or staff energy. Waiting for a delayed fix can preserve long-term capacity, but it may expose users to poor service today. A balancing intervention can stabilize a system while hiding a reinforcing loop that remains underneath.

Feedback diagrams also have limits:

• an arrow does not prove causality;
• a loop may change when the boundary, policy, or population changes;
• delays may be uncertain rather than fixed;
• several loops can act at once;
• the model may omit a response from users or other teams.

You can see the boundary when the model predicts the same response after the timing, incentives, or actors have changed. At that point, inspect the missing link instead of adding arrows for decoration.

Common Confusions

Confusion: Feedback means a person receives comments

Why it is tempting:

In everyday speech, feedback often means advice or evaluation.

Better model:

In a model, feedback means an output or consequence returns and changes a later state, input, or action. A person giving comments can be part of a loop, but comments are not required.

Confusion: Reinforcing means helpful

Why it is tempting:

“Reinforce” sounds like strengthening something desirable.

Better model:

A reinforcing loop amplifies movement in one direction. It can grow adoption, learning, debt, congestion, or failure.

Confusion: A delayed consequence is just a late measurement

Why it is tempting:

Both appear after the original action.

Better model:

A delayed consequence is a change in the situation that takes time to arrive. A late measurement is an observation that arrives late. They can occur together, but they are different parts of the model.

Confusion: Adding a balancing action removes the original cause

Why it is tempting:

The visible queue shrinks, so the problem seems solved.

Better model:

A balancing loop can reduce a symptom while an underlying reinforcing loop continues. Track the state and the mechanism that generated it.

Check Your Understanding

Check: A team sees a growing backlog and assigns more people. The backlog falls for one day, but planned automation work is delayed and new tickets rise next week. Which loop did the first dashboard miss?

Think first, then reveal.

Answer: It missed a reinforcing overload loop: backlog increased interruptions, interruptions reduced future improvement, and the delayed loss of automation capacity increased later arrivals.

Check: A manager changes staffing every afternoon based on the current queue, while the staffing change takes three days to affect resolution capacity. What risk should the model show?

Think first, then reveal.

Answer: The manager may repeatedly react before earlier actions take effect, causing oscillation or overshoot. The model should show the delay and define when to review the intervention again.

Practice: Trace One Intervention

Choose a situation where a decision changes the situation it is trying to improve: a library queue, a study plan, an incident backlog, household spending, or a team workload.

Write a short loop review:

1. name the initial state and the signal you observe;
2. write one balancing loop;
3. write one reinforcing loop, if one exists;
4. add the delay between the intervention and at least one consequence;
5. choose one signal that would tell you which loop is dominating;
6. state one trade-off of the intervention;
7. say when you would review the model again.

A good answer should use arrows with words, not only labels. It should show what changes first, what changes later, and how the consequence returns to the next decision.

Connection to the Next Lesson

Feedback makes a model dynamic, but a dynamic model still needs to say how confident we are in each link and what evidence is missing. The next lesson adds ranges, confidence, and update triggers:

How much should we trust a model when its inputs and consequences are uncertain?

Resources

• [BOOK] Thinking in Systems — Focus: Feedback loops, delays, balancing and reinforcing behavior, and leverage points.
• [BOOK] The Model Thinker — Focus: Compare a simple causal story with alternative explanations and model limits.
• [ARTICLE] Mental Models I Find Repeatedly Useful — Focus: Notice reinforcing and balancing patterns in everyday decisions without treating a metaphor as proof.

Key Takeaways

• Feedback exists when a consequence returns and changes a later state, input, or action.
• A balancing loop pushes against an initial change; a reinforcing loop amplifies movement in one direction.
• Delays can make a good intervention look ineffective at first or cause repeated actions to overshoot.
• A loop diagram is a causal hypothesis that needs evidence, timing, and boundary checks.
• To model a consequence responsibly, trace what changes now, what changes later, and what returns to the next decision.