When Customers Compensate for You
What your customers are actually telling you when they won’t stop asking for updates
A while ago a client asked me a really good question. During an outage, one of their customers had wanted updates constantly: every twenty minutes, then a call, then an exec-to-exec escalation.
“Why do they need so much hand-holding?”
I told them the customer wasn’t hand-holding. The customer was compensating for a message that should have gone out in the first ten minutes and never did.
What the flood of updates actually is
When an outage starts, the customer’s world goes quiet. The service they rely on has stopped doing its job, the downtime is costing them by the minute, and nobody has told them anything. So they do the only thing available to them: they pull. They email, then ask again, then escalate, until a director is calling a VP. Each request pulls someone off the actual fix to relay a thin sentence, ”still investigating,” which doesn’t reduce the anxiety, it raises it. The scramble to communicate slows the resolution, the slower resolution raises the anxiety, and the anxiety raises the rate of asking, so the whole thing feeds on itself.
By the end you’ve spent a VP’s afternoon, pulled one of your engineers off the bridge to brief them, and taught the customer that the way to get attention from you is to escalate. So after the incident, they want to keep the hotline. And you can’t say no without signalling you care less now that the fire is out. The high-touch mode, born of a failure, becomes the permanent baseline. You will burn that capacity every time you have an incident, for one reason: the loop that should have run on the morning it mattered wasn’t there in the first place.
None of that is the customer being difficult. All of it is compensation: behaviour that exists only because a loop that should have existed didn’t. And what makes it useful is that compensation is visible. It’s the fingerprint, and once you learn to read it, it points straight at the thing you forgot to build.
Stop managing the symptom; read it
The instinct in the moment is to manage the demand and assign more people to updates, pull in the exec, stand up a war room, etc. Every one of those treats the symptom, and worse, it feeds the ratchet that makes the high-touch mode permanent.
What actually works is to look behind the compensation. The customer asking for constant updates is a sign in the clinical sense. Just like a runny nose isn’t the disease but instead tells the doctor you might have the flu, the updates point at a missing feedback loop: a regular, honest, proactive heartbeat that the customer could have relied on, so they never had to pull.
And the heartbeat is almost free. A message at 09:20 that reads ”We’re aware the service is down. We don’t yet know why. A team is on it. Next update by 09:50 whether or not we know more, and every thirty minutes after that” carries almost no information. It admits you don’t know the cause. And it would have changed everything, because what the customer needs at 09:20 isn’t the answer itself, but evidence that someone competent is in control and working a plan. A regular signal is that evidence. It tells them they don’t have to watch, because the signal will come to them.
That’s the difference between predictability and intensity, and it’s the whole game. In a crisis, trust is built by predictability, not by intensity. The outage scramble delivered enormous intensity: a VP, hourly calls, a war room. And the customer still felt you weren’t in control, because frantic high-touch reads as exactly that. The heartbeat delivers predictability at a fraction of the cost.
This is bigger than outage comms
Once you see it, compensation is everywhere, and it’s typically pointing at the same thing: a feedback loop that isn’t doing its job.
The engineer who pings a senior colleague directly instead of using the ticket queue is compensating for a queue that doesn’t route, or that nobody trusts. The team keeping a private spreadsheet next to the “official” dashboard is compensating for a dashboard that doesn’t tell them what they need. In each case the behaviour is the visible trace of a loop that should be carrying the load and isn’t.
This connects to one of the more uncomfortable findings in the research on workarounds. Anita Tucker and Amy Edmondson studied how nurses cope with the small system failures they hit constantly during a shift: a missing supply, a broken process, a tool that isn’t where it should be. They found that people overwhelmingly patch the problem in the moment and carry on, rather than chasing down what caused it. The real cost of that patch is that it stays local: the problem never travels to anyone with the authority to fix the system, and the person who worked around it is often praised for being resourceful, which removes any reason to escalate it. So the failure keeps recurring, the workaround keeps absorbing it, and the loop that would have surfaced the problem never gets built. That is why a workaround you are proud of can be the very thing keeping a loop broken.
So the diagnostic is simple to state and hard to practise: when you see people working around something, don’t celebrate their resourcefulness and don’t manage their behaviour. Instead, ask yourself what loop they’re standing in for.
A warning that comes with it
Compensation has one more property you need to understand: watched the wrong way, it behaves like a countdown rather than a gauge.
While people are compensating, the surface looks fine. The customer is still engaged, the workaround still works, and the numbers you usually watch stay green. So the growing gap stays hidden, right up until the person doing the compensating runs out of road. The VP gets pulled onto something else, the engineer who held it together burns out, a second customer demands the same treatment and there aren’t enough hours. Then the compensation collapses all at once, and because it had been masking the gap, the failure looks like it came from nowhere. David Woods calls this decompensation.
But the surprise is avoidable. The thing to watch is not the output, which stays flat until the very end, but the effort it takes to hold that output flat. Compensation is your people supplying, through sheer effort, the capability the system should have had, and that effort is a finite, expensive reserve. When the same steady result starts costing more people and more hours each month, the reserve is draining, and the gauge the surface was hiding is right there to read. That is the real lesson right there: you cannot out-work a missing loop, only buy time against it.
Not all of it is a problem
Not every workaround is a sign of a broken loop, and this is where the lens can over-fire. People constantly adapt to absorb the normal variability of real work, and that is not a defect, it is the system actually running. Skilled operators improvising during a novel incident are not compensating for something you forgot to build; they are doing the thing no procedure could have done for them. Treat that as a gap to engineer away and you will proceduralise the very adaptability that is keeping you alive.
So the test, before you go building, is whether the thing being worked around is reducible, a mechanism that genuinely should exist (like proactive outage comms), or irreducible, the inherent messiness of the world that humans have to absorb. If it is reducible, build the loop; if it is irreducible, strengthen the people instead of reaching for a control that would only bury your best adaptive capacity under process.
What to do with this
Next time you catch yourself irritated by someone’s behaviour (a customer who won’t stop asking, a team that won’t use the tool you bought them, an engineer who keeps going around the process), pause before you manage it. The behaviour is a sign. It’s showing you, for free, exactly where a loop is missing, mis-aimed, or too weak to cope.
Then make the cheap move instead of the expensive one. Building the loop the behaviour is pointing at almost always costs less than the compensation it replaces, and it lasts, because a customer who can rely on your signal stops needing to chase it. That is the trust the scramble was only ever renting.
//Adrian



Maybe each incident needs two-person mode: both are hands on, both react, but one fixes the immediate issue, the other chases the "root cause" just then and there, so it's not forgotten in some post-mortem