The board and the exec team

The mistake technical leaders make with boards is assuming the board wants to understand engineering.

They don't, mostly.

What they're evaluating is whether the person running engineering has an accurate picture of their own organisation, and whether that picture arrives before the problems do or after.

Everything else is secondary. Including the technology. Including the plan.

So the job in front of a board isn't to explain. It's to demonstrate that you see reality clearly and report it honestly.

Monthly, written, no surprises

Board meetings are quarterly at most companies. Far too slow for an engineering picture.

Three months is enough time for a problem to appear, grow, and become somebody else's information before it becomes yours.

So I write a short monthly note. Two thirds of a page.

What shipped and what it changed. The two or three numbers that matter. What's at risk and what I'm doing about it. What I need.

The purpose isn't reporting. It's that the quarterly meeting ends up containing nothing new.

Every problem discussed there has already been named, in writing, weeks earlier, with what was being done attached.

That turns a board meeting from an examination into a conversation. Highest-return habit available in the whole relationship.

The rule underneath it is absolute. Never surprise them.

A board can absorb almost any bad news arriving early with a plan attached. What it can't absorb is discovering you knew and didn't say.

And the second time that happens, the conversation stops being about the problem and starts being about you.

What belongs in the deck

Three or four slides. Mostly not about engineering.

Delivery against what you said last time. Including the misses, stated first, with the reason and what changed as a result.

A section reporting only hits reads as curated, and directors have sat through a great many curated sections.

The two or three metrics connecting engineering to the business. Reliability against your objective, delivery lead time, cost trend if that's live for you this year.

Not story points. Not velocity. Nothing internal.

Team health in one line. Headcount against plan, attrition, and any single point of failure you're carrying.

The technical risk that could affect the company's trajectory, if there is one, described in business terms.

That's it.

What doesn't belong: architecture diagrams, a tour of the roadmap, anything requiring you to teach a concept before you can make a point. If a slide needs a preamble, it's the wrong slide.

Explaining technical risk to non-technical directors

The translation rule. Risk gets expressed as a probability, an impact in business terms, and a decision they can actually make.

Not "our database is approaching its scaling limit." That's information with no handle on it. Something closer to: "at current growth, sometime around Q3, we hit a ceiling on the main database. If we don't act, the likely outcome is degraded performance during peak hours, which affects checkout. Fixing it is roughly two engineers for a quarter, which delays the integrations work. I recommend doing it now, and I want you to know that's the trade."

Three things there. A timeline they can hold onto. A consequence in the currency of the business. A choice, with your recommendation already attached to it.

Never present a technical risk without a recommendation.

A board handed an unresolved technical question will either ignore it or start making engineering decisions, and both of those are worse than the one where you decide and tell them what you decided.

The one genuinely hard case is legacy debt with no forcing event.

It's real, it's slowing you down, and there's no date attached, which makes it very hard to fund.

There, frame it as a rate rather than an event. Everything we build in this area costs roughly twice what it should, here's the evidence from the last three projects, here's what I propose spending to change that.

The pre-read and the pre-brief

Two mechanisms. People skip the second one.

The pre-read is the deck or memo, sent early enough to actually be read, ideally with the meeting spending its first minutes reading rather than presenting.

Same logic as any written-first meeting. It stops the session being consumed by narration.

The pre-brief is a phone call with your CEO, and when something consequential is landing, with individual directors, before the meeting.

Not lobbying. Just making sure nobody meets a substantial piece of news for the first time in a room with an audience.

That separates a board meeting that goes well from one that doesn't, far more than the quality of the deck ever does.

A director who hears difficult news privately, first, has time to think and turns up with questions. The same director hearing it live, in front of peers, has to react in real time. Reactions in that setting are performances.

Delivering bad news

Early, complete, with a plan. In that order. Completeness matters most.

The instinct is to release bad news in stages, partly in hope that some of it resolves itself.

What that produces is a sequence of disclosures, each one reopening the wound, each one teaching the board that your first number is never the real number.

One complete disclosure, even a very bad one, is survivable. Three partial ones is a credibility problem outliving whatever caused it.

Say what you know, what you don't know yet, when you'll know it, and what you're doing meanwhile.

Then meet the date you gave for the follow-up.

And don't editorialise about how it happened until you've done the analysis.

Speculation about causes, delivered to a board, gets repeated. Then quoted back to you when it turns out to be wrong.

The one thing to remember

Your job in that room isn't to be impressive. It's to be the person whose read on their own organisation gets believed.

Which means the most valuable sentences you say in there are the unflattering ones.

This is behind. This was my call and it was wrong. This number is worse than last quarter, here's why.

Those buy you the ability to be believed later, when you tell them something is fine.