If you put a Software Engineer, a Sales Director, and a CEO in a room, they’re likely to struggle to understand each other.

The Engineer talks technical debt and microservices.
The Sales Director talks pipelines and quarterly targets.
The CEO talks growth and market share.

How do you get different disciplines to align on a decision?

You need a translation layer, a common language that everyone understands.

That language is Risk.

Risk is the best metric to bridge every department. It converts “bad code” into “potential revenue loss.” It converts “rushed features” into “reputational damage.”

Previously I wrote about how to take a risk based approach to prioritisation, treating risk as a planning tool.

Today, I want to talk about how to use it as a tool to make sure you are understood.

Establishing the “Rosetta Stone”: The 5×5 Matrix

The problem with discussing risk is that it is often subjective. To an engineer, a “High Risk” might mean the build pipeline breaks. For a CEO, “High Risk” means there is a strong chance that the company gets sued.

To have a shared language, you need a shared dictionary. The industry standard for this is the 5×5 Risk Matrix.

Using this matrix we map Likelihood (How probable is it?) against Severity or Impact (How bad will it be if/when it happens?).

Drawing the grid is the easy part. The strategic work is agreeing on what the definitions mean before a crisis hits. You need to define the axes:

  • Likelihood: What does a “5” mean? “Once a day” or “Once a year”?
  • Impact: What does a “5” mean? Is it “Server downtime for 10 minutes” or “Total loss of revenue for 24+ hours”?

When defining Likelihood and Impact, it is easy to fall into the trap of creating definitions that only make sense to engineers. It is important that definitions carry commercial weight too. As well as describing loss of services or underperformance, be sure to describe the impact on users and revenue.

You might do this alone and present it back to stakeholders, or you might do it collaboratively with them. Whichever approach you take, once you have agreed definitions you eliminate ambiguity. You stop arguing about feelings (“I feel like this is risky”) and start arguing about facts (“This has a risk score of 12 – Likelihood 4 x Impact 3 = Risk score 12”).

Risk-Based Conversations in Practice

Speaking the language of risk stops you being a “blocker” and starts you on the path to being a strategic advisor.

Example: The OBR & The Budget Leak

In late 2025, the Office for Budget Responsibility (OBR) accidentally released a budget document early. Technically, this happened because of a misconfigured WordPress plugin and—crucially—a predictable URL structure.

If we view this through a Risk Matrix, the failure becomes obvious:

  • The Scenario: Documents were uploaded to a predictable URL pattern (e.g., /2025/autumn-budget.pdf).
  • The Likelihood (3/5): Scrapers and journalists constantly ping these standard URLs. Early access is only possible when there is a human error in the configuration of a plugin. Likelihood is “Possible” (3).
  • The Impact (5/5): A budget leak causes political embarrassment and potential market movement. The impact is “Catastrophic” (5).

The “Risk” Conversation

If the team had spoken the language of risk, the conversation would have looked like this:

Engineer: “I noticed last time we released a budget document that we had traffic on the URL for the file before it was released”

Stakeholder: “Could people access the file?”

Engineer: “No, but only because the release is scheduled. If someone made a mistake when scheduling the release the files could be available early.”

Stakeholder: “So preventing early release relies on us being perfect. Sounds dangerous. The impact of us getting it wrong is a 5. It breaks the embargo. The likelihood any one time is pretty low, but I would say eventually this will bite us, I make that a 3. That gives us a Risk Score of 15 (High). We can’t rely on ‘hope’ as a strategy. We need to lower the Likelihood of discovery even if the config fails.”

Engineer: “We could add a random GUID to the URL. That makes it almost impossible to guess.”

Stakeholder: “How long will that take?”

Engineer: “Ten minutes.”

The Outcome

By identifying the risk profile, the solution became obvious.

  • Action: Add a random GUID to the URL (e.g., /2025/autumn-budget-f497f8...pdf).
  • Cost: Near zero.
  • Result: Even if the plugin fails, the file cannot be guessed. The Likelihood drops from 3 (Possible) to 1 (Rare), reducing the overall risk to Acceptable.

Because this conversation (likely) didn’t happen, the risk remained until it turned into a headline. (For a deep dive, read the OBR’s investigation into the error—it is a masterclass in communicating response to failure clearly).

The Risk of Inaction

There is a trap we often fall into: we obsess over the risk of doing something, but ignore the risk of doing nothing.

Inaction is a choice, and it carries its own risk profile.

Consider a specific sub-system within a legacy product—let’s say, a bulk data export tool written in ancient code. It has zero unit tests, the documentation is missing, and the original developer retired in 2015.

  • The Impulse: The engineering team hates it. They want to refactor it to bring it in line with modern standards.
  • The Risk of Action: Because the domain knowledge is lost and there are no safety nets (tests), the Likelihood of introducing a regression is High (4). The Impact on customers who rely on these daily exports is Major (4). Result: Critical Risk.
  • The Risk of Inaction: The code is ugly, but it is stable. It hasn’t failed in five years. The Likelihood of spontaneous failure is Rare (1). Result: Low Risk.

In this case, the Risk of Action (breaking a critical feature) vastly outweighs the Risk of Inaction (developers having to look at ugly code).

Some engineers might see this decision as “lazy” or as “accepting low quality,” and conclude that refactoring is being dismissed.

A strategic leader understands that refactoring does matter, but also recognises that timing and context are critical. In this case, accepting known maintenance debt is a calculated trade-off to reduce operational risk, not a rejection of quality.

Summary

Risk is the currency of decision-making.

If you want to be understood across the business, stop leading conversations with test coverage and technical debt, and start talking about Likelihood and Impact.

Further reading

If you enjoyed this post then be sure to check out my other posts on Engineering Leadership.

Join the flock

Subscribe to get the latest posts on the messy reality of software delivery sent directly to your mailbox. I regularly share new thoughts on leadership and strategy —zero spam, just value.