There’s a version of the stakeholder update that every engineering leader has written — the one that’s technically accurate, covers everything, and lands completely flat. The SVP skims it, asks one clarifying question that’s actually answered in paragraph four, and moves on. Nothing bad happens, but nothing good happens either. The update was noise.
At some point early in my career managing large organizations, I realized that “thorough” and “useful” are not the same thing. An update that takes thirty minutes to write and thirty seconds to absorb is infinitely more valuable than one that takes thirty minutes to read and leaves the reader unsure whether to be worried. The craft is in the compression — and the honesty.
Who You’re Actually Writing For
When your stakeholders are SVPs and VPs who are running organizations of hundreds of people, they are making portfolio decisions, not project decisions. They are not wondering whether your migration to a new data pipeline is technically sound. They are wondering: is this org on track, should I be worried, and do I need to do anything?
That’s it. Three questions. And most engineering updates answer none of them directly.
Think about what’s on that SVP’s plate on any given week — org design decisions, headcount battles, cross-org dependencies, partner escalations, maybe a reorg somewhere. Your update lands in a calendar that’s already broken. You have about thirty seconds of genuine attention before they mentally file it and move on. The update that respects that reality is the one that gets read, remembered, and acted on.
The Structure That Actually Works
A few years ago, I started forcing myself to answer three things in every update, in this order: what’s the state of the org, where are the real risks, and what do I need from you. Not because it’s a formula, but because it maps to how an executive actually thinks when they read it.
State of the org is not a project status roll-up. It’s a narrative about whether the organization is healthy and moving in the right direction. Are the teams staffed and executing? Are we hitting the milestones that matter for the next quarter? Is morale where it needs to be after that reorg six months ago? At the scale of multiple teams and a portfolio of systems, “green/yellow/red” per workstream is table stakes — what the executive actually needs is your honest synthesis of whether the aggregate picture is good.
Risk is where most leaders are too cautious (and I mean genuinely — not from dishonesty, but from not wanting to alarm people unnecessarily). The problem is that executives hate surprises far more than they hate bad news delivered early. An org-level risk isn’t “this microservice might have a latency issue in Q3.” It’s “we have a hard dependency on a team that has not committed to our timeline, and if they slip, our launch window closes.” It’s “we’re running a competitive hiring process against three other orgs for the same senior engineers, and we may not win.” That’s the kind of risk an SVP can actually do something about — and they can only do something about it if you tell them.
The ask is probably the most underdeveloped part of most updates I’ve seen. Engineers are trained to solve problems themselves, so the instinct is to present the problem and the solution simultaneously, with the ask being a rubber stamp. But at the leader-of-leaders level, the things you genuinely need from an SVP are different: organizational alignment across teams that don’t report to you, a conversation with a peer VP to unblock a dependency, air cover on a hard resourcing trade-off you’re about to make. Those asks require setup and clarity. Be specific about what you need, why you need it, and by when — and if you don’t need anything, say that too, so they know the update is informational.
The Honesty Problem
Here’s the thing about executive stakeholders that nobody talks about enough: they are very good at detecting when something is being smoothed over. Not because they’re unusually perceptive, but because they’ve read hundreds of updates and they’ve seen what a slightly-too-polished paragraph looks like. When every workstream is green and every risk is “being managed,” they start to wonder what’s actually going on.
The updates that build trust are the ones that include uncomfortable things, stated plainly. “We are behind on X, here’s why, here’s the recovery plan, and here’s what happens if the recovery plan doesn’t hold.” That sentence is worth more than three paragraphs of context-setting. It tells them you understand the situation, you’re not hiding from it, and you’ve thought about the downstream scenarios. That’s what leadership looks like in writing.
What Good Actually Looks Like
The best stakeholder update I ever sent was one page. It had three sections — State, Risk, Ask — and each one was three to five sentences. The State section synthesized six teams and a dozen active workstreams into a paragraph that told an honest story. The Risk section named two org-level risks that I’d been thinking about for weeks but hadn’t surfaced yet. The Ask section asked for one specific thing: a thirty-minute conversation with a peer leader to align on a shared dependency before it became a blocker.
The response was a calendar invite within the hour.
That’s not magic. That’s what happens when you write for your reader instead of for completeness.
The discipline of a good stakeholder update is really the discipline of clear thinking — because you can only write a crisp three-sentence risk paragraph if you actually understand the risk well enough to state it plainly. The update is the output, but the clarity has to come first. If you find yourself hedging or burying something in qualifications, that’s usually a signal that you haven’t fully thought it through yet — and that’s actually useful feedback, because it means the writing process itself is doing work.
Write updates that respect your stakeholders’ time and assume their intelligence. They’ll notice.