Part 9 · 1 chapters · ~10 min
Risk Management
Managing what can stop a system or project from succeeding: a register written as cause and consequence, likelihood times impact, avoid, reduce, transfer or accept, ordering work to buy down the biggest risks first with a walking skeleton, the premortem, and a weekly review shared with stakeholders.
11
The register, the premortem and the burn-down
| risk (if ... then ...) | L | I | response | owner |
|---|---|---|---|---|
| If the shared signing service limit is not raised, month-end letters queue for hours | 4 | 4 | reduce: load test week 2; transfer: written capacity commitment from the platform team | eng lead |
| If receiving banks do not accept QR verification, customers still call support | 3 | 4 | reduce: demonstrate to two partner banks during the parallel run | product |
| If the ledger API changes its balance semantics, eligibility is wrong | 2 | 5 | reduce: contract tests in the ledger team's pipeline | eng |
| If legal changes the letter wording late, the template is reworked | 3 | 2 | accept: wording held in a config template, reviewed in week 1 | product |
| If the one engineer who knows the ledger leaves, delivery stalls | 2 | 3 | reduce: pairing and a written integration guide | manager |
the staff habit
Put a risk register on the first page of every design doc you write, and order the plan by risk rather than by what is easy to demo. The walking skeleton through the ledger, the signing service and the PDF, with no polish, is what lets the rest of the project go fast.
RISK MANAGEMENT
a register, likelihood times impact, buying down the biggest risks first, and the premortem
swipe the figure sideways, or tap expand for full screen
1/6
the register
The register: each risk is written as a cause and a consequence ("If the shared signing service rate limit is not raised, month-end letters will queue for hours"), with an owner, a likelihood, an impact, a response and a date to review. Vague risks ("performance") cannot be managed; specific ones can.