How to Set Up a Cross-Team Standup in Slack
Cross-team standups fail for two reasons: they become too long for the information they convey, or they devolve into status reports that bore everyone except the person giving the update. An async Slack-based standup format solves both problems: it forces concise updates, captures information in a searchable format, and lets teams read at their own pace rather than sitting through a 30-minute meeting.
This guide covers setting up a cross-team standup in Slack that actually drives coordination — with a Workflow Builder automation, structured update format, and escalation path for blockers.
Step-by-step guide
Create a dedicated cross-team standup channel
Create a Slack channel named #cross-team-standup or #art-standup. Invite one representative from each team (the team lead or PM) and all program-level managers. Set the channel topic to the standup format and time. Pin the format message at the top of the channel so it is always visible. Keep this channel separate from individual team standup channels — cross-team coordination is a different conversation.
Build a Slack Workflow for the standup prompt
In Slack Workflow Builder, create a workflow scheduled to trigger automatically at 9 AM Monday, Wednesday, and Friday. The trigger action posts a message to #cross-team-standup with the standup template as a formatted block: "Time to sync! Post your update using this format: [Team Name] / Shipped this week: ... / In progress: ... / Blockers/Dependencies: ... / Needs from other teams: ..." The scheduled message creates a consistent signal without requiring anyone to remember to post.
Establish the update format with examples
Create a pinned message in the channel with a completed example update: "[Team Falcon] Shipped: OAuth integration PR merged and deployed. In progress: Sprint 3 onboarding improvements (70% complete). Blockers: Waiting on Team Hawk's analytics events schema — needed before Monday. Needs from other teams: Team Hawk to confirm analytics schema by Friday." The example sets the bar for what a good update looks like.
Set up an escalation path for blockers
When a blocker appears in an update, the team posting the update should add a @mention for the blocking team's lead in the update message. Create a norm: if a blocker is not resolved within 24 hours, the PM escalates to the #engineering-leads channel (or equivalent) with a brief context message linking to the original update. This two-step escalation prevents small blockers from being ignored while keeping the main standup channel clean.
Create a weekly program-level summary
Every Friday, the Program Manager or Scrum Master posts a weekly digest in the channel: a summary of all blockers from the week, which were resolved, which are still open, and any cross-team dependencies due the following week. Create a Slack workflow that posts a "Friday Summary" prompt automatically to remind the PM to write the digest. This digest is the weekly cross-team health check in 10 lines or less.
Review and improve the format quarterly
Every quarter, send a 3-question poll to the channel participants: Is the standup format giving you useful information? Are you seeing escalation happen fast enough? What would make this standup more useful? Make one change per quarter based on the feedback. Small, consistent improvements prevent the standup from becoming another ignored Slack channel.
Common mistakes
Scheduling the standup at a time that spans multiple time zones
A 9 AM Pacific cross-team standup asks London-based team members to post at 5 PM. Use 10 AM Pacific / 1 PM Eastern as the default for US-based teams. For global teams, make the standup fully async with a 24-hour window to post updates before the Program Manager compiles the summary.
Allowing long, narrative updates
Updates longer than 5 lines do not get read. Enforce the format strictly: shipped, in progress, blockers, needs. Anything that requires more than 5 lines belongs in a thread, not the standup. The PM can model this by posting the first concise update each standup day.
No accountability for teams that do not post
If some teams post and others do not, the standup loses value. Set a norm: if a team does not post by noon on standup days, the Program Manager DMs their lead asking for the update. Consistent follow-up creates the habit.
Treating the standup as a reporting exercise instead of a coordination tool
The goal of the cross-team standup is not to inform the PM of status — it is to surface blockers between teams. If blockers are not visible in updates ("everything is on track"), the format is producing false positives. Encourage teams to share early-warning blockers, not just confirmed ones.
Tips
Use Slack's /remind command to remind each team lead to post their update 30 minutes before the standup window closes
Add a weekly emoji reaction vote: at the end of each Friday summary, ask participants to react with a green check if they got what they needed from the standup this week or a red X if not — this gives the PM a quick weekly satisfaction signal
Link the cross-team standup channel to your dependency Miro board in the channel topic so any new dependencies mentioned in updates can be quickly added to the board
Archive standup threads monthly in Notion or Confluence with a "Retrospective" tag — the historical record of blockers and how they were resolved is valuable for future PI Planning
How Vantage helps
Vantage's conflict detection feature identifies when two projects have overlapping requirements or competing dependencies. When this kind of cross-team conflict is detected, Vantage surfaces it as a risk on the project dashboard — giving you the blocker intelligence you need before it shows up as a standup update.