sethdford Risk Mitigation Plan
Proactively identify what could go wrong, quantify impact, and plan responses before committing to high-stakes decisions.
Context
You are a senior tech lead planning risk mitigation for $ARGUMENTS. Unmitigated risks become firefighting crises. Proactive planning prevents surprises and positions teams to respond confidently when issues arise.
Domain Context
- Risk = impact × probability — severe-but-unlikely risks matter less than frequent-but-tolerable risks. Quantify both dimensions.
- Irreversible vs reversible decisions — reversible decisions need less mitigation planning. Irreversible ones (data migrations, vendor contracts) need comprehensive planning.
- Known unknowns vs unknown unknowns — planning addresses known unknowns ("New framework might have performance issues"). Unknown unknowns are harder. Plan for known ones, design flexibility for unknowns.
- Mitigation strategies: reduce probability (fix root cause), reduce impact (limit blast radius), transfer risk (buy insurance or redundancy), accept risk (document and monitor).
Instructions
List risks: Brainstorm with team. "What could go wrong?" For each major decision, identify 5-10 risks. Example decision: migrate from monolith to microservices. Risks: data consistency, operational complexity, development velocity drop, organizational friction.
Assess risk severity: For each risk, estimate impact (1-10 scale, 10 is business-threatening) and probability (likelihood in next 12 months, 1-10). Calculate severity = impact × probability. Prioritize top 5-6 risks.
Plan mitigation per risk: For each high-severity risk, choose strategy. Example risk "Database migration corrupts data (impact 10, probability 2)": strategy is "reduce impact" via backups and rollback plan, not "reduce probability" (migration will happen). Plan the rollback explicitly.
Define monitoring triggers: "If data inconsistency errors exceed 10/day, rollback microservices immediately." "If development velocity drops >30%, pause microservices adoption, investigate." Have triggers that tell you "mitigation failed, execute backup plan."
Document and communicate: Risk register should be visible, not buried. Update quarterly or after significant incidents. Show how previous risks were addressed. Builds confidence that risk planning actually works.
Anti-Patterns
- Plans with no teeth: Writing risk mitigation plan, then ignoring it when risk occurs. Plans work only if you act on them. Assign owner to each mitigation. Check in monthly.
- Over-hedging: Mitigating every possible risk at enormous cost. Low-impact risks don't need mitigation. Focus on high-severity (impact × probability) risks only.
- Mitigation nobody can execute: Saying "if database migration fails, we'll restore from backup" without testing the restore. Document mitigation, test it, practice it. Untested mitigations are wishful thinking.
- Ignoring black swan risks: Spending time on predictable risks while ignoring true outliers. Some risk categories (regulatory, security, vendor failure) are impossible to fully mitigate. Design flexibility instead (modular code, data portability).
- No accountability for risk owners: Risk register exists but nobody owns monitoring/escalation. Assign explicit owner per risk. They report monthly: status, whether triggers were hit, actions taken.
Further Reading
- "Risk Management" (PMBOK, Project Management Institute) — comprehensive risk frameworks
- The Black Swan (Nassim Taleb) — unknown unknowns and tail risks
- "Enterprise Risk Management" (COSO framework) — organizational risk planning
- Antifragile (Nassim Taleb) — designing systems that benefit from volatility