Start with what can fail
“We need to refactor” describes proposed work. A decision-maker also needs to understand the failure the work addresses, who is exposed and how long the current arrangement can remain acceptable.
A good technical risk note preserves the mechanism. If a billing job can process the same event twice after a retry, explain that sequence. Replacing it with a vague statement about revenue risk removes the detail needed to compare fixes.
Revised September 13, 2026. All financial figures below are illustrative. The expected-loss calculation in the earlier version has been corrected.
Separate evidence from assumptions
Imagine a system whose incident history suggests a material chance of an outage during each quarter. An estimate that combines probability and impact can help compare options, provided it states what each number means.
Suppose the simplified model allows either zero or one incident per quarter, with a 40% probability of one incident. If each incident costs €50,000, the annual expected loss is:
4 quarters × 0.40 × €50,000 = €80,000
This is an average across possible outcomes, not a prediction that the business will lose €80,000 next year. If multiple incidents per quarter are possible, the model needs an expected incident count rather than only the probability of at least one.
Keep observed facts, inferred probabilities and illustrative assumptions separately labelled. An invented probability should never become “industry data” because it makes a slide look more authoritative.
Price the reduction in risk
A proposed change costing €40,000 does not automatically pay for itself against €80,000 of expected loss. It only addresses the part of that exposure it can actually remove, and it may take time to deliver.
If the same simplified model assumes the quarterly incident probability falls from 40% to 10%, the annual expected loss falls to €20,000. The estimated annual reduction is €60,000. A €40,000 investment would then have a simple payback of eight months after the reduction takes effect, before maintenance and other costs.
The uncertain input is the improvement. What evidence supports 10%? Can a smaller intervention remove most of the exposure? What failure modes remain after the rewrite? These questions make the proposal stronger by exposing the part that needs validation.
Put options beside the estimate
A useful note for the duplicate-billing example could compare:
- An operational reconciliation step that detects duplicates after the fact.
- A durable event identity and uniqueness check that prevents a class of duplicate writes.
- A broader replacement of the billing workflow.
The first may be cheap but leave customer-facing errors. The second may address the specific mechanism with less work. The third may be justified by additional constraints, but should not receive credit for benefits that have not been explained.
Google's SRE treatment of risk is helpful because it connects reliability to service objectives and cost. The aim is an explicit acceptable level of risk, rather than an unlimited commitment to eliminate every possible failure.
Write a note someone can disagree with
Use a compact structure:
| Part | What to write |
|---|---|
| Failure | The sequence that produces harm |
| Evidence | Incident records, measured workload or reproduced behaviour |
| Exposure | A range for frequency and impact, with assumptions |
| Options | Effort, residual risk and delivery time for each |
| Recommendation | The next action and the condition for reconsidering it |
A strong recommendation survives a challenge to one input. If the estimated incident cost is halved, does the proposed fix still make sense? If not, the next step may be to improve the estimate rather than approve the whole project.
Make the decision observable afterwards
Record the outcome the change is supposed to produce. For the duplicate-billing case, count duplicate attempts, prevented duplicates and reconciliation exceptions. Those are closer to the mechanism than an undifferentiated reliability score.
The post-change review should compare the result with the original assumptions. That turns the note into reusable engineering knowledge and makes the next estimate better. It also gives leadership a reason to trust technical recommendations that acknowledge uncertainty.