Explaining technology to a board that isn't technical

A board does not need to know how a system works. It needs to know what a decision costs, what it risks, and what it makes possible. The gap between those two things — the technology and the decision — is where most technology reporting fails.

Lead with the decision, not the detail

Start with what you are asking the board to agree to and why. The architecture, the vendor comparison, the migration plan — that is the appendix. A board member should be able to read the first paragraph and know what is being decided and what is at stake.

Put a number on the risk

“There is a security risk” is not actionable. “An account compromise here would expose client data and likely trigger a regulatory notification; closing the gap costs about a day of work” is. Risk that is quantified can be weighed. Risk that is vague just creates anxiety.

Trends, not snapshots

A single figure tells a board where you are. A trend tells them whether things are getting better or worse, which is what they actually want to know. Show the direction of travel.

Make the recommendation explicit

If you have a view — and you should — state it. Boards value advisers who will say “I recommend we do X, here is the trade-off” over those who present options and leave the judgement on the table.

Good technology leadership is partly a translation job. The work is real, but the value is only realised when the people holding the budget understand what they are deciding. That translation is exactly what a fractional CTO is there to do.