Feedback Loops: The Pattern Behind Most "Mystery" Problems

Two kinds of loop explain most of the problems that feel genuinely mysterious the first time you run into them, the ones where the obvious cause does not seem to match the size of the effect. A reinforcing loop feeds on its own success, and it is the easier of the two to spot once you know to look for it. A product with more users gets more attention and more word of mouth, which draws in more users, which draws more attention again. Nobody outside the loop is pushing it forward at each step. It is pushing itself, and each trip around the loop tends to move a little faster than the one before, because the loop is now acting on a slightly bigger base than it started with.

A balancing loop does close to the opposite. It quietly resists change and pulls a system back toward wherever it was already sitting. A team adds headcount specifically to speed up delivery, and coordination overhead, the extra meetings, the extra handoffs, the extra onboarding time, grows just enough to absorb most of the intended gain. Push the system, and the system pushes back in roughly the same proportion, which is exactly why the result so often feels disappointing relative to the size of the investment that went in.

Why pushing harder fails on both

Most teams, faced with a problem that is not resolving the way they expected, reach for the same instinct: push harder. More effort, more hours, more headcount, more urgency. That instinct is wrong for both kinds of loop, just in two different directions. Push a reinforcing loop in the wrong direction and it snowballs out of control, faster than anyone expected, because the loop was never resisting the push, it was accelerating with it. Push a balancing loop harder and it simply produces more resistance to match, with little extra to show for the additional effort, because the loop's entire function is restoring the system to roughly where it was.

Recognizing which loop you are actually dealing with, before deciding how hard to push, is close to the whole skill. A reinforcing loop running in a direction you do not want, complaints spreading faster as more customers see other customers complaining publicly, usually needs an intervention that breaks the loop's own mechanism rather than one that simply opposes its current direction. A balancing loop resisting a change you do want, that headcount example, usually needs the resistance itself addressed directly, reducing the coordination overhead the loop is generating, rather than more raw force thrown at the original goal.

A reinforcing loop worth watching for

That exchange only happens because the BA asked specifically whether the effect was feeding itself, rather than simply assuming a bigger cause had produced a bigger effect in the usual proportional way. A reinforcing loop breaks that proportionality, and missing it means the fix aimed at the original cause looks like it failed, when really it was only ever half the actual problem.

A balancing loop worth naming out loud

The headcount example is worth staying with a moment longer, because balancing loops are genuinely harder to spot than reinforcing ones. A reinforcing loop announces itself with a number that is clearly accelerating. A balancing loop looks, from the outside, like nothing is happening at all, a flat line where a clear improvement was expected, and flat lines rarely trigger the same urgency that a visibly worsening number does. The team that added headcount and saw delivery speed barely move is not looking at a failed hire or a bad plan. They are looking at a system that is doing exactly what balancing loops do, absorbing the push and settling back near where it started. Naming that out loud, in the room, changes the conversation from "did we hire the wrong people" to "what in this system is generating the resistance, and can we address that directly instead of adding more force against it."

Both loops reward the same underlying habit: pause on the effect long enough to ask whether it is feeding itself, resisting you, or simply responding in the straightforward way you expected. That one question, asked before committing more budget, more headcount, or more urgency to a problem that is not behaving the way effort alone predicts, is most of what separates systems thinking from ordinary determination.

It is worth adding that most real systems carry several loops running at once, not just one, and they rarely announce which kind they are. A marketing campaign can be feeding a reinforcing loop of growing demand at the very same moment a balancing loop in fulfillment capacity is quietly capping how much of that demand can actually be served well. Treating the whole situation as a single loop, and pushing it in one direction, misses that the two are pulling against each other, and the honest fix often has to address both at once rather than picking the more visible one and hoping it accounts for everything.

A practical way to sort this out in an ordinary meeting, without any formal modeling, is to ask the room one direct question about whatever metric is under discussion: if we do absolutely nothing else, does this number tend to keep moving on its own in the same direction, or does it tend to settle back toward where it has historically sat. A number that keeps moving on its own, once something nudges it, is pointing at a reinforcing loop somewhere nearby. A number that stubbornly returns to roughly the same place no matter what gets thrown at it is pointing at a balancing loop quietly doing its job. Neither answer requires a diagram to reach, only a moment spent actually looking at the metric's own history before deciding how hard to push it.

Tomorrow pushes one step further into the same territory: not just what a change does immediately, but what it does after that, and after that again.

Go out and be successful.

Oluwatosin Ogunkoya · Flotog BA Insights · 1:1 mentoring and coaching for BAs at every career stage · www.flotogbainsights.com

TOMORROW

Second-Order Effects: What Happens After What Happens - Training yourself to ask what a change does to the rest of the system, not just whether it solves the problem in front of you.