# Your Best Work Erases Its Own Evidence Two engineers, one quarter. Priya notices that payment retries can charge a customer twice when the gateway times out. She adds idempotency keys and merges a quiet PR. A month later Marcus spends a Saturday restoring checkout after the connection pool runs dry, and gets thanked by name at the all-hands. At review time, Marcus shows "ownership under pressure." Priya "delivered assigned work reliably." Her fix may have been worth more. It just left nothing behind. This post explains why that happens, and what you can do about it without waiting for your company to change. ## Why prevention work is invisible **Credit follows evidence, not value.** An incident creates evidence as it unfolds: an alert with a timestamp, a graph with a cliff, a channel full of witnesses, a postmortem with names, and a shared experience of pain followed by relief. Prevention works the other way. A successful fix removes the only proof it was needed. The graph stays flat, nobody is paged, and the PR looks routine. ![](https://cdn.hashnode.com/uploads/covers/6a44b5d24b41ab0145e5cf63/25875540-919e-4ec9-b6e7-141897e9701b.png align="center") > The better your prevention works, the less evidence it leaves. ## Hindsight makes it worse Once a risk is neutralized, people judge it in hindsight. It looks either obvious ("of course you'd add idempotency to payments") or exaggerated ("was that ever going to happen?"). Both shrink the contribution to nothing. At scale this is called the **preparedness paradox**: when preparation works, the missing disaster becomes the argument that preparation wasn't needed. The year-2000 bug is the textbook case. A lot of remediation happened, the world mostly kept running, and many people now remember it as hype. ## The research: the capability trap In 2001, MIT researchers Nelson Repenning and John Sterman published "Nobody Ever Gets Credit for Fixing Problems that Never Happened" in *California Management Review*. The title came from an engineer at a company they studied. Their argument: organizations stuck in firefighting mode reward and promote the people who rescue troubled projects, so over time leadership fills with those "war heroes," and slow, quiet improvement work keeps losing to the visible save. They called the resulting spiral the **capability trap**. ## The fix: write it down before you fix it The common advice is a brag document, a running list of accomplishments (Julia Evans popularized it). It's good advice, but it's written after the fact, and for prevention work anything written after the fix reads as hindsight. The change that matters is timing: > A prediction written before the fix is evidence. The same sentence written after it is just a story. A dated ticket saying "payment retries can double-charge when the gateway times out; proposing idempotency keys," written before anyone knew whether it was true, can't be dismissed as hindsight. ![](https://cdn.hashnode.com/uploads/covers/6a44b5d24b41ab0145e5cf63/b6ad8c07-de7c-4f0b-9579-e037081d4d5a.png align="center") ## Five prevention receipts 1. **Write the prediction first.** Failure mode, trigger, who it hits. Dated, shared, and specific enough to be wrong. 2. **Capture the before number.** The load test where it broke, the error rate, the slow query. Your fix deletes that measurement forever, so save it first. 3. **Instrument the save.** Add a metric that counts every time your safeguard fires: duplicates rejected, circuit breaker trips, retries absorbed. Your fix keeps producing evidence for months. 4. **Price it in their currency.** Customers, hours, money, as a conservative range with assumptions shown. 5. **Point to the fire next door.** When the same failure appears in another team's incident or a public postmortem, link it calmly. It's the counterfactual your work never had. ![](https://cdn.hashnode.com/uploads/covers/6a44b5d24b41ab0145e5cf63/d574aafc-2475-4217-8260-cb17c6905abe.png align="center") ### What it looks like in a review "In February I flagged a double-charge risk in payment retries (linked ticket, dated before the fix) and shipped idempotency keys that month. Since then the duplicate check has rejected \[N\] retries, each of which would have been a double charge and a refund." Versus: "Improved reliability of payment flows." Same work, very different weight. ### Two guardrails * **Stay calibrated.** If every ticket predicts catastrophe, people stop listening. Precise predictions and conservative estimates build the track record that gets the next one believed. * **Respect the firefighter.** Incident response is a real skill. The goal is to stop scoring prevention as zero, not to take credit from anyone else. ## Key Takeaways * Promotion and review systems reward what they can see, and prevention is invisible by design. * Hindsight makes averted risks look either obvious or exaggerated (the preparedness paradox). * Repenning and Sterman's 2001 "capability trap" research shows why organizations keep rewarding firefighting over improvement. * A brag document written afterwards is still hindsight. A dated prediction written before the fix is evidence. * Five receipts: predict first, capture the before number, instrument the save, price it conservatively, link the fire next door. ## FAQ ### Why do engineers who fix outages get promoted over engineers who prevent them? Because review processes reward visible evidence. Incidents generate alerts, timelines, witnesses and postmortems automatically. Prevented incidents generate almost nothing, and the absence of a problem is hard to attribute to anyone. ### What is invisible work in software engineering? Work whose value comes from something not happening: preventing outages, removing risk, improving reliability, paying down fragile code. Its success looks identical to "nothing was ever wrong," which is why it tends to be under-credited. ### How do I get credit for preventing problems at work? Create evidence at the right time. Write down the risk, its trigger and its impact in a dated ticket before you fix it, capture the measurement that shows the problem, and add a metric that counts how often your fix prevents the failure afterwards. ### What is the preparedness paradox? It's what happens when successful preparation prevents a disaster, and the fact that nothing bad happened is then used as evidence that the preparation wasn't necessary. Y2K remediation is the most cited example. ### What is the capability trap? A term from Nelson Repenning and John Sterman's 2001 research: organizations under pressure skip improvement work to hit short-term targets, capability declines, more firefighting is needed, and the people rewarded for firefighting rise into leadership, reinforcing the cycle. ### Is a brag document enough to show impact from prevention work? It helps you remember what you did, but it's written after the fact, so for prevention work it can read as hindsight. Pair it with dated predictions written before the fix and metrics that count prevented failures. ## Related reading * [Why your API charges customers twice (idempotency)](https://simplyexplained.hashnode.dev/why-your-api-charges-twice) * [Your Database Is Fine. Your App Is Dying Anyway.](PASTE_URL) * [The Outage Was Over in 40 Seconds. Your System Stayed Down for an Hour.](https://simplyexplained.hashnode.dev/metastable-failure-why-systems-stay-down) * [AI Isn't Coming for the Hard Jobs. It's Coming for the Checkable Ones.](https://simplyexplained.hashnode.dev/will-ai-replace-software-engineers-what-to-do) * [Start Here: the Simply Explained hub](https://simplyexplained.hashnode.dev/start-here-understand-ai) ## The bottom line Your review measures what it can see. Firefighting is born visible; prevention is born invisible. You don't fix that by working harder. You fix it by moving the moment you write it down. > Credit follows evidence, not value. So create the evidence while it still exists. *Adam Jaber is a software engineer who writes Simply Explained: complex topics, made simple — no jargon, no hype.*