Practice vocabulary for communicating technical risks to stakeholders: risk framing, probability vs. impact, risk treatment options, service boundary risk, and escalation language.
0 / 5 completed
1 / 5
An engineer says 'if we don't address this, we risk outage during Black Friday'. What makes this risk communication effective?
Effective risk communication connects technical risk to business consequences the stakeholder cares about. 'We have a race condition in the checkout service' is abstract; 'we risk a checkout outage during Black Friday — our highest revenue day' is concrete and urgent. Time-bounding the risk ('during Black Friday') creates appropriate urgency and helps prioritise the remediation.
2 / 5
'The probability is low but impact is high.' How should this type of risk be handled?
Risk management uses a probability × impact matrix. Low probability / high impact risks (e.g., database corruption, security breach, Black Friday outage) may have a very low expected annual cost when multiplied out, but their catastrophic nature justifies proactive mitigation. Stakeholders must understand that unlikely does not mean ignorable when the impact is irreversible or reputation-damaging.
3 / 5
'We recommend accepting/mitigating/transferring this risk.' What do these three options mean?
The four standard risk treatment options are: Accept (acknowledge and document — appropriate for low risks or when mitigation cost exceeds risk cost), Mitigate (reduce probability or impact through action), Transfer (shift financial or operational consequence to a third party — e.g., insurance, vendor SLA), and Avoid (eliminate the risk by not doing the activity). Presenting options lets stakeholders make an informed decision rather than just hearing a problem.
4 / 5
'The risk is bounded to one service.' Why is communicating risk boundaries important?
Stakeholders often fear worst-case scenarios. Communicating that a risk is bounded — 'this only affects the reporting service, the payment service is on a separate stack and is isolated' — helps stakeholders calibrate their response. Bounded risks have lower potential impact, require narrower remediation, and are less likely to cascade. Clearly communicating boundaries prevents over-reaction and helps prioritise.
5 / 5
What is the key difference between communicating a risk to engineers versus to business stakeholders?
Engineers need technical context to understand and fix the problem. Stakeholders need a different set of information: what is the business impact if this risk materialises, how likely is it, what does it cost to address it, and what happens if we don't? Translating technical risk into business decision language — without burying it in jargon — is a core skill for senior engineers and engineering managers.