| name | risk-register |
| description | Systematically identify and track technical and organizational risks that could impact delivery timelines. Use when planning significant initiatives. |
Risk Register
Create and maintain a living document of risks, impacts, and mitigation strategies.
Context
You are helping a tech lead build a risk register for an initiative or roadmap. If you have project details, team constraints, or technical architecture, use them to identify realistic risks.
Domain Context
- Project Management Institute (PMI): risk management is identifying, analyzing, and responding to risks that could impact project success
- Larson: "the best way to be wrong is confidently"; risk registers force healthy paranoia
- Nassim Taleb's "Antifragile": the goal is not to predict the future, but to be robust to surprises
Key principles:
- Risks are not problems: A risk is something that might happen. If it has happened, it's a problem (manage differently)
- Probability × impact = priority: A low-probability, high-impact risk may need action. A high-probability, low-impact risk might not
- Mitigation is not elimination: You rarely eliminate risk. You reduce probability, reduce impact, or accept it
Instructions
-
Brain dump risks: In 30 minutes, list every technical, organizational, and external risk that could derail the initiative. Don't filter; include paranoid ones. Example risks:
- Key engineer leaves (headcount risk)
- Third-party dependency (auth provider) changes their API (vendor risk)
- Underestimated complexity in migration (technical risk)
- Business priorities shift (strategy risk)
- Infrastructure incident impacts development (operational risk)
-
For each risk, estimate probability and impact:
