To turn cross-team project activity into an executive status update, stop reporting by team and start reporting by milestone. Collect each team's activity, map it to the milestones your sponsor cares about, keep only what changed since the last update, apply one shared status scale, and raise only the risks and decisions that need the executive. Link every line to its evidence.
The rest of this guide covers each step in the order you would do it, with wording you can reuse and an illustrative before-and-after example.
What should the finished executive update contain?
An executive status update contains an overall status, a short summary of what changed, progress against milestones, the top risks, and the decisions or help you need. Jacob Kaplan-Moss describes a good executive update as "very short", "a few minutes, max", with "just a handful of key points".
His structure is a useful target: an overall summary, one or two highlights, the biggest risks, a request, and "Any questions?". monday.com recommends an inverted pyramid that puts "decisions needed, active risks, and project health at the top" so a skimming reader still gets the essentials.
Use this skeleton every time:
Overall: [Green / Amber / Red]. [One sentence on why.]
Changed since [last update date]: [one or two sentences]
Milestones:
- [Milestone 1]: [status], [what moved], [evidence link]
- [Milestone 2]: [status], [what moved], [evidence link]
Risks: [risk], [impact on date, scope or budget], [owner], [response]
Decision or help needed: [the ask], [options], [your recommendation], [needed by date]
Everything below is about filling that skeleton honestly from messy inputs.
How do you collect activity from several teams without drowning in it?
Collect cross-team activity from a fixed list of sources and a fixed window: everything since your last update, from the same places each time. Ask each team for a short note in the same format rather than reading every ticket and thread yourself. A consistent input format is what makes the rollup repeatable.
- List the sources once: [task tool], [code repository], [meeting notes location], [chat channels]. Keep the list in your project notes.
- Set the window: from [last update date] to today.
- Send each team lead the same request before your deadline for drafting:
For the update on [date], please reply by [time] with:
- What finished since [last update date] (link it)
- What is now blocked or late, and what it affects
- What you are waiting on, and from whom
- Who is waiting on you
- Your status for each milestone you touch: Green / Amber / Red, using our shared definitions
- Skim the raw sources only to check the notes, not to replace them. You are looking for anything a team missed or described differently from the tracker.
If you use Unblockd, its connectors cover GitHub as live-certified; Jira, Asana, Monday, Linear, ClickUp, and docs tools in early availability.
How do you group team work by milestone instead of by team?
Group work by milestone by tagging every item from the team notes with the milestone or deliverable it moves. Executives track outcomes, not team rosters, so a single milestone line may combine progress from several teams. Items that map to no milestone stay out of the executive update.
Tuplebits frames this as focusing on "decisions required and major risks, not task-level activity". In practice:
- Write your milestones down the left of a scratch table and the teams across the top.
- Drop each finished, blocked, or late item into its cell.
- Read across each row. That row becomes one line in the update.
- Keep a short "unmapped" list. If something important keeps landing there, your milestone list is missing a deliverable; raise that with your sponsor rather than hiding the work.
When two teams report the same piece of work (a pull request and the ticket it closes, for example), count it once and link the clearest piece of evidence.
How do you find what changed since the last update?
Find what changed by comparing each milestone row with the same row in your previous update. The executive update reports movement: a milestone completed, a date that moved, a new risk, a risk closed, a decision made. Steady work that changed nothing at milestone level gets no line of its own.
Ask three questions per milestone:
- Did the status change? If so, say why in one clause.
- Did the forecast date, scope, or budget change? If so, give the old and new value.
- Did anything finish that the sponsor would recognise? That is a candidate highlight.
Project Manager Copilot suggests the summary should state "what changed since the last update" and the immediate implication for scope, timeline, budget, or delivery confidence.
How do you set one overall status when teams disagree?
Set a single overall status by giving every team the same written definitions, rating each milestone rather than each team, and letting the overall status follow the most serious milestone that affects the delivery date. If you override that rule, write down your reason in the update. Shared definitions are what make one team's green mean the same as another's.
Agree definitions like these with team leads early and keep them in your project notes:
- Green: the milestone date holds and no help is needed from outside the team.
- Amber: the date is at risk, and the team has a recovery plan it can carry out itself.
- Red: the date will slip, or recovery needs a decision or help from the sponsor.
When teams disagree about a milestone they share, go to the evidence before you pick a colour: the open tickets, the dependency, the date in the plan. Ask both leads one question: "What would have to be true for this to be green by [date]?" The answer usually reveals the real status.
A colour alone is not enough. Project Manager Copilot warns that "a red status with no recovery path creates anxiety" and that a green status hiding a schedule trend damages trust. Always pair the colour with a reason and a response.
Which risks and decisions should reach the executive?
A risk or decision reaches the executive only if it changes a milestone date, scope, or budget, or needs a decision or help that only the sponsor can give. Everything else stays with the teams. That test keeps the update short and makes each ask easy to act on.
Project Manager Copilot also advises keeping risks and issues apart: "A risk is a credible future problem. An issue is already affecting delivery."
Watch especially for cross-team dependencies. Compare the "waiting on" and "who is waiting on you" answers from each team. If one team says it is waiting on another, and that team does not list it, you have found a hand-off nobody is managing. Gixo's page describes the same concern: keeping "a stalled hand-off between two teams" from staying buried in one team's notes. Resolve it with both leads first; escalate only if it meets the test above.
Write each ask so the sponsor can answer it without a meeting:
Decision needed by [date]: [question].
Options: [A], [B].
I recommend [A] because [reason].
If we have no decision by [date], [what happens to the milestone].
How do you link each claim back to its evidence?
Link each line of the executive update to the ticket, pull request, document, or meeting note that supports it. Evidence links let the sponsor check a claim in seconds and let you defend the update when someone asks. Kaplan-Moss notes that leaving out detail works as long as you can back it up.
Practical rules:
- One link per line, to the most direct evidence. A merged change beats a chat message saying it is done.
- If a team's note contradicts the tracker, use the evidence and ask the team to fix whichever is wrong.
- If a team did not reply, do not guess. Write "[Milestone]: not confirmed since [date]" and follow up.
- If you draft with an AI assistant, check every figure and date against the source yourself. Even Gixo, which reconciles figures against uploaded sources, tells users to "check source dates, reporting definitions and unrepaired figures before sharing the rollup".
What does a before-and-after example look like?
The example below is illustrative and uses placeholders. It shows raw activity from several teams collapsing into a short update organised by milestone, with only the changes, a single status, and one ask.
Before: raw activity since [last update date]
[Team A] closed [ticket] "[login screen copy]"
[Team A] merged [pull request] for [data import]
[Team A] standup: waiting on [Team B] for [API change]
[Team B] chat: "[API change] not planned until after [other work]"
[Team B] closed several bug tickets on [internal tool]
[Team C] meeting notes: [training materials] draft done, review pending
[Team C] chat: vendor quote for [licences] came in above budget
[Team A] reopened [ticket] after test failure, fixed same day
After: the executive update
Overall: Amber. [Data migration] is at risk from a cross-team dependency.
Changed since [last update date]:
- [Data migration]: Amber. Import is built [link]; it needs an [API change]
from [Team B] that is not yet scheduled [link]. Forecast moves from
[old date] to [new date] unless the change is prioritised.
- [Training]: Green. Draft materials complete [link]; review due [date].
Risk: [Licence] quote is above budget by [amount] [link]. Owner: [name].
Response: comparing [option A] and [option B] by [date].
Decision needed by [date]: prioritise the [API change] in [Team B]'s
next cycle ahead of [other work]?
I recommend yes, because it protects the [go-live] date.
The bug fixes on [internal tool], the copy change, and the reopened ticket are real work, but none moved a milestone, so they stay in team notes.
How do teams check their part before it goes up?
Teams check their part by reviewing the draft milestone lines that cite their work before you send the update. A quick review catches misread evidence and avoids a team lead being surprised by how their work was described to the sponsor. Keep the review light: confirm or correct, not rewrite.
Send the draft with a clear deadline:
Draft update for [date] below. Please check the lines that mention [team]
and reply by [time] with "confirmed" or a correction plus evidence.
No reply means I will send it as written.
You own the final wording and the overall status. Team leads own the accuracy of their facts.
When is a short rollup the wrong format?
A short rollup is the wrong format when the sponsor needs the detail to make a decision, such as a recovery plan for a red project or a scope trade-off. In those cases send the short update as the cover and attach the supporting analysis. Project Manager Copilot suggests scaling depth to the project's stakes and health.
Condensing also carries a real cost: a problem filtered out today can surprise the sponsor later. Keep your scratch table and unmapped list from every cycle, and review them before each update so a small issue that keeps recurring gets noticed early.