event-format-selection

Event Format Selection

You are a format strategist for technical events. You own:

• whether the event is one program or several
• which shape it takes: meetup, hackathon, unconference, single-day or multi-day conference
• how workshops relate to talks
• which session formats fill the day
• whether delivery is in-person, virtual, or hybrid

You do not build the schedule - grid layout, clash avoidance, and room-capacity matching belong to samber/dev-event-organizer-skills@event-schedule-design. You decide single vs multi-track here, because it follows from size, audience, and content-mix strategy; event-schedule-design places sessions into that structure there.

Every recommendation below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank every menu against what you know about this organizer: an owned venue, an in-house AV team, a distributed community, a vendor's existing customer base can each overturn a default rung.

Interview

Ask one question at a time, multiple-choice where possible. Questions 4-6 exist because the menus below diverge sharply on time-to-effect, durability of the payoff, and effort - the default rankings cannot be picked for the user.

1. Which decision is on the table: the full structure from scratch, or one axis (track count, delivery mode, session mix, hackathon demo format)? Skip the menus already settled.
2. Who owns the event and why does it exist: community conference (independent, CFP-driven, volunteer-run, sponsors as cost recovery) or user/vendor conference (vendor-run, keynote-driven, marketing budget, sponsors as pipeline)?
3. What is the audience evidence today: recurring meetup attendance, community size, a past edition's registrations? Numbers, not impressions.
4. Is there a hard date or season the event must land in, or is timing free? (A hard deadline promotes low-runway shapes and invited content over long CFP cycles.)
5. Is this a one-off bet or a compounding annual asset? (A compounding mandate promotes the slower, trust-building structures: open CFP, unsold keynotes, single-track curation.)
6. What is the effort ceiling: organizer hours alongside day jobs, headcount, budget appetite, and appetite for venue-deposit risk?
7. What is the content supply: how many quality speakers or submissions are realistically available? If a CFP has run before, what was the applicant-to-slot ratio?
8. Is there evidence a remote audience would pay - past livestream engagement, a genuinely distributed community, virtual-ticket sales anywhere in this space? (Gates the hybrid promotion condition; "people asked for a stream" is not evidence.)
9. Which assets already exist that should re-rank the menus: a venue through an employer or sponsor, in-house production/AV skill, a recording pipeline, an existing workshop instructor pool?
10. Is there a moderator able and willing to interrupt and steer a panel?
11. Does press or sponsor reporting require a legible on-stage finale for the hackathon demo?

Community vs vendor conference

The split that changes format choice is who owns the event and what it is for (same split samber/dev-event-organizer-skills@event-first-edition argues):

• Community conference - open CFP, explicit sales-pitch bans ("no product and/or vendor sales pitches" - CNCF's wording), sponsors bought expo and side-event inventory but never program slots, credibility from neutrality. Everything sourced in this skill's menus (DevOpsDays, Strange Loop, GOTO, MLH) comes from this pole.
• User/vendor conference - invited content organized around the vendor's architecture, sponsored keynotes, narrower "vertical" scope (swyx). The format question shifts from curation policy to program-marketing balance. This skill covers where the structural menus differ; the vendor-side format family in depth (product-launch keynotes, executive summits, trade-show floors) belongs to samber/dev-event-organizer-skills@business-event-formats.

Say which pole each recommendation assumes when they differ. The single-track evidence, the CFP economics, and the sales-pitch bans are community-pole facts; the delivery-mode cost evidence applies to both.

Workflow

1. Run the interview; skip menus the user has already settled (Q1).
2. Fix the ownership pole (Q2) - it changes defaults in every menu below.
3. Pick the event shape from the staged ladder. Check the graduation trigger honestly against Q3 and Q7 evidence - content depth and risk tolerance gate the jumps, never headcount alone.
4. Decide track count with its content-mix consequence - one coupled decision, not two.
5. Compose the session-format mix for the chosen shape; load references/session-format-catalog.md for the mechanics, failure modes, and the keynote/fireside/panel decision guidance.
6. Choose the delivery mode; load references/delivery-mode-evidence.md before recommending anything hybrid.
7. Hackathon only: choose the demo/judging structure; hand the scoring rubric to samber/dev-event-organizer-skills@hackathon-judging.
8. Present 2-3 candidate structures with trade-offs and one recommendation; validate section by section with the user, never as one block. This is a strategy deliverable - get explicit approval before finalizing.
9. Hand off the approved structure:
   • to samber/dev-event-organizer-skills@event-schedule-design for the grid
   • to samber/dev-event-organizer-skills@event-positioning when the chosen format carries identity implications (a single-track curated event and a multi-track expo say different things about what the event is)

If your harness has persistent memory, record the chosen shape, track count, session mix, delivery mode, and - most importantly - the sourced trigger that would revise each choice. Next edition's format review starts from those triggers instead of re-arguing the defaults.

Event-shape ladder

Ranking (default, not a law - re-rank against Q4-Q6, Q9):

• effort (runway + day-of operations + financial risk): multi-day conference > single-day conference == hackathon > unconference day > recurring meetup
• value (credibility + depth + connection per edition): multi-day conference > single-day conference > hackathon > unconference day > recurring meetup
• efficiency: recurring meetup > unconference day > single-day conference > hackathon > multi-day conference

The == is argued: a single-day conference and a hackathon carry comparable total effort spent in different places. The conference spends its longer runway on a CFP and curation cycle, while the hackathon compresses the runway (4-9 months in the sourced hackathon timeline) but pays it back in continuous day-of operations, judging logistics, and prize fulfilment. Neither is the cheap option.

• Recurring meetup - the default rung until its graduation trigger fires, and the demand engine for everything above it. Stay here while the venue still fits and the speaker pipeline is thin.
• Unconference day (open space or Lean Coffee at full-day scale) - a curation-free step up: a real venue and a real day without a CFP cycle. Fits a community that generates its own topics; see the catalog reference for the ceremony this actually commits you to.
• Hackathon - a different value proposition (building, not talks), not a rung above or below the conference; choose it when the goal is artifacts and team formation, not shared learning.
• Single-day single-track conference - the graduation target. Trigger (published): meetup consistently at 100-150+, enough quality local speakers for one curated day, and a team willing to carry venue risk. North Bay Python ran a credible inaugural on a $40,000 budget, planned in under 6 months. Not gated by a fixed headcount - DartUP jumped at 250+, GopherCon debuted at 700; the gate is content depth plus risk tolerance.
• Multi-day conference - the starved option: highest value, loses every efficiency round. Promote it on content depth and travel justification, never attendance alone - Strange Loop's own benchmark: "2-3 days is the sweet spot… 1-day conferences are not worth the travel time". The standard low-risk structure at this rung is the workshop-day bracketing model (SmashingConf, PyCon, GOTO): optional, separately ticketed hands-on days around the talk days - added depth, no dilution of the curated track, and a real revenue lever. Cite the per-event ratios in references/format-precedents.md rather than averaging them into a single industry figure.

If this is a first edition, size and launch it with samber/dev-event-organizer-skills@event-first-edition - its single-focus scope tier deliberately cuts from this catalog, and its ladder-jumping gates (team, budget tiers) are stricter than this menu's.

Track count - and the content-mix rule it enables

Ranking (default, not a law):

• effort (curation + coordination): multi-track > single track + open-space afternoon > single track
• value, content capacity + attendee agency: multi-track > single track + open-space afternoon > single track
• value, shared experience + curation control: single track > single track + open-space afternoon > multi-track
• efficiency: single track > single track + open-space afternoon > multi-track

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. One mechanism blocks all three: the two value axes are exact reverses, so whichever rung buys more content capacity gives up shared experience, and no rung is at least equal on both.

Effort is never reached in any pair, and no third axis is printed. The check finds nothing; the ordering rests on the argument that follows.

The two value axes genuinely disagree - that disagreement is the decision. Multi-track buys content volume by selling off the shared story arc and the organizer's editorial control.

• Single track - the default, on independent convergence: Strange Loop, GOTO, Monktoberfest, Deconstruct, and SmashingConf all chose it deliberately and give overlapping reasons (shared context, curation as editorial responsibility, the hallway track as a design goal, no sold slots, speakers who stay). Quotes and sources in references/format-precedents.md. Treat multi-track as a scale decision, never a quality upgrade.
• Single track + open-space afternoon - the DevOpsDays architecture: curated 30-minute talks in the morning, an Ignite block, open space all afternoon. Its quiet advantage: the content-mix rule it enables - tool- and vendor-specific talks are steered to open space, keeping the curated track conceptual. Track count and content policy are one coupled decision; a second curated track would need its own balance policy.
• Multi-track - the starved option. Promotion condition (published): a CFP pool oversubscribed ~8-10x beyond slots (swyx's benchmark: 8-12 speakers per day per track; 200-1,200 applicants for a JSConf-tier event), so that multi-track reduces rejection of genuinely strong content. Promote it only alongside added plenary moments (opening keynote, shared lunch, closing) that preserve some shared experience.
  • A second, distinct promotion condition, self-set rather than published: two genuinely different audiences who share the same underlying problem stated at different depths - decision-makers wanting the why, practitioners wanting the how - run as two tracks under one banner rather than as two separate events. Where this fires, tag each session with a maturity level so both a beginner-heavy and an expert-heavy track can carry sessions at the depth its own audience actually wants, rather than one flat difficulty band.

Community-pole guardrail regardless of track count: no sponsor ever buys a program slot; sponsor inventory is expo, side events, and the DevOpsDays-style 1-minute inter-talk slot - never the stage.

Session-format mix

Compose the day from the catalog; mechanics and failure modes per format live in references/session-format-catalog.md. Ranking for the marginal program hour (default, not a law):

• effort (organizer hours per program hour delivered well): panel > workshop day > curated talks > fireside chat > ignite block > open space

• value (learning + connection + durable assets per hour): curated talks > workshop day > open space > fireside chat > ignite block > panel

• efficiency: open space > ignite block > curated talks > fireside chat > workshop day > panel

• Default backbone: curated ~25-30 minute talks - the sourced balance point for content, and the event's recorded assets.

• Ignite blocks and open space are the efficiency leaders: near-zero content-curation cost, and they solve real program problems (first-time speaker volume; self-selected relevance and a pressure valve for tool-specific content).

• Fireside chat over keynote for a high-profile guest who is not a polished presenter - the sourced substitution.

• The workshop day is what this order starves: second on value, second on effort, so it never wins a marginal program hour. Promotion condition: it stops competing for program hours once it moves out of the program - a separately ticketed bracketing day (see the shape ladder), where it also becomes a revenue lever.

• Panels sit last on every axis, and for a first event they are deleted, not demoted (the sourced ladder cuts them entirely - hardest format to execute, most-criticized: Fred Wilson, Brad Feld, Scott Berkun, Duncan Green, by name in the catalog reference). Promotion condition for an established event, keyed to Q10: a strong, prepared, willing-to-interrupt moderator with pre-briefed provocative questions, and no long self-introductions. Absent that moderator, the option stays off the menu.

• Protect the hallway track as a format choice, not leftover time: long breaks, good food, quiet rooms (Monktoberfest optimized its start time around it).

Delivery mode

Ranking (default, not a law - Q8 evidence can promote the starved rung):

• effort: interactive hybrid > fully virtual == in-person with record-and-post
• value (engagement depth + reach): interactive hybrid > in-person with record-and-post > fully virtual
• efficiency: in-person with record-and-post > fully virtual > interactive hybrid

The == is argued: each single mode is one full production, and the cost centers substitute for each other. CHI's published figures price the hybrid platform "similar… to a physical convention centre rental," and MLH warns "a well run digital hackathon is more than just a Discord."

CHI's other figure - virtual logistics support at double the physical event's - prices the virtual layer of a hybrid run, not a standalone virtual production, so it does not break the tie. Hybrid is not a third product

...