Nestor G Pestelos Jr · Writing
The Metric You're Watching Already Happened Upstream
The number you're staring at almost always already happened elsewhere or earlier. It rarely has one clean cause. Fix a real contributor instead of reacting to the metric, and expect that fix to expire too.
Twenty minutes into a Black Friday outage, the dashboards read "high" latency. That drastically understated what was happening. Requests were timing out, so their true latency was effectively infinite. A metric that only counts completed requests can't see one that never finishes. Michael Nygard, writing up the incident in Release It!, put the trap plainly: "Response time is always a lagging indicator. You can only measure the response time on requests that are done." The average looked stressed but nominal. The system was failing, and the metric everyone was watching was structurally incapable of showing it, because the requests doing the most damage were the ones that never finished long enough to be counted.
I went through my notes gathering every case I had of this shape, then ran a session actively trying to find what would break it. The pattern holds far outside operations:
- Justin Skycak flips a career cliché: passion follows competence. Chase passion first and you mistake the readout for the cause, because passion shows up after sustained effort.
- Aakash Gupta runs six founder cases through the same test; the cleanest pair is about money. Fired with his reputation intact, Sam Altman had an offer within 48 hours. Reputation gone, Sam Bankman-Fried couldn't raise a dollar after FTX collapsed. Investors are pricing what a founder will do next, and once the belief in "next" collapses, the current balance stops mattering.
- An operator writing as staysaasy makes the management version: how often a team fights fires is a lagging readout of planning quality, not bad luck.
- Victor Andres Manhit's data on Philippine legislation shows the same lag in public opinion, and it runs both directions. An early bad approval number isn't proof an initiative failed, and a later good one isn't proof it worked, since perception can lag the real condition either way.
- Tibo, who runs a SaaS portfolio at $1M MRR, traces most churn to signup and the first onboarding session, months before the "price" reason customers give when they cancel.
Norbert Wiener formalized the general idea in 1948: feedback is how a system adjusts future conduct by past performance. When that feedback arrives too late, the correction arrives too late with it, which is exactly Nygard's dashboard. Shortening the loop is the fix: watch something further upstream that's happening right now, before the delay has a chance to hide the failure again.
Two problems survived when I tried to break this.
First, there is rarely one clean cause to find. Richard Cook's How Complex Systems Fail makes the point bluntly: "Post-accident attribution to a 'root cause' is fundamentally wrong... there is no isolated 'cause' of an accident." Real failures need multiple contributors acting together, not one traceable cause. "Reputation caused the funding" or "onboarding caused the churn" names one real contributor among several. Name a contributor. Don't call it the cause.
Second, whatever you start watching upstream instead has the same problem waiting for it. Goodhart's Law, from 1975: any regularity you turn into a target stops behaving like a regularity. Watch account health scores the way you used to watch the cancellation number, and eventually someone learns to fake the score instead of fixing the account. The upstream signal is not a permanent fix. It's a fix with an expiration date, and the expiration date is the moment someone starts managing to it on purpose.
What changes, in practice:
- Name what the number in front of you finished measuring, and how long ago.
- Ask what's happening right now, further upstream, that you could watch instead: a health score before the cancel button, or a confidence level tracked against outcomes before the forecast fails.
- Plan to rotate that upstream signal before it turns into the next thing people learn to game.
The number told you about the past. The upstream signal only buys you a warning, and only for as long as nobody's optimizing for it yet.
Nygard's own prescription for the trap: supplement the average with percentiles and completion counts, the numbers that show a stuck request instead of hiding it. Build a way to see the failure the lagging number was built to miss.