What I would tell the Board

I have given many board updates on technology.

I have been honest in all of them. I have also, in all of them, chosen which honest things to say.

This is not a confession.

It is a description of how the role works. A board update is not a brain dump. It is a curated communication, designed to give decision-makers what they need in the time available. Filtering is appropriate. The problem is that over time, this gets optimized for the wrong goal.

We stop curating for clarity and start curating for comfort. We learn which things cause alarm and edit them out. We learn which framings generate productive questions and which ones derail the meeting, and we adjust accordingly. We get very, very good at giving board updates that go smoothly.

And somewhere in that optimization, we stop surfacing the things the board actually needs to know.

What gets filtered

The list of things technology leaders routinely do not tell their boards is not a list of secrets. It is a list of things that are hard to explain in a format that doesn’t allow for nuance.

The real state of the architecture. Not “our systems are stable” (well they are, you know, mostly, on weekends when no-one is deploying) but the actual picture: which parts are genuinely robust, which parts are held together by the institutional knowledge of two engineers who could leave at any time, which integrations have never been load-tested, which vendor dependencies have no exit strategy. That picture exists in the heads of the engineering team. It almost never makes it to the board.

The uncertainty behind the roadmap. Every technology roadmap is a confidence interval presented as a certainty. We will deliver X in Q3 actually means: we think we will deliver X in Q3. Right? Assuming no other priority initiative needs our time, or no significant incidents, no key staff changes, no scope creep, and none of the technical risks we’ve identified materializing.

The board hears a commitment. We all know it’s a probability distribution. The gap between those two things is where surprises come from.

The technology bets that might not pay off. Every platform decision, every architecture choice, every major vendor relationship is a bet on a future that hasn’t arrived yet. Some of those bets are riskier than they appear. AI investments being the obvious current example: the potential is real, the costs are real, the returns are genuinely uncertain, and most boards are receiving either breathless optimism or cautious skepticism, rarely an honest accounting of what is known and what isn’t.

Why we filter

The incentives are not complicated. Board meetings are short. Nuance takes time. Alarm generates questions that take even more time, and not always useful questions. A CTO who walks into the boardroom and says “I want to walk you through the eight things that could go badly in the next eighteen months” is not going to have a short meeting. They may not have a long career either, if the board reads honesty as incompetence.

So we learn to smooth. We put the risks in the risk register where they sit between the cyber and the regulatory items and nobody asks about them unless something actually happens. We describe architectural concerns in language that doesn’t cause alarm. We’re monitoring the situation, we are in the process of developing a mitigation plan, we expect to address this in the next planning cycle. All true. All carefully calibrated to generate the minimum necessary concern.

The result is a board that approves decisions without the information they would need to challenge them, and then expresses shock when something goes wrong that the technology team knew was coming.

The trust problem at the centre of it

Here is what I think is actually happening. Technology leaders have not been trusted to bring complexity to the board, so they have stopped trying. A board that responds to uncertainty with pressure for certainty, that treats risk disclosure as a management failure, that asks “why didn’t you tell us earlier?” when things go wrong but also asks “why are you bringing us problems?” when they’re raised: that board has trained its technology leadership to manage communication rather than enable governance.

This is a two-way failure. The CTO who smooths everything is not serving the board. The board that punishes honesty is not serving the company. And neither of them is having the conversation that would change it.

• I have been in rooms where a board member, after a technology incident, said: We had no idea this was a risk.
• And I have been in rooms where the CTO said: I told them six months ago. Both of those statements were true. The information existed. It didn’t travel.

What good looks like

I don’t think the answer is more slides or longer risk registers. The answer is a different kind of conversation. One where we can say: Here is what I know, here is what I don’t know, here is where I need your judgment, and the board says: let’s think about this together.

That requires a board that has some technology literacy, not technical depth, but strategic literacy: enough to ask good questions. It requires a CTO who is willing to be uncertain in public, which is professionally uncomfortable. It requires an explicit agreement that surfacing risk is not the same as failing to manage it.

The financial consequences follow the same pattern. A board that cannot challenge a technology decision because it never received the full picture approves budgets, timelines, and vendor commitments on incomplete information. The cost of that gap does not show up immediately. It shows up eighteen months later as an emergency remediation budget, an unplanned migration, or a write-down on a platform that turned out to be the wrong bet. By then nobody connects it to the board update where the uncomfortable question was edited out.

Most of the technology disasters I have seen up close were not surprises to the people closest to the system. They were surprises to the people who had to pay for them. The information existed. The communication model failed.

The version of the board update I would give, if nobody was filtering it, would be shorter than the version I usually give. It would have fewer slides. It would have more uncertainty intervals and fewer certainties. It would have at least one item on it that the board finds uncomfortable.

It would also be more useful.

What to do differently tomorrow: Look at your last board update. Find the thing you knew that didn’t make it in. Not because it was irrelevant, but because it was awkward, or hard to explain in two minutes, or you didn’t think the board would receive it well. That is the item that belongs on the next agenda.