Executive & board communication

1 · The altitude problem

Engineers lose executives by talking at the wrong altitude — tokens, latency, and model names when the exec is asking about money, risk, and time. The core skill is translation: every technical fact has an executive-level meaning, and your job is to lead with the meaning and keep the mechanism in your back pocket for when they ask. Lead with the so-what.

Picture the meeting you've probably sat in. You've spent six weeks shaving p95 latency, adding an eval gate, and wiring up prompt caching. You get eight minutes in front of the leadership team, and you use them to walk through the architecture — token budgets, the retrieval pipeline, why you chose one model over another. Faces go polite and blank. Someone checks their phone. At the end the CFO asks, "So… is this thing making us money or costing us money?" and you realize the entire eight minutes missed the only question in the room. The work was excellent; the communication failed. That is the altitude problem, and it kills more good technical decisions than bad code ever will.

Here's the analogy that fixes it. Think of a pilot talking to air-traffic control versus talking to a mechanic. To the mechanic, the pilot describes the specific valve and pressure reading. To the tower, the pilot says "requesting descent to 10,000 feet" — same aircraft, completely different altitude of description, chosen for who's listening and what they'll decide with it. Executives fly at the money-risk-time altitude. Every fact you have lives down at the engineering altitude, and it is your job to climb it up to theirs — not theirs to climb down to you. They literally do not have the context to, and expecting them to is the mistake.

So what does "translation" mean concretely? It means for every technical fact, you ask one question before you open your mouth: "so what does this mean for money, risk, time, or the customer's experience?" The answer to that is your headline; the technical fact is the footnote you keep ready for when someone asks "how?" Notice this is not dumbing down — a good exec is sharp, just optimizing for different variables. You're not hiding the mechanism; you're leading with its consequence and offering the mechanism on request. The common mistake isn't using jargon (you can define a term); it's ordering the sentence wrong — putting the mechanism first and the meaning last, so the listener has to survive the whole explanation before learning why they should care. Flip the order. The table below is a translation dictionary: engineer-speak on the left, the blank stare it produces in the middle, and the sentence that actually lands on the right.

2 · The ROI business case

A credible AI business case has four parts: the problem (in business terms), the expected value (revenue, cost saved, or risk reduced — quantified), the cost (build + run TCO from EL3), and the risk/assumptions stated honestly. The number that wins is net value with a stated confidence, not a best-case fantasy.

Here's the pitch that almost always dies, and why. An engineer, genuinely excited, tells the funding meeting: "This AI feature could save us millions — customers will love it, it'll cut support time in half, and the model just keeps getting better." Every word might be defensible, and the request gets declined anyway. Not because the idea was bad, but because a business case made entirely of upside reads, to anyone who controls a budget, as naive — or worse, as someone hiding the downside. The most reliable way to not get funded is to present a case that can only go right.

Think about how a bank decides whether to give you a loan. They don't just ask "how much could you earn?" They ask what you already earn, what you owe, what happens if you lose your job, and how confident they are in your answer. They're pricing risk-adjusted return, not best-case return. A CFO evaluates an AI investment exactly the same way, and the four-part structure below is simply the shape of an argument that answers all four of their instinctive questions: what problem is this worth solving, what do we get, what does it truly cost, and what could go wrong. Skip any one part and a sharp exec fills the gap with their own (usually pessimistic) assumption.

Two pieces of this need spelling out because beginners get them wrong. First, expected value must be quantified in the exec's currency — dollars, hours saved, or risk reduced — not in "users will love it." "Love it" is not a line item. If you can't put a number on it, say so honestly and label it a qualitative benefit, rather than dressing a feeling up as a fact. Second, cost means total cost of ownership (the build and the ongoing run cost — inference, monitoring, upkeep — from EL3), not just the sprint to ship it. The single most common ROI mistake is quoting the build cost and quietly ignoring that inference bills arrive every month forever. The number that actually earns funding is net value stated with a confidence range: not "this saves $500k" but "conservative $180k, expected $360k, optimistic $540k, and here's the assumption that decides which one we land on." A range signals you understand the uncertainty; a single confident number signals you haven't thought hard enough. The pipeline below shows the four parts flowing into that final honest net.

3 · The risk register and board framing

A risk register is the living list of what could go wrong, each entry with a likelihood, an impact, an owner, and a mitigation. It's an engineering artifact and the source for board risk framing — boards think in likelihood × impact and "who owns it," not in exploit mechanics.

The failure this prevents is the worst kind: the surprise. Imagine the board learns your AI system leaked customer data — not from you, but from a news headline or a regulator's letter. In that moment two things happen at once: the incident itself, and the discovery that you knew this was possible and never told them. The second is often career-ending in a way the first isn't, because it destroys the one thing a leader trades on — trust. A risk register exists so that no risk is ever a surprise. Every scary possibility has already been written down, sized, assigned an owner, and paired with a plan, before it happens.

Think of it as the same document a doctor keeps: a chart listing each condition, how serious it is, how likely it is to flare up, who's managing it, and the treatment. A patient with a well-managed chronic condition isn't "unsafe" — they're known and cared for. That reframe is the whole point. The register doesn't make you look risky; it makes you look like the adult in the room who has already thought about what could go wrong. An AI system with an empty risk register isn't safe — it's unexamined, which is far more dangerous.

The register has two audiences, and confusing them is the classic mistake. To engineers, it's a working artifact: precise, technical, full of the exploit detail you need to actually build the mitigation. To the board, it's a source you translate up — the same altitude problem from section 1. A board does not want to hear "indirect prompt injection via retrieved context"; it wants three things per material risk: what it is in plain language, how bad × how likely, and who owns it and what they're doing. The four columns — likelihood, impact, owner, mitigation — exist precisely because those are the columns a board reasons in. Note that likelihood and impact are separate axes on purpose: a low-likelihood, critical-impact risk (a cross-tenant data leak) is managed completely differently from a medium-likelihood, medium-impact one (runaway cost), and collapsing them into a single "high/low" label throws away the information that decides where you spend your attention. The sample register below shows the shape; the callout after it shows how each row compresses into the board's three sentences.

4 · Roadmap communication

AI roadmaps face a special hazard: model releases and priorities shift faster than a Gantt chart. Communicate in outcomes and horizons, not dated feature promises. A now / next / later framing survives change; "feature X ships March 14" does not, and breaking it costs you credibility you'll need later.

You've seen this movie, probably starring you. Last quarter you put "Autonomous agent — ships Q3" on a slide because a new model was rumored to make it possible. The model slipped. The capability wasn't there. Q3 came and you shipped nothing autonomous. It doesn't matter that the delay was entirely outside your control — what the org remembers is that you promised a thing and missed it. Do that twice and your roadmap stops being read as a plan and starts being read as a wish list. In AI this happens more than anywhere else, because so much of what you'd like to build depends on capabilities that don't exist yet on the day you present.

The fix borrows from how good weather forecasts are communicated. A forecaster says "it's raining now" (certain), "rain likely tomorrow" (probable), and "unsettled next week" (a direction, not a promise) — and nobody feels lied to when next week turns out sunny, because the confidence was baked into the framing. A now / next / later roadmap does the same thing: it attaches a confidence level to each horizon so that a shift in the far horizon is expected, not a broken promise. You commit hard to Now because you're already building it. You point a direction with Next and reserve the right to learn. You name only themes in Later, deliberately vague, because pretending to know exactly what you'll build in a year is the fiction everyone can see through.

The single most important move is how you handle a capability-dependent item — the feature that needs a model that isn't out yet. The mistake is to promise it with a date, betting your credibility on someone else's release schedule. The craft is to state it as a bet with a trigger: "if models reach reliability bar X, then we'll build Y." Now if the model ships, you look prescient; if it doesn't, you look disciplined — and either way you kept your word, because you never promised the model, you promised your response to it. That's why the whole framing protects the currency you can't refill on demand: credibility. You spend credibility on the hard asks later (the big budget, the risky pivot), so you protect it now by only putting dates on things you actually control. The horizon table below lays out what you commit to, and at what confidence, in each band.

5 · Metrics execs care about & saying no

Execs care about a handful of numbers: value delivered (adoption × per-task value, from EL4), cost (and trend, from EL3), risk posture (open high risks and their owners), and reliability (does it work when customers need it). Report those; leave tokens-per-second for the engineering review. And the hardest leadership skill: saying no to a bad AI idea — an executive's pet project, an AI-for-AI's-sake feature, a use case with unacceptable risk — without becoming an obstacle.

There's a quiet law of organizations: you get more of what you measure. Put tokens-per-second on the executive dashboard and, without anyone deciding to, the org starts optimizing tokens-per-second — engineers tune the metric on the slide because that's what leadership looks at, even though a customer has never once cared how many tokens per second your model emits. Report the wrong numbers and you don't just waste a slide; you steer the whole team toward the wrong goal. The choice of what to report is a management decision, disguised as a formatting one.

So which numbers? Boil it down to the four questions every executive actually has, whether or not they phrase them this way: Is it making us money? (value delivered — and remember value is adoption × per-task benefit, so a brilliant feature nobody uses is worth roughly nothing). Is it costing us too much? (run cost and its trend). Are the scary things handled? (open high risks and who owns them). Does it actually work? (reliability). Everything else — latency percentiles, eval sub-scores, model version churn — is real and important, and it belongs in the engineering review, not the exec page. And always show a trend, not a snapshot: "$40k/month" tells an exec nothing; "$40k/month, down from $70k last quarter" tells a story they can act on.

The last skill on this page is the hardest, and it's the flip side of everything above: saying no. Sooner or later a senior leader will fall in love with an AI idea that's high-risk, low-value, or just AI-for-AI's-sake, and your job is to stop it without becoming the "department of no" that everyone learns to route around. The instinct to fear is reflexive refusal — "no, too risky" — which reads as obstruction and costs you the seat at the table you need to do the job at all. The move that works is agree with the goal, disagree with the method: affirm the outcome the leader wants (you almost always share it), then bring evidence — the ROI case, the risk-register entry, the TCO — for why this specific approach won't get there, and crucially, offer an alternative that does. Then let them decide: you inform, they own the call. That last part is what separates leadership from gatekeeping. A "no" that comes with a reason and a better path is you doing your job; a "no" with nothing behind it is just friction — the organizational version of the over-refusing safety filter that blocks so much it becomes useless. The callout spells out the exact framing.