Writing for Stakeholders
The first line is the decision you need or the thing that changed for them; everything after it is optional reading for whoever wants the detail.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
If someone reads only the first line of your update, what must they know?
The finance lead asks the team lead: "Can someone send me an update on the checkout project? I need to know whether it affects the quarter." The team lead forwards it to you.
Write a thorough update: background, what the team did this sprint, what is in progress, risks, next steps. Completeness shows respect for the reader and leaves nothing out.
Finance reads the first two lines — background they already know — and stops. The one sentence that matters, that launch moves two weeks and what that means for revenue, is in paragraph four under "Risks".
- Finance reads the first two lines — background they already know — and stops. The one sentence that matters, that launch moves two weeks and what that means for revenue, is in paragraph four under "Risks".
- A chronological update makes the reader do the synthesis. The busier the reader, the less likely they are to do it, and senior stakeholders are the busiest readers you have.
- Completeness hides the ask. "We will need a decision on launching without the buy-now-pay-later option" sits in "Next steps", nobody answers it, and it becomes a blocker the week before launch.
- Every update has the same shape and the same tone, so readers learn to skim them. The update carrying bad news gets skimmed too.
What is really going on
- Stakeholders read in order and stop early. An update is a stack; they read from the top until they have what they came for, or until something else needs them.
- The first line can only usefully be one of three things: a decision you need from them, a change to something they rely on (a date, a cost, a scope), or "no change, nothing needed". Each needs a different sentence.
- The reader's question is not "what did engineering do?" but "what does this mean for me?" — the quarter, their team, their customers. Write it in their unit: money, dates, orders, support tickets.
- Everything below the first line is optional depth, useful to the reader who wants it and as a record. Structure it so it can be skipped without loss: short headings, short bullets.
- A fixed format week after week is what makes a change visible. When the first line is always in the same place, the week it says something different is noticed.
The first line is one of three things
Before writing anything, decide which kind of update this is. That decides the first sentence, and the first sentence is most of the update for most readers.
| Kind of update | First line | Example |
|---|---|---|
| You need a decision | The decision, the deadline, your recommendation and the default | "Decision by Thursday: launch without buy-now-pay-later? We recommend yes; default is yes." |
| Something they rely on changed | The change and its consequence in their unit | "Launch moves to 17 March; Q1 revenue is not affected." |
| Nothing changed | That, and that nothing is needed | "On track for 3 March. Nothing needed from you." |
Rewriting an update from the top
Most weak updates contain the right sentence. It is just in the wrong place. Rewriting is usually moving one sentence up and deleting two.
Finance asked whether the checkout project affects the quarter. Launch is slipping two weeks because the payment provider has not finished its review, and you need a call on launching without buy-now-pay-later.
"Hi! Quick update on checkout. As you know, we have been rebuilding the payment step to support more providers. This sprint we finished the address form and the new order summary, and started on the payment integration. We have hit a delay with the provider's review, which may push things back a bit. Next steps: finish integration, QA, and we will need to decide whether to launch without buy-now-pay-later. Let me know if you have questions!"
"Launch moves from 3 to 17 March. Q1 revenue is not affected — the current checkout keeps taking orders until the switch. One decision by Thursday: launch on the 17th without buy-now-pay-later, adding it in April? We recommend yes. If we do not hear back, we go ahead. Detail, if useful: the provider's review is the cause; we submitted on the 2nd and they have committed to the 12th. Everything else is done."
A status update skeleton
A fixed shape does two things. The reader learns where to look, and the week the top line changes, they notice. The skeleton below is short on purpose; most weeks the first two lines are the whole update.
1**Status:** On track for 3 March | Slipping to 17 March | Blocked2**Needed from you:** Nothing | Decision by <date>: <question>. We recommend <X>. Default if no reply: <X>.3 4### What changed for you5- <one line in your unit: revenue, dates, customers, support load>6 7### What we do not know yet8- <unknown> — we will know by <date>9 10### Detail (optional)11- Done this week: <bullets>12- Next: <bullets>13- Links: <one-pager>, <decision record>The ask has three parts — the question, the recommendation, and the default — so that silence is also an answer and you are never blocked on a reply.
Translate into their unit
Engineering progress is naturally measured in engineering units: tickets closed, services migrated, tests passing. None of those are what a finance lead, a support lead or a PM is deciding with. Translating is not dumbing down; it is doing the synthesis you are better placed to do than they are.
Payment service migration 80% complete; 3 of 5 providers integrated; p95 latency down 40ms.
Card and wallet payments move to the new checkout on 17 March. Buy-now-pay-later follows in April. Customers will see a faster payment step; nothing changes for refunds.
The first requires the reader to know what a provider integration means for customers and dates. The second tells them what changes, for whom, and when — which is what they will be asked about.
How to do it
Most important first.
- Write the first line last. Draft everything, then ask "if they read one sentence, which one?" and move it to the top.
- One ask per update, with a deadline and a default: "If I do not hear by Thursday, we launch without it and add it in May."
- State any change in the reader's unit: "Launch moves from 3 to 17 March. No effect on Q1 revenue — the current checkout keeps taking orders until then."
- Use the same skeleton every time so readers know where to look (A Shipping Cadence the Team Can Keep).
- Say what you do not know and when you will: "We will know by Friday whether the payment provider approves us" ("I Don't Know Yet").
- Remove engineering vocabulary. "Migration", "flag", "refactor" become what they mean for the reader, or they go.
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- When someone asks why the update is so short: "The first line is the thing you need to act on. Everything under it is there if you want the detail."
- For bad news, lead with it and its consequence, then the cause and the plan: "Launch moves two weeks, to 17 March. Q1 revenue is not affected. The cause is the payment provider's review; we submitted on the 2nd and they have given us a date."
- For an ask: "Decision needed by Thursday: launch without buy-now-pay-later, or wait two weeks for it? We recommend launching without it. If we do not hear back, we launch."
- For no change, say only that: "On track for 3 March. Nothing needed from you." That is a complete update, and writing it is what earns attention for the week it is not true.
- "Leading with the delay will panic them." They will find out either way. The choice is whether they hear it from us with the consequence and the plan, or from someone else without either.
- "My manager likes to see all the detail." It is all still there, under the first line. Leading with the decision does not remove anything.
- "Our updates have always been in sprint order." Sprint order is how we worked; the reader's order is how they decide. The detail can stay in sprint order below the top line.
What can go wrong
- Burying bad news in the middle to soften it. It softens nothing, and when it is found, every later update is read with suspicion.
- Over-correcting into alarm: every update leads with a risk, so the week there is a real one it reads like the others.
- The ask without a default. The reader can ignore it at no cost, nothing happens, and you are blocked.
- Writing for the reader you wish you had: sending the finance lead latency percentiles because they are what you are proud of.
- "Short means less information." Short at the top, full underneath. Nothing is removed; it is reordered.
- "Stakeholders want to see how hard we are working." They want to know what it means for them. Effort is not their unit.
- "A good update needs no reply." If you need a decision, the update has failed until someone replies with one.
Knowing whether it worked
- Stakeholders answer the ask in their first reply, without a follow-up meeting.
- "Can you give me a quick summary?" replies stop arriving.
- Nobody is surprised in a review by something that was "in the update".
- The finance lead quotes your first line in their own report upward — which means it was already in their unit.
- With one stakeholder, this is a chat message. With twenty, the first line has to work for all of them, or you send two updates to two audiences with two different first lines.
- In a larger organisation updates get forwarded, and the first line has to survive without the thread it was written in.
- Over months, the updates become the record of what was said and when. That record settles more arguments than any meeting does.
- It takes longer. A short update with the right first line takes more thought than a long one with everything in it.
- Leading with bad news makes you the messenger. Some teams punish that, at least in the short run, and you should know whether yours does.
- Compressing to their unit loses nuance. A single sentence can be quoted without the caveats, so the first line has to be true on its own.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALHolds for email, chat, docs and tickets alike. Where an organisation mandates a fixed report template, the rule moves inside it: the first line of each section carries the point, and the summary field carries the ask.
- ROLE-SPECIFICWriting to an executive or a finance lead, the first line is almost always money, dates or a decision. Writing to a peer engineering team, the first line is often an interface change or a date they depend on, and more technical detail is welcome underneath.