how to run a bridge call that stays under 10 people
Runs an incident bridge call that stays under 10 people. Use when bridges balloon into audiences, too many voices slow decisions, or you need roles instead of a crowd. Covers the core roles, a waiting-room pattern, and async updates for everyone else. Not for declaring incidents, technical debugging, or postmortems.
TL;DR
A bridge with 40 people is a webinar, not a decision room. Cap the active bridge at the roles that decide and act: incident commander, comms lead, and the responders working the problem. Everyone else gets async updates in the incident channel, and subject-matter experts join on request and leave when their part is done. Small bridge, big audience via chat.
Error / query
how to run a bridge call that stays under 10 peopleUse this skill when
- Incident bridges grow into unmanageable crowds
- Too many voices slow down decisions
- You need clear roles instead of a free-for-all
- Executives want in but should not be in the working room
Not for this skill when
- Deciding whether to declare an incident (declaration criteria)
- Debugging the technical problem (the responders' job)
- Reviewing afterward (postmortem)
Steps
Step 1: Name the roles, not the people
Incident Commander (runs the call, makes decisions)
Comms Lead (writes updates, handles the channel)
Responders (2-4 people actively working the problem)
Scribe (optional; keeps the timeline)Expected: every person on the bridge has a role. If someone cannot name their role, they belong in the channel, not on the call. Announce the roster at the start.
Step 2: Move everyone else to the incident channel
Bridge stays at the roster above. Everyone else follows in #incident-[id]:
comms lead posts an update every 15 minutes, plus on any status change.Expected: stakeholders get better information from written updates than from listening to a working call. The channel becomes the record; the bridge stays a working room.
Step 3: Use on-request experts with a clear exit
Need a database expert? Page them, ask the specific question,
get the answer, thank them, let them drop.Expected: experts contribute without becoming permanent audience. The commander explicitly releases them (thanks, we have what we need), which keeps the headcount honest.
Step 4: Enforce the cap kindly and consistently
Commander script: "We are keeping the bridge to responders so we can
move fast. Follow #incident-[id] for updates; ping me if you need in."Expected: a standing, blameless phrase the commander can use every time. The rule has to apply to executives too, or it applies to no one.
Variant phrasings
"incident bridge too many people"
Steps 1-2. Roles plus the channel pattern fix the crowd problem structurally.
"who should be on an incident call"
The roster in step 1: commander, comms, responders, optional scribe. Everyone else async.
Why it happens
Bridges accrete people because joining feels like helping and nobody wants to be out of the loop. But every extra voice adds coordination cost and makes the commander manage the room instead of the incident. The channel gives everyone the information without the cost, and roles give the people on the call a reason to be there.
Edge cases and pitfalls
- SEV1s with customer impact may need a dedicated customer-comms person; add the role, do not just add people.
- If the same experts are needed for hours, rotate responders rather than growing the bridge; fatigue degrades decisions.
- Record the bridge or keep the scribe's timeline; people in the channel will ask what was decided.
- The cap is for the working bridge; a separate exec briefing call can run in parallel for leadership updates.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_iqIwRI0UvfW8Jf5UVtXnqQ