To give a concise status update, report what changed, what could stop the plan, and what happens next: outcome, blocker, next step. Start with the result, not the chronology. If there is no blocker, say so. End with the owner, deadline, or request that makes the next step real.
Aim for about 30 seconds when that level of detail fits the meeting. Use the limit to practise choosing what matters. Move technical history and problem-solving to a follow-up, but keep important risks, uncertainty, and bad news visible.
Method
A 30-second status map
What changed?
What threatens the plan?
Who does what, by when?
A status update is not a work diary
Long updates often follow the order in which events happened: first the email, then the call, then the review. That order may help you remember the work, but it makes everyone else wait for the point.
A useful update gives the group enough information to decide whether anything needs attention. Replace “What did I do?” with “What changed that matters?” Add history only when it changes a decision, risk, or request. For a broader test of what to keep, see how to give shorter answers at work.
What concise status updates are meant to accomplish
The 2020 Scrum Guide asks a Daily Scrum to inspect progress, surface anything getting in the way, and plan the next work. That is a useful test for any status update: does the group know what changed, what needs attention, and what happens next?
Thirty seconds is a rehearsal target for a routine update, not a meeting rule. If the group needs a minute to understand a real risk, take the minute.
Use outcome, blocker, next step
Use three prompts: outcome, blocker, next step.
Outcome: what changed?
State the result or current state in one sentence. Prefer an observable change over a list of activities.
- “The proposal is approved and ready for design.”
- “The migration is complete, but validation is still open.”
- “There is no new result yet; the test is still running.”
“No progress” can be a clear outcome. Say it early rather than disguising it with an account of effort.
Blocker: what threatens the plan?
Name the issue, dependency, or risk that could change the date, scope, cost, quality, or decision. Add the consequence if it is not obvious.
If nothing needs attention, say: “No blocker that needs the group's attention.” Do not use that line when a real risk exists. Concision should reveal risk, not hide it.
Next step: who does what, and by when?
End with an action, owner, and timing. Make any request explicit.
Outcome: [What changed or what is true now.]
Blocker: [No blocker, or the issue and its likely impact.]
Next step: [Owner, action, and timing.] I need [person] to [decide or help] by [time].
Three spoken examples
The facts below are fictional.
Standup
Checkout logging is now in staging. No blocker that needs the team. I am running regression tests this morning and will hand the build to Priya by 15:00.
Executive check-in
Recruitment has reached 18 of the 20 pilot sites. Legal review in two regions is the main risk. Nadia will decide by Wednesday whether to narrow the launch, and I need approval today to hold two backup sites.
Cross-functional meeting
Campaign copy is approved. Design is blocked on final pricing. Jules, can Finance send the approved figure by 14:00? Once it arrives, Lina owns publishing the page tomorrow.
A 75-second update and a 30-second version
Listen for how the shorter version changes the order and removes the history.
Roughly 75 seconds
Quick update on the launch. Last Tuesday we sent the final integration questions to the vendor. They replied Thursday, and I reviewed the response with engineering on Friday. Most of the API details were fine, but the production credential was missing. I emailed their support contact Friday afternoon and copied our account manager. We have not received it yet. In parallel, the build is complete and QA started its final pass this morning. They have finished the payment and account tests and expect to complete the remaining mobile checks on Monday. We had originally planned to freeze the build Monday evening, so there is still some room, but only if the vendor credential arrives by Tuesday morning. If it does, we can keep the Thursday launch. If it does not, we will need to move the date. Maya is following up with the vendor, and I am preparing a fallback plan. Sam, it might help if you contact their account lead as well.
Roughly 30 seconds
The launch build is complete, and QA is on track to finish Monday. The only blocker is the vendor's production credential, which we requested Friday. If it arrives by Tuesday, Thursday's launch stays on track. If not, the date will slip. Maya owns the vendor follow-up, and I need Sam to escalate with their account lead today.
The shorter version drops the email chronology. It keeps the outcome, QA date, dependency, consequence, owner, and request. The fallback plan and technical diagnosis can move to a follow-up.
Try it aloud, then retry without chronology
Choose one project and open the speaking.app speech timer. Set a custom limit of 30 seconds.
- Give a first attempt from memory without restarting.
- Notice how long it takes before you state the current outcome.
- Write three cue words: outcome, blocker, next step.
- Retry without “first,” “then,” or “after that” unless sequence affects the decision.
- Compare the first 10 seconds. Did the current state arrive earlier?
The goal is not to talk faster. It is to make the useful information arrive sooner.
When this advice does not fit
Do not compress a serious risk until it sounds harmless. If safety, a legal obligation, a customer commitment, a launch, or major cost is at risk, lead with that fact and give the detail needed for a decision.
Complex work may also need more context. Use the short update as a headline, then expand on evidence, options, and trade-offs.
Accessibility can change the format. The W3C checklist for accessible meetings recommends accessible materials in advance and support such as captions or interpreters when needed. Some people need more time to speak, process questions, or use assistive technology. Do not treat speed as competence. A written update can support the spoken version.
Frequently asked questions
What belongs in a status update?
Include the result or current state, any blocker or important risk, and the next action with an owner. Add context only when the audience would otherwise misunderstand the impact. Leave out the full task list and chronology unless they change a decision.
How long should a standup update be?
There is no fixed per-person limit. About 30 seconds is a practical target for a routine, low-complexity update. Take longer when the group needs more information to coordinate or decide.
What do I say if there is no progress?
Say it directly: “There is no new outcome yet.” Then give the reason, impact, and next step. For example: “The test is still running, so we do not have a result. There is no new blocker. I will share the result by 16:00.”
How should I report a blocker?
Name the dependency, explain what it threatens, and ask for the help or decision you need. “We are blocked” is incomplete. “The vendor credential is missing, which puts Thursday's launch at risk. Maya owns the follow-up, and I need Sam to escalate today” is actionable.
How do I give bad news concisely?
Lead with the changed reality, not the explanation. State the impact, what you know, what remains uncertain, and the recovery action. Do not bury bad news under reassuring detail. Concision helps only when it makes the problem and response clearer.
Practise the skill
Use the speech timer for one 30-second attempt, then retry with the three cue words visible. For less scripted practice, open impromptu speaking practice and answer a random prompt aloud without preparing a paragraph.
