exec-comms

Executive communication

Executives read differently. They are scanning for a decision, a risk, or a number, across a queue of documents that all want something. The writing convention most people learned — build context, develop the argument, arrive at the conclusion — is precisely backwards for this reader, because it makes them work through material they may not need to reach the part they do.

Put the answer first. Then support it. Then, only if needed, the background.

The structure

Every executive document is a variation on this shape:

1. The ask or the answer          (1-3 sentences)
2. Why, in three points           (the supporting logic)
3. What it costs / what it risks  (the honest downside)
4. What happens next              (owner, date)
5. Appendix                       (everything else)

If the reader stops after section 1, they should still be able to act. That is the test. Write section 1 last, once you know what you are actually saying, and then check whether the rest is needed at all.

Section 1 in practice

State the decision being requested, the recommendation, and the deadline:

Asking for approval to move the Northwind renewal to a 3-year term at a 12% discount, by September 30. This trades $71k of year-one revenue for $340k of committed multi-year revenue and removes the competitive risk flagged in July. Recommend approving.

Everything a busy reader needs is there: what, how much, why, by when, and what you think. Compare against the version that opens with "As you know, Northwind has been a customer since 2023..." — which asks the reader to hold context before knowing what it is for.

SCQA, when you need a narrative

For documents that must persuade rather than just inform, the Situation— Complication—Question—Answer frame is the most reliable structure available:

• Situation — the stable context both parties agree on.
• Complication — what changed, creating tension.
• Question — what that forces us to decide.
• Answer — the recommendation.

Its power is that the reader arrives at your question themselves. By the time the answer appears, they are already asking for it. Keep Situation to one or two sentences; a long Situation is where executive documents go to die.

Numbers

Round to the precision the estimate supports. $1.2M says you have decided what matters. $1,247,318.44 says you have not.

Always give a comparison. A number alone is uninterpretable. "$340k" means nothing; "$340k, up from $290k last year, against a $325k target" means something. Every important number needs one of: prior period, plan, or benchmark.

Say what the number does not include. Volunteering the limit of your own figure is the cheapest credibility available, and it costs you almost nothing because a competent reader would have asked.

Bad news

Bad news travels badly when it is managed. It travels fine when it is reported.

Lead with it. Burying a miss in paragraph four means the reader finds it themselves and now distrusts the first three paragraphs.

Give the number and the cause separately. Executives can hold both. Merging them into an explanation reads as an excuse even when it is not.

Bring the plan. Not a full recovery plan — the next concrete step, its owner, and when you will know if it worked.

Do not pre-emptively apologize. It shifts the reader's attention from the problem to managing your feelings about it. Report, recommend, move on.

Recurring formats

Board update

Written for people with limited context and high judgment. What they need:

1. Headline metrics against plan. Three to five. Same metrics every time — changing them reads as hiding something even when it is not.
2. What changed since last time. Only material changes.
3. The one or two things you want their help with. The most underused section in board reporting. Boards are a resource; a board update that asks for nothing wastes it.
4. Risks, with what you are doing about each.

Consistency period-over-period matters more than completeness in any single update. A board that can compare this quarter to last quarter without re-learning your format gets far more out of it.

Pipeline and forecast slides

Board updates and internal QBRs almost always carry a pipeline slide, and it is the slide most often built from arithmetic done by hand on stage probabilities nobody sourced. Compute it instead:

PYTHONPATH="${CLAUDE_PLUGIN_ROOT}" python3 -m gtmkit.pipeline pipeline.csv \
  --stages stages.json --target 1200000 --closed 95000 \
  --period-end 2026-12-31 --as-of 2026-10-06

Then write it the way this skill writes everything else. Lead with the expected landing against target, and the commit number. Put coverage next to the coverage the stage probabilities need — a bare "2.2x" invites the reader to compare it with a rule of thumb that does not fit your stage mix. Carry the spread with the forecast ("$1.0M expected, ±$330k"), because a lone forecast figure is precision outrunning the estimate. If the engine graded the probabilities D or F, or ran on its placeholder model, say so on the slide: it is the limit a board member would otherwise find for you. Use the same stage model every period, for the same reason you keep the same metrics.

The file format and the stage model are in the pipeline format reference.

Customer QBR

The mistake is making it a status report. A QBR is a business review with the customer's business at the center.

1. What they set out to achieve — in their words, from the original case.
2. What actually happened — measured, including where it fell short.
3. What it produced — value delivered, against the original model.
4. What is next — jointly, not a list of things you want to sell.

If you built the original business case with value-case, revisit it here with real numbers. A vendor who returns with "here is what we projected and here is what actually happened, including where we were wrong" is in a category of one.

Escalation

1. What is broken, and the impact in their terms.
2. What has been done so far.
3. What you need from the reader, specifically.
4. When you will next update them.

Point three is the entire message. An escalation without a specific ask is a complaint.

Editing

After the draft, run these four passes:

Cut the first paragraph. It is warm-up, roughly 70% of the time.

Delete every sentence that survives its own deletion. If removing it changes nothing, it was there for rhythm, not information.

Find hedges and decide. "We believe it may be possible that" is either a recommendation or it is not. Executives read hedging as either an absence of a view or an attempt to avoid accountability for one.

Read section 1 alone. Could the reader act on it? If not, rewrite it — and resist the urge to fix it by adding section 2 into section 1.

Common failures

Context before conclusion. The default failure, and the most expensive.

Burying the ask. If you need a decision, the word "approve" or "decide" should appear early and unmistakably.

Metric drift. Changing which metrics you report between updates destroys comparability and looks evasive.

Precision that outruns the estimate. Four significant figures on a number built from a wide assumption is a claim the underlying work cannot support.

Passive voice around accountability. "Mistakes were made" tells the reader nothing they can act on and costs you the credibility that naming it would have bought.