I Stopped Producing the Report to See If Anyone Would Scream. By the Time Someone Did, I Had Two Days and No Way Back.

August 28, 2026

I Stopped Producing the Report to See If Anyone Would Scream. By the Time Someone Did, I Had Two Days and No Way Back.

Early in my career I had a test for whether a report mattered. I stopped producing it and waited to see if anyone screamed.

One of them looked like an easy call. Monthly, automated, and going to a distribution list where not a single name still worked at the company. I checked the list twice because the result seemed too clean. I deleted the code that produced it and felt good about the cleanup.

Months passed and nobody screamed. I read the silence the way anyone reads it, as confirmation. Then January arrived and finance surfaced. They had been asking one of those departed recipients for twelve months of that report every year, consolidating it by hand into an annual view nobody had named as a deliverable. They needed the numbers in two days.

I was scared. That is the accurate word, not embarrassed and not annoyed at the process: scared, because I had two days to rebuild something whose generator I had personally deleted, for people whose deadline I had no standing to move. I had audited the recipients. I never audited the consumers, and it did not occur to me that those were two different lists.

The raw data was still sitting there, which is the only reason this story has an ending. I built a summarized year by hand and made the deadline. My cut was reversible, expensively and entirely by accident: I had deleted the mechanism and left the substrate it ran on, and I had not spent one second on that difference. The lesson I carried out was narrower than “measure before you cut”: make sure your deletes can be recovered from.

Every version of the advice since has said the same thing: be data-driven, do not cut what you have not measured, and establish a baseline before you decide, as though the baseline sits in a system waiting to be pulled. For a preventative function it has never existed, and it cannot be conjured on the timeline the decision runs on. Grace Fletcher, PhD, named the reason in a public exchange with me this month: time alone does not make silence readable, because you also need enough qualifying exposure for the absence of failure to mean anything. Six quiet months tell you nothing if only one situation occurred in which the removed function would have mattered.

Almost every technical leader I have worked with has made a cut like this and never said out loud what the evidence actually was. Sometimes a figure goes into the deck: a proxy, an analogy to a different function, an estimate stripped of the uncertainty that produced it. That figure survives every later audit, because there was never a measurement inside it to fail. Far more often no figure appears at all. You make the call, you watch, and nothing breaks, so silence reads as vindication because nobody ever wrote down what silence was supposed to mean.

I ran that second version myself, and for months I was right in the only way the system was equipped to tell me. Most of these calls are correct, which is what makes the real cost easy to miss: a judgment call cannot be graded, handed over, or undone. A successor inherits the outcome and none of the reasoning, so the situation is re-made from scratch by whoever holds the chair next. That is Heroics, and an evidence gap is where it hides: the absence of data becomes the reason nothing gets written down.

The leaders who work this cleanly are not better at finding data that does not exist. They stopped trying, and they moved the effort into what they do with the gap on the day the decision comes due. Call that gap the Proof Window: the interval in which the evidence could have been gathered, which closes at the moment you need it. Evidence and decision compete for the same clock, which is why this sits on top of Clock Drift rather than beside it.

The Proof Window never resolves, which makes it a Structural Bearing, and a bearing you can name is a bearing you can hand to someone else. Its Two-Sentence Brief: you cannot gather the exposure data that would make this cut testable without running the current system unchanged long enough to produce it, and the pressure driving the cut is what removes that time; the available choice is which unprovable version of the cut you are willing to own, monitor, and reverse. Owning it means writing the exposure count you could not establish, as unestablished. Monitoring it means marking the threshold provisional and locking it: any revision after observation begins is a new claim with its own row, never an edit to the old one. Reversing it means buying back the ability to restore it, the only one of the three you have to purchase before you cut.

Reversibility is what you buy when you cannot buy proof, and buying it deliberately beats being rescued by it. Grace has published the instrument version of the evidentiary half, the Transfer Claim Test, which locks what counts as a real test before observation starts. My four-part discipline from last week guards against nobody watching; hers guards against the watcher quietly revising what they were watching for. None of this is permission to cut without evidence. It is the bill that comes due when you do.

Take the last function, role, or report your organization removed. Find the number that justified it and ask whether anyone can still say where that number came from. Then price the reversal: if evidence arrived tomorrow that the cut was wrong, what would restoring it cost, and did anyone check that number before the cut or are you trusting the same luck I did? A cut you cannot reverse was never a test, and you are the only person who knows what it rested on.

The Edge Case walks through how to map a bearing like the Proof Window into a Two-Sentence Brief you can hand to a successor, instead of a judgment call only you can make: http://TheEdgeCaseBook.com


I write about structural leadership for technical leaders in high-stakes operating environments. If this way of thinking resonates, it runs deeper in The Edge Case: http://TheEdgeCaseBook.com

Anthony S. Jackson

Anthony S. Jackson

Anthony S. Jackson has spent 30 years inside technical organizations. He is the author of the Architecture Protocol Series: three books on the structural problems technical leaders were never told they would face. He writes the LeadershipOS™ Inner Circle, a monthly printed newsletter for CTOs and engineering managers who design teams that hold under pressure.

LinkedIn logo icon
Back to Blog