event-run-of-show

Event Run of Show

You own the day itself. The grid arrives decided and you never reopen it: samber/dev-event-organizer-skills@event-schedule-design states the split from its own side - "You stop at the published grid: how staff execute it minute by minute on the day, and how they respond live to a no-show or an AV failure, is samber/dev-event-organizer-skills@event-run-of-show".

It also hands you one more artifact besides the grid: a disruption priority order written into the schedule document.

1. Protect the plenary or keynote first.
2. Protect the headline commitment the audience showed up for next.
3. Minimize how many other sessions the fix disturbs.
4. Lock the revised grid for the rest of the block.

Consume that order. Do not re-derive one under pressure.

samber/dev-event-organizer-skills@event-speaker-experience states the same boundary from its side - "the minute-by-minute conduct of the day belongs to samber/dev-event-organizer-skills@event-run-of-show", and it lists this skill as owning "the day-of minute-by-minute document; hand it your speakers' timing needs." Green room, tech check and the on-site host who walks a speaker to their room stay there. You receive arrival and timing constraints as input, and you are where a speaker's live delay becomes a decision.

Two more boundaries:

• samber/dev-event-organizer-skills@event-risk-management authors the standing register and the printed emergency plan: which scenarios, which contacts. You never re-author a safety scenario; you own the on-duty person and the channel that execute that plan when something happens.
• samber/dev-event-organizer-skills@event-production engineers technical redundancy: the backup mic, the second recording path. You own what a room lead does in the ninety seconds after the redundancy fails.

Every ranking below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank all three menus against what you already know. Each of these can overturn a default rung:

• Radios the event already owns.
• A venue basement with no signal.
• A volunteer team that has run this day four times.
• A room that started late every hour last edition.
• A hard briefing deadline.

Interview

Ask one question at a time, multiple-choice where possible. Questions 5-7 exist because the menus diverge sharply on time-to-effect, durability and effort - those orderings cannot be picked for the user.

1. What is the published grid, and did the schedule document arrive with a disruption priority order? If not, get it before writing anything (see workflow step 1).
2. How many rooms or stages run at once, and what staffed posts exist besides them - registration, production, info desk, a sponsor hall?
3. Who is actually on the day, and in what shifts? Volunteers, organizers, paid crew, venue staff. This is an input from samber/dev-event-organizer-skills@event-volunteers, not something you build.
4. Does mobile coverage hold everywhere staff will be, and does the venue run its own comms you have to join rather than talk over?
5. What is the last moment you can still change something - print the cue sheet, add a person to a shift, brief a room lead? That deadline, not the event date, is what the menus are ranked against.
6. One-off edition or a recurring event? A recurring event promotes the rungs whose payoff lands after this day ends: a reusable cue-sheet template, a written handoff format, recorded turnover times.
7. What is the effort ceiling - who writes and maintains this document, in how many hours, and how many people can be on duty rather than doing a job?
8. Does a printed emergency plan already exist, and who is named on it? If not, that is samber/dev-event-organizer-skills@event-risk-management's work and it blocks you.
9. What already exists that should re-rank the menus: last edition's overruns, radios you own, a basement with no signal, a team that has run this before, a room that always starts late?
10. Is the opening recorded or livestreamed, and does any sponsor contract fix wording that must be read verbatim?

Community-run or vendor-run: tested, and it splits only part of this

The community-run versus vendor-run split holds for one part of the day and fails for the rest.

It holds for hosting. DevOpsDays writes "one or more MCs" - plural, as a legitimate design, not a fallback. That is a real fork:

• Community pole: distributes hosting among organizers who already embody the event's norms, against no set playbook. Plan a rotation of organizer-hosts and a separate speaker-introducer per session.
• Vendor pole: treats hosting as a named craft with a briefed and rehearsed single host. Practitioner guidance there covers scripting to the culture and rehearsing together beforehand. It also covers the discipline that "the first 90 seconds set the tone for the entire event" (guidance from professional-host services that sell MC work, so read it with that interest in mind). Plan one host, one script, and one rehearsal, and let cue-sheet depth move up a rung on its own.

It fails for everything else. A transition takes the same seconds to execute, a radio reaches the same distance, and a handoff drops the same context whoever paid for the venue.

What actually changes the rest of the work is how many staffed posts run at once and whether anyone on duty is also doing a job. A single-room meetup where three organizers see each other all day needs no channel architecture at all. A four-room day needs one before it needs anything else.

Say which pole or which scale a recommendation assumes whenever they differ.

Workflow

1. Take the published grid and the disruption priority order. If the schedule document has no priority order, go get one rather than inventing it - the ordering is a program decision, and improvising it at 14:00 with a hall full of people is how a keynote gets cut to save a sponsor slot.
2. Collect the inputs the day depends on: the shift plan, every speaker's arrival and timing constraint, the venue's own windows and staff, and the printed emergency plan with the names on it.
3. Assign the day-of roles (see below) by name, not by function. "A volunteer" is not an owner.
4. Build the cue sheet at the depth the menu picks, working from the grid outward - a row per segment and per transition, not a row per hour.
5. Set the comm channel architecture and write the two escalation paths onto the cue sheet itself: the routine one (a staffed post hits something above its authority) and the incident one (which triggers into the emergency plan, which you do not rewrite).
6. Build the on-duty rotation and the handoff format. Publish who is on duty for every block on the cue sheet, where a volunteer at a registration desk can read it without asking anyone.
7. Brief everyone against the document, not around it. The briefing is where you find out that two rows assume the same person is in two rooms.
8. Run the day. At each transition, execute the cue: queue position, tech ownership, spoken line (see below).
9. When something breaks, run the live disruption sequence (see below) rather than deciding fresh.
10. At each shift change, complete the handoff before the outgoing person leaves - including the live channel check.
11. Close out: the last segment, the venue handback, and the same-day capture of what the document got wrong.

Present the run of show section by section for validation - roles, then the cue sheet, then comms and escalation, then the rotation - before it is printed and briefed. After printing, every change costs a person who is holding the old version.

If your harness has persistent memory, record:

• Which rows turned out wrong.
• Which transitions ran long.
• Where the comm channel failed.
• Who was actually reachable.
• The venue's own comms and coverage facts.

A venue you use twice is worth not re-learning.

The day-of roles

Three roles come from published organizer guides. The fourth is one you define yourself, and it is labelled where it appears.

• MC (sourced) - kicks off and orchestrates the event. One or more; splitting the duty across people is named practice, not a compromise.
• Speaker introducer (sourced) - a separate role from the MC, assigned per session. The MC orchestrates the whole event's flow; somebody else handles the per-session task of introducing whoever is next. Collapsing the two is a named failure mode below.
• Organizer on duty (sourced) - the named person who takes last-minute decisions for a block, and the target of the routine escalation path. Sourced explicitly as single-point-of-failure mitigation for crisis decision-making, not as a fairness rota.
• Room lead (a role you define yourself) - one person per room who owns that room's clock: holds a start, cuts a Q&A, gets the tech owner, and escalates to the on-duty organizer. Published practice assumes per-room ownership without fixing what that person may decide, so define its authority explicitly in your own document - what it may do alone, and what it must escalate.

Cue-sheet depth

Ranking (default, not a law - Q5, Q6, Q7 and Q9 re-rank it):

• effort (hours writing, rehearsal, per-segment arithmetic, coordination at the briefing): word-for-word MC script > per-slot execution budget > scripted transitions > timed grid with named owners

• value, a day that runs without dead air or a dropped handover: scripted transitions > per-slot execution budget > timed grid with named owners > word-for-word MC script

• value, what the audience remembers of the opening and the closing: word-for-word MC script > scripted transitions > timed grid with named owners == per-slot execution budget - argued tie: neither an owner column nor a setup-and-swap number changes a single word anybody hears. Both buy a day that runs, not a moment anyone recalls.

• efficiency: timed grid with named owners > scripted transitions > per-slot execution budget > word-for-word MC script

• Timed grid with named owners - the default: every segment and every transition gets a start time, a named owner and a room. Near-zero, because the grid already exists and you are adding a column. Move up one rung the moment any block hands over faster than the buffer absorbs - lightning talks, demos, back-to-back sponsor slots - or the moment more than one room runs at once.

• Scripted transitions - what physically happens at each handover: where the next presenter stands, who owns the tech, and the line that gets said out loud. This is the sourced mechanic, drawn from a rapid-fire format and generalizing to any tight transition; the mechanics and a worked row are in references/cue-sheet-anatomy.md.

• Per-slot execution budget - budget the setup-and-swap tax inside slots that carry live execution risk, instead of assuming the published slot length covers it. The one sourced worked example budgets ten minutes per team for a live demo: three minutes of demo, one to two of questions, and the remaining five to six for setup and swapping to the next team - more than half the slot spent on neither. Present it as that event's number for that format, never as a constant.

• Word-for-word MC script - the starved option: every line written and rehearsed. It tops the memorability axis and tops effort, so efficiency never picks it. Promotion conditions, keyed to Q10: a single hired or briefed host rather than distributed organizer-hosting, a recorded or livestreamed opening, sponsor lines that must be said exactly as contracted, or a first edition where nobody has done this before and reading beats improvising.

• Delete, do not demote: the attendee-facing published schedule used as the staff document. It names no owner, no transition and no tech, and leaving it on the menu is how a day ends up being run off the public agenda by whoever is holding a phone.

Comm-channel architecture

The sourced pattern is structural, not a product: one coordination channel reserved for the organizing team, kept separate from every population-facing channel - including the channel attendees use to reach organizers, which is a different, public space that organizers merely monitor. The source implements this on a chat platform because it describes a hackathon; the split carries over to radios, a phone group, or three people who can see each other. Name the medium your event actually has.

Ranking (default, not a law - Q2, Q4 and Q9 re-rank it):

• effort (hardware, setup, discipline to teach people who have never used it, message volume to manage): radio net with call signs > role-addressed channels > text-plus-live pair > single organizer channel

• value, a message reaches the right person during a live problem: radio net with call signs > role-addressed channels == text-plus-live pair > single organizer channel - argued tie: each buys exactly one split of the same undifferentiated stream, one by function and one by urgency, and which split helps depends on whether your day's confusion runs along roles or along noise. Neither reaches anybody who is out of signal.

• value, a handoff or a post-event review has something to read: text-plus-live pair > role-addressed channels > single organizer channel > radio net with call signs. Radio leaves nothing behind, which is exactly why it sits last here and first above.

• compliance cost (the review it triggers, and what is hard to undo): radio net with call signs > single organizer channel == text-plus-live pair == role-addressed channels - argued tie: all three sit on a platform the event already accepted terms for when it opened its attendee channels, so none triggers a review that has not already happened. The radio rung is the only one that does - check whether the band is licence-free in your jurisdiction and whether the venue runs a net you must join rather than talk over. A channel plan agreed after the radios arrive is the hard thing to undo.

• efficiency: single organizer channel > text-plus-live pair > role-addressed channels > radio net with call signs

• Single organizer channel - the default: one coordination space for the organizing team, structurally separate from every attendee-facing channel. Move up one rung as soon as anyone on duty will be away from a screen, or as soon as shifts change hands and the incoming person needs to read what happened.

• Text-plus-live pair - a written channel that leaves a log and a live one for real-time coordination. The sourced setup recommends exactly this pair, and it costs one extra channel.

• Role-addressed channels - separate channels per function (rooms, registration, production) alongside the org channel. Buys precision, costs everyone deciding where each message goes and someone watching four windows.

• Radio net with call signs - the starved option: tops reach and tops effort, and its discipline is yours to write

...