Feedback loops: learn from what happens

Do people learn what happened after their decisions—and can they act on it?

Systems thinking examines the relationships between parts of a system. Feedback is one important relationship: the consequences of an action return to influence what happens next.

For practical improvement, useful feedback means information about what happened reaches the people who can use it to improve their next decision or action. It is slow or incomplete when it arrives too late, leaves out important consequences, reaches the wrong people—or produces a report without an opportunity to respond.

One example: a promise without the result

Imagine sales promising a delivery date but never learning whether it was met or what disruption it caused. Operations fixes each problem locally. Sales continues making similar promises—not necessarily through indifference, but because the consequences never reach the decision.

Connect actual delivery results and operational difficulties back to the people making promises. Agree how they will use that information with operations to change future commitments, then check the effect on reliability and workload.

Close the learning loop

  1. Choose the decision that needs feedback. What do people need to learn—not simply report?
  2. Follow the consequences. Include the customer’s experience and effects on other teams, not just whether an action was completed.
  3. Get useful information to the right people in time. Combine measures with specific examples and people’s experience. Make problems safe to report and avoid blame that discourages honest information.
  4. Agree who can respond. What can they change? What needs escalation or joint action? Give them the time and authority to use the feedback.
  5. Check what happened next. Communicate the response and review whether it helped. Sending information is not the same as closing the loop.

Timely does not always mean immediate. Some effects take time to appear. Check early signs and possible harm, but avoid repeated adjustments before the effects of the previous change can be understood. Urgent safety concerns still require action.

Feedback can amplify or counteract change

In a causal feedback loop, a change influences other things that eventually affect the original change:

Work pressure: a reinforcing feedback loop More work pressure can lead to more shortcuts, which can lead to more errors and rework, increasing work pressure again. All three arrows have a plus sign, meaning a change in the same direction, other things being equal. Work pressureShortcutsErrors andrework +++ R R — reinforcing loop
One possible cycle. More work pressure can encourage shortcuts; shortcuts can create errors and rework; rework adds to the pressure. Each + means “a change in the same direction”, other things being equal—not “good”.

Each shortcut may save time now but create more work later. Ask where you could interrupt the cycle—for example, by preventing recurring errors or reducing avoidable demand. Check whether these relationships actually hold in your setting.

A causal loop is not the same as a learning loop. This diagram proposes how a problem might sustain itself. The learning loop above is how you test a change, review what happens and adapt.

Reinforcing and balancing do not mean “good” and “bad”. Delays, capacity limits and other influences can alter what happens. These examples are possible mechanisms to investigate, not established explanations of your system.

Optional: sketch a causal loop diagram

A causal loop diagram is a sketch of proposed relationships—not proof of them.

  • Name quantities that can change: for example, rework, time available for prevention and errors.
  • Connect them with arrows: explain how a change in one might affect another. A + means the effect moves in the same direction; a − means the opposite direction, other things being equal. Neither sign means good or bad.
  • Trace the return path: does it amplify the original change (R, reinforcing) or counteract it (B, balancing)? Mark important delays. A chain without a return path is not a feedback loop.
  • Check the explanation: involve people across the connections, look for evidence for each link and consider alternatives. Use the sketch to make a prediction and guide a test.

A chart may identify a performance change, but cannot establish that the proposed loop caused it or that an intervention broke the loop.

Optional reading

What’s your next useful question?

Who needs to learn what happened—and what could they do differently with that knowledge?

Return to Right problem? →
Look at relationships across the system →
Close the feedback loop when making a change →