#127 - Risk, Cost, Consequence!

15 Oct 26

Boards don't need to understand how it works. They need to understand what happens if it doesn't, what it will cost to fix, and what it will cost to ignore. Most Engineers spend their time on the first and run out of it before reaching the other three. In the Navy, a shared mission made that translation easier. In industry, it's a skill you have to build.

Trial Brief

Engineers are trained to explain how things work. Boards and non-technical executives are paid to decide what to do about them. Those are different jobs, and they need different information. When an Engineer walks into the boardroom and explains the mechanism, the room hears detail it can't act on. What it needed to hear was the risk, the cost and the consequence.

Raising a briefing to that strategic level is harder than it sounds. It means stepping back from the detail that made you credible, and expressing what matters in terms a non-technical leader can grasp and act on straight away.

Trial Execution

The instinct to explain the how is understandable. It's the territory where an Engineer is most credible, and it feels like the honest thing to do. Surely the board will make a better decision if they understand the technical detail?

In practice, the opposite usually happens. The explanation of how consumes the time and attention available, the board's questions drift towards the detail they've just been given, and the decision they were meant to take gets lost. The executives aren't being obtuse. They're doing what anyone does when handed a lot of information they can't weigh: they look for the part they can judge, and it's rarely the part the Engineer most needed them to focus on.

In the Navy, this was easier than it is elsewhere. Everyone, from the most junior rating to the Captain, was focused on the mission. That shared purpose gave every briefing a natural frame: what does this mean for the mission, and what do we need to do about it? Engineers and commanders were already pointing at the same outcome, so translating between them took less effort.

The commercial world is different. The stakes are not as high, but they still matter, and they show up in the P&L. There is no single mission binding everyone together, so the Engineer has to supply the frame. That means working out what the board is actually accountable for, whether that's margin, delivery, reputation or regulatory exposure, and expressing the engineering issue in those terms. It's a harder skill than it looks, and many Engineers are never taught it.

I've written before about the PEST framework: Problem, Effect, Solution, Timeframe. This is the same discipline applied one level up. At board level, the questions that matter are simpler and harder: what could go wrong, how likely is it, what would it cost us, and what are we choosing between?

Trial Findings

Translating engineering for a board comes down to swapping three things for three others.

Swap mechanism for risk. The board doesn't need to know why a component fails. It needs to know that it might, how likely that is, and what happens when it does. "The seal degrades under thermal cycling" is mechanism. "There is a one-in-ten chance this fails during the programme, and if it does, we lose the capability for six months" is risk. The first invites a technical discussion, the second invites a decision.

Swap effort for cost. Engineers tend to describe cost in terms of work: how many people, how many weeks, how complex. Boards think in terms of money, time and opportunity. Translate the effort into what it costs, what it delays, and what the board gives up by choosing it. Don't stop at the cost of acting. The cost of not acting is often the most persuasive number in the room, and the one least often stated.

Swap solution detail for consequence. An Engineer wants the board to understand why the proposed fix is the right one. The board needs to understand what each option leads to. Lay out two or three realistic choices, what each costs, what each risks, and what each means for the business, customers or safety. Then say which one you recommend and why. A board that can see the consequences of its options can decide. A board that has been walked through the design cannot.

None of this means hiding the technical truth. The detail still needs to exist, and it should be ready if someone asks for it. But it belongs in reserve, not in the opening. As Einstein put it, everything should be made as simple as possible, but not simpler. Risk, cost and consequence is that threshold for a board: simple enough to act on, complete enough to be honest.

There's also a point about trust. Executives who hear plain statements of risk, from an Engineer who isn't hedging or hiding behind jargon, learn that this person tells them what they need to know. That credibility compounds. The next time that Engineer says a risk is serious, the board listens.

The Common Thread

A board doesn't make engineering decisions. It makes decisions about risk, money and consequences, informed by engineering. In the Navy, a shared mission made that translation easier. In industry, the Engineer has to build the bridge to the P&L deliberately. The Engineer's job in that room is to translate, not to teach. Explain the how to the people who have to build it. Explain the risk, cost and consequence to the people who have to decide.

Trial Sign-off

One practical action

Take the next issue you need to put in front of senior non-technical decision-makers and write it in three sentences: what could go wrong and how likely it is, what it costs to fix versus not to fix, and what each option leads to. If you can't, you're not ready to brief it.

One question for reflection

The last time you briefed someone senior and non-technical, how much of your time went on how it works, and how much on what it means for them?

Have a great week!

Steve

If you're interested in through-life Engineering Leadership development from first time Engineering leader/manager, through Head of Engineering up to Director, see the link here.

For short courses which target specific leadership issues, see this link.