Selling Absence
The best quarter a reliability engineer can produce looks, from the outside, identical to the quarter they did nothing. No incidents, no pages, no postmortems. Absence is the output, and absence leaves no trail.
People who run into this problem usually frame it as communication. "We need to tell a better story." But the comms framing misses the shape of the problem. There is no story to tell that doesn't rest on a counterfactual, and counterfactuals have a credibility ceiling. "We prevented twelve outages" means twelve things that didn't happen, which is indistinguishable from twelve things that were never going to happen. The listener has no way to evaluate the claim. They have to take your word for it, and "trust me" is a thin foundation for budget defense.
This is structural. The work's success condition and its uselessness condition produce the same evidence.
Compare to feature work. A feature ships, users interact with it, metrics move. The work leaves a residue. Security work has this property when it succeeds loudly: catching a breach attempt, surfacing a vulnerability before exploitation. Reliability's ideal state is a flat line. A flat line reads the same whether you earned it or inherited it.
The feedback trap runs deeper. When a reliability initiative is underway, it briefly taxes the system. Engineers are changing infrastructure, testing failure modes, rerouting load. During that window, things can go visibly wrong, and that visible wrongness becomes evidence that the initiative is the problem. When the initiative succeeds, nothing happens, which looks identical to the initiative being unnecessary. Either way the case for continued investment is weak. Organizations learn to defer, drift until a major incident, then invest reactively in ways that produce visible heroics. Heroics leave evidence. Prevention doesn't.
"Tell a better story" tries to manufacture visibility after the fact: reliability scorecards, error budgets, incident reports on near-misses. These practices have real value. But they're all attempts to construct evidence for a counterfactual. The dashboard exists; the relevance of the numbers depends on a model of what would have happened without the work. The listener either believes that model or doesn't, and their belief runs mostly on trust, not on anything you produced.
Chaos engineering is the most honest attempt to address the structural problem directly. It manufactures incidents deliberately, which gives the work a visible artifact: a game day was run, a failure mode was found, it was fixed. The work has output now. But that only covers discovery. The larger fraction of reliability work, the monitoring, the capacity planning, the operational hygiene, still produces nothing visible when it succeeds. And chaos engineering requires organizational trust to run in the first place, which means you had to solve the credibility problem before you got permission to manufacture the incident.
The structural problem doesn't resolve. The better you are at it, the less anyone can observe you doing anything at all. An organization that never has major incidents either has excellent reliability work or has a system that was never seriously threatened. From inside, you know which it is. From outside, the evidence is the same.
Error budgets and SLO reporting and postmortems are worth doing. But none of them escape the fundamental asymmetry: incident evidence is hard and verifiable, prevention evidence is soft and model-dependent. No communication strategy bridges that gap, because the gap isn't in the communication.
The floor is accepting that and doing the work anyway.