Executive & board communication
The best technical decision dies if you can't communicate it upward. This lesson is how AI-engineering leaders talk to executives and boards: building an ROI business case, maintaining a risk register, framing risk for a board, communicating a roadmap, reporting the metrics execs actually care about, and — the hardest skill — saying no to a bad AI idea without becoming the department of no. Scenarios are representative; the communication craft is real.
Learning objectives
- Build an ROI business case for an AI feature that a CFO will accept.
- Maintain a risk register and translate technical risk into board language.
- Frame AI risk for a board: likelihood × impact, owner, and mitigation — not jargon.
- Communicate a roadmap that survives contact with shifting priorities and model releases.
- Report the few metrics execs care about, and say no to a bad AI idea constructively.
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.
| Engineer says | Exec hears (nothing) | Translate to |
|---|---|---|
| "We cut p95 latency 40%" | ? | "The feature now feels instant, so more users finish the task" |
| "We added an eval gate in CI" | ? | "We can't ship a quality regression to customers anymore" |
| "Prompt caching saves tokens" | ? | "This cuts the feature's running cost ~X%/year" |
| "The model sometimes hallucinates" | ? | "There's a bounded accuracy risk; here's how we contain and monitor it" |
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.
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.
| Risk | Likelihood | Impact | Owner | Mitigation |
|---|---|---|---|---|
| Model hallucinates in a customer answer | Medium | High | Eng Lead | Grounding + citations + eval gate + HITL on high-stakes |
| Prompt injection exfiltrates data | Low | High | Security | Least privilege + rails + action gate + monitoring |
| Cross-tenant data leak | Low | Critical | Eng Lead | Tenant-filtered retrieval + canary test in CI |
| Vendor deprecates the model | Medium | Medium | Platform | Provider abstraction + tested fallback |
| Runaway cost | Medium | Medium | FinOps | Budgets, quotas, anomaly alerts |
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.
| Horizon | What you commit to | Confidence |
|---|---|---|
| Now | Specific outcomes in flight | High — you're building it |
| Next | Direction + the bets we're making | Medium — subject to learning |
| Later | Themes and options, not promises | Low — deliberately vague |
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.
✓ Checkpoint — you can move on when you can…
- Translate three technical facts into executive-level meaning and lead with the so-what.
- Build an ROI case with a value range, TCO, and stated assumptions rather than one rosy number.
- Turn a technical risk into a three-sentence board framing (what / likelihood×impact / owner+mitigation).
- Communicate a roadmap in now/next/later instead of dated feature promises.
- Say no to a bad AI idea while preserving the relationship and offering an alternative.
An executive asks in a review: "Is our AI safe?" You know the honest answer is "it depends on what you mean, and there's residual risk." How do you answer in a way that's both truthful and useful to a board?
Show answer
A senior VP is excited about adding a flashy generative-AI feature you believe is high-risk and low-value. How do you say no without torching your relationship or your influence?
Show answer
🪜 Practice ladder beginner → industry
Six graded exercises, easy to real-world. Try each before opening its solution.
Context: The foundational skill is speaking at the right altitude — meaning first, mechanism later.
Your task: Rewrite five engineer-level statements into executive-level meaning that leads with the so-what.
Requirements:
- Facts: latency cut, eval gate added, caching saved tokens, occasional hallucination, provider abstraction built
- Each rewrite leads with business impact (money, risk, time, or experience)
- Keep the mechanism as an optional follow-up, not the headline
💡 Hint: Ask of each fact: 'so what does this mean for money, risk, time, or the customer?'
Show solution
- Latency −40%: "The feature now responds instantly, so more users finish the task and fewer drop off."
- Eval gate in CI: "We can no longer accidentally ship a quality regression to customers — every change is quality-checked before release."
- Caching saves tokens: "This lowers the feature's running cost by roughly X% a year with no change to the experience."
- Occasional hallucination: "There's a bounded accuracy risk; we contain it with grounding, citations, and human review on high-stakes answers, and we monitor it."
- Provider abstraction: "We're not locked to one AI vendor — if one raises prices or deprecates a model, we can switch with low disruption, which also gives us negotiating leverage."
Each leads with money/risk/time/experience; the mechanism is available if asked.
Context: A CFO funds a clear net-value case with honest assumptions, not a rosy point estimate.
Your task: Write a one-page ROI case for a representative AI feature (say, a support-drafting agent).
Requirements:
- State the business problem in money/time terms
- Quantify expected value as a range (conservative/expected/optimistic)
- Include build + run TCO
- State the key assumptions and what would make the number wrong
- End with the net value and the ask
💡 Hint: Net value with a confidence range beats a single optimistic number.
Show solution
Problem (BLUF): Support agents spend ~40% of time drafting routine replies; at current volume that's ~$1.2M/year of agent time on work an AI can draft.
Expected value (range): conservative 15% time saved → ~$180k/yr; expected 30% → ~$360k/yr; optimistic 45% → ~$540k/yr. Value = time saved redeployed to complex tickets + faster response.
Cost (TCO, from EL3): ~$30k build + ~$30k/yr run (inference + upkeep). Net expected value ≈ $330k/yr.
Assumptions / what makes it wrong: adoption reaches ~70% (the biggest lever — see EL4), draft-acceptance stays high, no trust-destroying incident. If adoption stalls at 20%, net value roughly quarters.
Ask: fund a 4-week pilot ($X) with a go/no-go on measured time-saved and acceptance before broader investment. All cost figures verified against current pricing.
Context: Boards decide on likelihood × impact and ownership, not exploit mechanics.
Your task: Take a real technical risk and produce the board-level framing.
Requirements:
- Pick a risk (e.g. prompt injection with tool access)
- Give the plain-language 'what it is'
- State likelihood × impact and why
- Name the owner and the mitigation in one line each
- Contrast it with the (wrong) jargon-heavy version
💡 Hint: Three sentences: what it is, how bad × how likely, what we do and who owns it.
Show solution
Board framing (right):
"What: A malicious instruction hidden in content our agent reads could try to make it leak data or take an unauthorized action. How bad × likely: High impact if it worked, but low likelihood because of our controls. What we do / who owns it: Security owns it; the agent can only access the data it needs and can't take irreversible actions without human approval, and we monitor every action — so even a successful attempt is contained and logged."
Jargon version (wrong): "Indirect prompt injection via retrieved context could pivot the ReAct loop to invoke exfiltration tools bypassing the system prompt's guardrails…" — the board glazes over and reads it as either 'scary and unmanaged' or 'he's hiding something.'
Why the first works: it gives the board exactly what it needs — the risk is known, sized, owned, and contained — and it comes from you, not a headline.
Context: AI roadmaps break when they promise dated features tied to unreleased capabilities.
Your task: Produce a now/next/later roadmap for an AI product line and defend why it's structured this way.
Requirements:
- Now: committed outcomes in flight (high confidence)
- Next: directional bets (medium confidence)
- Later: themes and options (low confidence)
- Include one capability-dependent item framed as a bet with a trigger
- Explain how this protects credibility
💡 Hint: Commit to outcomes and horizons, not dates on features you don't control.
Show solution
Now (this quarter, high confidence): ship the support-drafting agent to broad rollout; reach ~70% adoption in support; land the eval gate and HITL policy. These are in flight — we commit.
Next (following quarter, medium confidence): extend drafting to a second department; pilot difficulty-based model routing to cut cost. Direction is firm; specifics may shift on learning.
Later (themes, low confidence): deeper workflow automation; multi-step agents for back-office tasks. Options, not promises.
Capability-dependent bet: "If reasoning models reach the reliability bar for unattended multi-step actions, then we'll pursue autonomous back-office workflows" — a bet with a trigger, not a dated commitment on a model that doesn't exist yet.
Why it protects credibility: we only put dates on what we control; everything contingent is framed as a bet, so a shifted priority or a delayed model release is 'we learned and adjusted,' not 'they missed their commitment.' Credibility is the currency you spend on the hard asks later.
Context: Reporting the wrong numbers trains the org to optimize the wrong things.
Your task: Design the one-page monthly AI dashboard for the executive team.
Requirements:
- Pick ~5 metrics across value, cost, risk, and reliability
- Define each in one line and why an exec cares
- Include trend, not just a snapshot
- State what you deliberately leave OFF (and where it goes instead)
💡 Hint: Value, cost, risk, reliability — the four questions every exec actually has.
Show solution
Exec AI dashboard (monthly, one page):
- Realized value (adoption × per-task value, trend): are we getting the return? The headline.
- Run cost + trend (from EL3): is it economical and is spend under control?
- Open high/critical risks + owners (from the register): are the scary things known and owned?
- Reliability (uptime / SLA adherence): does it work when customers need it?
- Adoption trend (% of eligible work): the leading indicator of future value.
Deliberately left off: tokens/sec, p95 latency, model version churn, eval sub-scores — these belong in the engineering review, not the exec dashboard. Putting them on the exec page invites optimization of inputs instead of outcomes. Every metric shows a trend arrow so the story is direction, not a decontextualized snapshot.
Context: Representative scenario: the CEO, energized by a competitor's announcement, wants a fully-autonomous customer-facing AI agent live in six weeks. You assess it as high-risk, low-readiness. You must respond in a leadership meeting.
Your task: Deliver the 'no' (or 'not like this') in a way that is truthful, evidence-based, and keeps your influence and the relationship.
Requirements:
- Affirm the underlying goal the CEO cares about
- Present the risk and readiness evidence at board altitude
- Offer a credible alternative that serves the same goal
- Make the decision the CEO's, not yours
- Say how you'd handle it if overruled
💡 Hint: Agree with the goal, disagree with the method, bring evidence, offer a path, let them decide.
Show solution
Affirm the goal. "You want us to be visibly ahead on AI in the customer experience — I'm completely aligned on that, and I want us to win it."
Evidence at altitude. "A fully autonomous, customer-facing agent in six weeks carries high, hard-to-contain risk: a confident wrong answer or an unauthorized action goes straight to a customer, with reputational and possibly regulatory exposure (risk register: high impact, and at this timeline, high likelihood). We haven't proven the evals, the HITL policy, or the rollout that make it safe — so the expected value is low against a real downside."
Credible alternative. "Here's how we win the same goal fast: ship a human-in-the-loop version in six weeks — the agent drafts, a person approves — which is visibly ahead, low-risk, and gives us the data to expand autonomy safely. We announce the AI experience now and earn autonomy with evidence."
Their call. "That's my recommendation; you own the decision. If speed-to-announce is the priority, the HITL version gets us there without betting the brand."
If overruled: state the residual risk in writing for the register, insist on the minimum non-negotiable guardrails (action gate, monitoring, a kill switch, a bounded scope), and commit to making the CEO's chosen path as safe as it can be — disagreeing and then committing, with the risk owned and documented, not silently sandbagging.