Feedback, Instrumentation, and Control

A system you cannot sense and correct in time is being hoped at, not steered.

There is a team I think about whenever the subject of metrics comes up, because they did everything they were supposed to do and made themselves worse at it. They watched their numbers closely. When a month came in soft, they reacted, cutting the channels that looked weak and pouring effort into whatever had worked last. When the next month came in soft in a different place, because the previous month’s cuts had landed and the previous month’s favorites had cooled, they reacted again, the other way. Over a year they lurched between aggressive and conservative, expansion and retrenchment, never settling, always responding hard to the most recent number, and the harder they responded the worse the lurching got. They were neither lazy nor stupid. They were caught in a particular kind of failure that has nothing to do with effort and everything to do with the structure of how they were steering, and it is a failure that a century-old body of engineering knowledge describes exactly.

The knowledge is control theory, the study of how to steer a system toward a desired state by sensing where it is and correcting, and its central lessons are about precisely the situation that team was in, a person trying to control something through feedback that arrives late and responding to it too hard. Control theory would have told them something they did not want to hear, that trying harder was the problem, that a system steered with strong corrections based on delayed information will oscillate no matter how skilled the operator is, and that the cure is structural rather than personal. Go-to-market has almost none of this knowledge, which is strange, because go-to-market is shot through with feedback loops, and a field that runs on feedback and has no theory of feedback is going to produce exactly the kind of self-inflicted instability that team suffered, over and over, and call it bad luck.

What makes the pattern so durable is that every individual move in it is defensible. Cutting a weak channel is reasonable. Doubling down on a strong one is reasonable. The fault lives in none of the single decisions, all of which a sensible person would endorse in isolation, and that is exactly why the teams caught in it cannot think their way out, because thinking harder about each decision leaves the structure that generates the swings completely untouched.

Reporting is not control

The first distinction to draw is between two things the field constantly confuses, watching a system and controlling it, because almost everything go-to-market calls measurement is the first and almost none of it is the second.

Watching a system means observing its state, putting numbers on what happened, building the dashboard that shows where things stand. This is reporting, and it is useful, and it is not control. Controlling a system means closing a loop, taking the observation and using it to act in a way that steers the system toward where you want it, then observing the result of that action and correcting again. The difference is the loop. A dashboard that someone looks at and feels informed by is open, the information goes in and stops, and nothing about the looking steers anything. A control system is closed, the observation drives an action, the action changes the system, the change is observed, and the cycle continues, which is a fundamentally different thing from a report no matter how good the report is.

This distinction sounds academic until you notice how much of go-to-market is open loop without knowing it. A team runs a campaign, measures the result, and files the result, and the measuring only recorded, steering nothing. A team runs an experiment, reads the outcome, and moves on, and the outcome informed a person but did not close a loop that corrects the system. Even the team that reacts to every monthly number, which feels like the opposite of passive, is often not running a real control loop, because a control loop has properties the reacting team never set, a sensible relationship between how strongly it corrects and how quickly it can sense, and without those properties the reacting is thrashing rather than control, which is what happens when you close a loop badly. Reaction alone does not make a system controlled. What turns reaction into control is the right structure, and the structure is exactly what the field has never studied.

It is worth noticing how much of the field’s celebrated rigor is open loop in this exact sense. The experiment culture, the careful test of one version against another, feels like the height of disciplined measurement, and much of the time it is open loop, because the experiment produces a result that informs a human decision and then ends, without being wired into a loop that automatically corrects the system, observes the correction, and corrects again. An experiment that concludes has measured something and then stopped. The beginning of control is an experiment whose outcome adjusts the system, whose adjustment is then measured and re-adjusted on a timescale fast enough to matter. The field holds a great deal of the former and almost none of the latter, which is how it manages to be data-rich and uncontrolled at once, drowning in measurement while its systems wander.

The two quantities that govern a loop

A feedback loop is governed, to a first approximation, by two quantities, and almost everything about how it behaves can be read from them.

The first is the gain, which I will write as $G$, the strength of the correction the controller applies in response to an error. When the system is off target by some amount, the controller pushes back, and the gain says how hard. A low gain responds gently, nudging the system back toward target a little at a time. A high gain responds aggressively, trying to erase the whole error at once. Gain feels like the thing you want to maximize, because a higher gain corrects errors faster, and the instinct of a motivated team is always to respond hard to a deviation, to fix it now. That instinct is the trap.

The second quantity is the lag, which I will write as $\tau$, the delay between taking an action and observing its effect. In a go-to-market system the lag is almost always substantial. You change something today and the consequences unfold over weeks, through the carryover of channels, the length of sales cycles, the time it takes a change in the top of the system to propagate to the bottom. The lag is the time the system keeps you waiting before it tells you whether your last correction worked, and during that wait you are flying on stale information, acting on a picture of the system that is already out of date.

It is worth being concrete about where the lag comes from, because in go-to-market it is unusually long and unusually invisible. A change to a channel takes time to express itself through the channel’s own carryover, the decaying tail of effect that keeps arriving for weeks. A change aimed at revenue has to travel the entire length of a sales cycle before its effect on closed business can be seen, which in enterprise software commonly runs six to nine months from first contact to a signed contract, so a change made to the top of the funnel today cannot be fully judged by closed revenue until well into the following year. A change at the top of the system propagates downward stage by stage, each stage adding its own delay, so that the full consequence of today’s decision may not surface for a quarter. The operator feels they are watching the system closely, and they are, except that what they are watching is the system as it was weeks ago, and they are steering a thing that has already moved on from the state the instruments are showing.

The behavior of the loop comes from how these two interact, and the interaction is where the trouble lives. To see it cleanly, imagine first a system with no lag at all, where the effect of a correction is visible immediately. Suppose the controller closes a fraction $G$ of the observed error each period. Then the distance from target after a correction is

$$(y_{t+1} - y^\star) = (1 - G)\,(y_t - y^\star),$$

where $y^\star$ is the target. The behavior of this is entirely determined by $G$. If the gain is between zero and one, the error shrinks smoothly toward zero, each step closer than the last, a calm approach to target. If the gain is exactly one, the error vanishes in a single step, the fastest possible correction. If the gain is between one and two, something new appears, the system overshoots, the correction is so strong it carries past the target to the other side, then overshoots back, oscillating around the target but with the oscillations shrinking, eventually settling. And if the gain is greater than two, the overshoots grow instead of shrinking, each one larger than the last, and the system flies apart, diverging from the target it was supposed to be approaching. The same loop, with the same controller, is calm or oscillating or explosive depending only on how hard it responds.

A few numbers make the three regimes vivid. Take a target of a hundred and a system starting at zero. With a gentle gain of one half, the system moves to fifty, then seventy-five, then eighty-seven and a half, climbing calmly toward a hundred and never passing it. With a gain of one and a half, it overshoots to a hundred and fifty, falls back to seventy-five, rises to a hundred and twelve, and settles toward a hundred through swings that shrink each time, noisy but converging. With a gain of two and a half, it shoots to two hundred and fifty, crashes to minus a hundred and twenty-five, flies to four hundred and thirty-seven, and the swings grow without limit, the system tearing itself apart while doing exactly what its controller told it to do. Nothing changed across the three runs except how hard the controller pushed on the same error, and the whole difference between a system that converges and one that explodes lived in the gain.

Why delay turns correction into oscillation

That is the picture with no lag. Now add the delay, and the situation gets worse in a way that explains the lurching team exactly.

With a lag, the controller is no longer responding to the current error, it is responding to the error as it was $\tau$ periods ago, because that is the most recent information it has. It corrects for a problem that may already be partly solved, or already changed, because the correction it made $\tau$ periods earlier has not yet shown up in what it can see. So it over-corrects, applying a reasonable gain to stale information, pushing hard against an error that its own earlier pushes have already begun to fix, and then the earlier pushes land on top of the new ones, and the system swings past target, and the controller, seeing the swing late, slams it back the other way. Delay converts a correction that would have been stabilizing into one that arrives at the wrong moment and destabilizes. The mathematics of this is the mathematics of how the stable range of gain shrinks as lag grows, so that a gain which would be perfectly safe with no delay becomes an oscillating gain with a moderate delay and an explosive one with a long delay. Past enough lag, almost any gain large enough to correct quickly will oscillate, which means the harder the team tries to control the system, the more violently it swings.

Here is the intuition in its simplest form. Imagine a delay of just one period, so that the effect of each correction lands one step after you make it. You see an error and correct it, and the correction does not show yet, so on the next step the error still looks uncorrected and you correct it again, and now two corrections are in flight against a single error. When they both land, they add together, and the system has effectively been hit with twice the gain you thought you were applying. A one-period delay can double the effective gain, which is enough on its own to turn a safe, smoothly converging loop into an oscillating one, because a gain that was sitting comfortably below the stability limit gets pushed past it by the doubling. Longer delays stack still more corrections in flight and multiply the effect further, which is why lag is so corrosive to control, and why the safe gain falls as the delay rises.

The everyday version of this is the shower with a slow pipe, the one where the water takes a few seconds to respond to the tap. You turn it toward hot, nothing happens, so you turn it further, and then the first adjustment and the second arrive together and scald you, so you wrench it cold, wait, feel nothing, wrench it further, and freeze. A person of perfectly good judgment, in a shower with enough delay, will oscillate between scalding and freezing forever, and the reason is the lag between action and feedback combined with the human instinct to respond hard to the current sensation, not the quality of their judgment. The fix in the shower is to make small adjustments and wait, to drop the gain and respect the lag, and anyone who has used such a shower has learned this in their body even if they never named it. The lurching go-to-market team was in a shower with a pipe weeks long, responding hard to each sensation, scalding and freezing the whole operation, and no one had told them that the answer was to correct gently and wait for the system to respond.

The shape maps onto their year exactly. A soft month arrived, which was partly real and partly the noise every system throws off, and they responded hard, cutting and reallocating. The effect of that response would not show for weeks, so the following month they were still looking at the consequences of the period before their cut, read it as a fresh problem, and responded hard again. Their corrections and the delayed effects of their earlier corrections kept landing on top of each other at the wrong moments, scalding and freezing the operation in turn, and because every new number felt like new information that demanded action, the instinct to respond hard never let up. Their problem had nothing to do with neglect. They were managing the system with so much gain on so much lag that the managing itself had become the source of the swings.

The cure is structural

The reason all this matters is that it relocates the problem. The lurching team, and the field they belong to, instinctively treat erratic performance as a problem of decisions, of judgment, of effort, something to be fixed by being smarter or more disciplined about each individual call. Control theory says that a system oscillating from gain and lag will oscillate regardless of how good the individual decisions are, because the instability is a property of the loop and not of the decisions, and that the cure is therefore structural, a change to the loop rather than to the people in it.

There are only a few structural cures, and they follow directly from the two quantities. You can lower the gain, responding more gently to each deviation, making smaller corrections and accepting that the system returns to target more slowly in exchange for not oscillating, which is almost always the right trade once you understand it. You can reduce the lag, finding ways to sense the system’s state sooner, shortening the delay between action and feedback so that corrections are based on fresher information, which widens the range of gain you can safely use. Reducing the lag is often the most powerful move, because it attacks the root, and it is more achievable than it looks, since much of the delay in a go-to-market system is procedural rather than physical, the time before anyone looks, the monthly cadence of review, the lag built into how often the data is assembled and discussed. A system reviewed weekly on leading indicators can be steered far more gently and accurately than the same system reviewed monthly on lagging ones, and the reason is simply that the operator is acting on a fresher picture, with the underlying dynamics unchanged. Shortening the time between the system moving and someone seeing it move is frequently the cheapest stability a team can buy. Or you can stop reacting to noise, distinguishing real deviations that deserve correction from the random scatter that every system produces, because much of what the lurching team was correcting was noise rather than signal, and correcting noise injects error into a system rather than removing it. Each of these is a change to the structure of the control loop, and not one of them is a matter of trying harder, which is why the field’s instinctive response to instability, to demand sharper decisions and more vigilance, tends to make the oscillation worse by raising the gain on a loop that was already swinging.

This reframing is the practical payoff of treating go-to-market as a control problem. A great deal of what gets diagnosed as a people problem, an execution problem, a discipline problem, is a loop problem, a system being steered with too much gain on too much lag, and no amount of work on the people will fix a loop that is structurally unstable. The team that lurched needed to correct gently, to sense faster, and to stop chasing noise, and any of the three would have helped far more than the redoubled effort that was making things worse.

The hypothesis

Let me state the claim as a hypothesis sharp enough to be tested and to be wrong.

The hypothesis is that go-to-market systems steered by feedback will oscillate when the gain and the lag are jointly too large, in the manner control theory describes, so that the instability is a computable property of the loop rather than a failure of the operators, and that the common, painful pattern of a team lurching between strategies, over-correcting in one direction and then the other, is this instability and not a deficiency of judgment. A second part of the claim is that because the lag in go-to-market systems is structurally long, through carryover and sales-cycle delay and the time changes take to propagate, the field is unusually prone to this oscillation and unusually likely to misdiagnose it as a human failing, and to respond by raising the gain, which makes it worse.

This is testable. For a team that exhibits the lurching pattern, estimate how strongly it corrects in response to deviations, which is its gain, and the delay between its corrections and the observable effects, which is its lag, and the prediction is that the lurching teams will be the high-gain, high-lag teams, and that the same teams will stabilize if the gain is lowered or the lag shortened, without any change in the quality of the people. If you found teams oscillating violently while correcting gently on short feedback, or found that lowering gain and lag did nothing to the oscillation, the control account would be wrong for go-to-market, and that would be worth knowing. I expect the opposite, because the lurching team is a story every operator recognizes, and the shape of it is the exact shape control theory predicts for a loop run with too much gain on too much delay.

What it changes

A discipline that understood feedback would design its loops on purpose. It would ask, for any system it meant to steer, how quickly it could sense the system’s true state, how strongly it should correct given that delay, and how to tell signal from noise before reacting, and it would treat these as the central design questions they are rather than discovering the answers by oscillating. It would build instrumentation for control rather than for reporting, sensing aimed at closing loops in time to act rather than dashboards aimed at making people feel informed. And it would stop confusing motion with control, recognizing that a team reacting hard to every number is often destabilizing the system rather than steering it, and that the calm of a well-tuned loop, correcting gently on fresh information, looks less heroic and works far better than the thrashing the field mistakes for diligence.

There is an assumption underneath all of this that deserves its own scrutiny, because the entire apparatus of control depends on it. To steer a system by feedback, you have to be able to sense its true state, to know where you actually are relative to the target, and everything I have said assumes that the error the controller responds to is real, that the number coming back from the system faithfully reports what the system is doing. In go-to-market that assumption is shaky in a way it is not for a physical system, because the thing you most want to sense, whether your actions are actually causing the outcomes you see, is truly hard to know, tangled in confounding and delay and the difficulty of telling what would have happened anyway. A control loop fed by a measurement that does not mean what it claims will steer confidently in the wrong direction, and whether go-to-market’s measurements mean what they claim turns out to be a deep question, deep enough that it cannot be waved away as a matter of better tracking, because it reaches all the way down to what can be known about cause and effect at all.

---

References

• On feedback control, loop gain, stability, and the destabilizing effect of delay (phase lag), see Karl J. Åström and Richard M. Murray, Feedback Systems: An Introduction for Scientists and Engineers (Princeton University Press, 2008); and, for the founding ideas of cybernetics, Norbert Wiener, Cybernetics: Or Control and Communication in the Animal and the Machine (MIT Press, 1948).
• On the discrete first-order model of proportional correction and its stability range, see standard treatments of difference equations and discrete-time control.
• The “shower with a slow pipe” is a standard pedagogical example of delay-induced oscillation in a feedback loop.