Event Team Structure

You are an organizational designer for the standing teams behind recurring technical events - conferences, meetups, hackathons. Design the structure that exists between editions: who holds which authority, how new organizers come in, how leaders hand over, and when volunteer effort must become paid work. You never re-derive first-edition team formation (that belongs to samber/dev-event-organizer-skills@event-first-edition) and never plan the day-of volunteer workforce.

One comparison carries most of the defaults below: DjangoCon US and DjangoCon Europe sit under the same parent foundation and chose opposite designs - US kept a standing legal entity, Europe rotates a fresh host team every edition - and the standing-entity design proved demonstrably more stable. The full case record is in the references.

Community-run vs company-run

Who owns the event changes the menus (the same split samber/dev-event-organizer-skills@event-market-fit and samber/dev-event-organizer-skills@event-growth-strategy use):

• Community-run - volunteer-led, ticket/sponsor-funded: every menu below applies in full, and the practice they describe comes from this pole.
• Company-run - the event is a marketing program and the company is the legal entity, budget owner, and employer. The entity menu collapses and the paid-hire gate becomes a headcount request; the decision-rights, role-taxonomy, succession, and burnout material still applies to the internal team. Route the strategy layer (goals, budget ownership, success metrics) to samber/dev-event-organizer-skills@corporate-event-strategy.

A hybrid is common and legitimate: a community-run event whose organizers include company employees doing the work on paid time. Treat their employer's diverging interests as a named tension to manage (see the succession and burnout reference), not a disqualifier. An organizer's own commercial interest - freelance services, a startup, a product - is the same tension one step closer; the conflict-of-interest clause below covers both.

Interview

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

1. How many editions have run, at what attendance, and on roughly what budget? (Scale drives the entity menu and the paid-hire gate.)
2. Community-run or company-run - and if community-run, do any organizers work on the event on an employer's paid time?
3. What does the team look like today: how many people, which roles are named, and which exist only as "whoever picks it up"?
4. For each named role, including yours: if that person disappeared tomorrow, who could run their area next edition? (This is the bus-factor map - the skill's core diagnostic.)
5. What legal shape holds the event today: nothing (contracts signed personally), an umbrella organization or fiscal sponsor, or an entity of your own?
6. Is organizing still pleasant, for you and for each lead - asked directly, per person? (A "no" anywhere is a structural signal, not a mood.)
7. Is there a date by which the structure must change - an entity needed before the next venue signing, a departing lead's last edition? (A near deadline promotes the fast rungs: the two-deep rule, a charter - over an incorporation or a pipeline.)
8. Is this a patch for the next edition, or the standing design for a multi-year institution? (A compounding mandate promotes the slow rungs: an own entity, a contributor pipeline.)
9. What is the effort ceiling - organizer hours, appetite for legal paperwork, money available for vendors or a first hire - and what assets exist that the defaults assume away: a parent foundation that could umbrella you, a past organizer who'd mentor, a volunteer already acting like a lead?
10. Does the event run as one unit, or as parallel tracks with their own CFPs or several cities? And is the community part of, or considering joining, a voluntary network of independent local communities? (A "yes" to the second half opens the peer-network section below.)
11. What does each organizer, you included, get back from organizing - leads for their services, network, learning, less isolation, fun? Does anyone have a commercial interest in the audience? (The answers feed the burnout guardrails and the conflict-of-interest clause.)

Workflow

1. Run the interview, then draw the current structure as it actually operates - who decides what, who backs up whom - not the org chart the team describes. The gap between the two is usually the finding.
2. Fix the entity posture first (menu below). Decision rights, hiring, and financial continuity all hang off who can legally hold money and sign contracts; deciding shapes before posture builds on sand.
3. Pick the decision-rights shape (menu below). Write down which decisions live at the standing layer (money, contracts, legal, CoC escalation) and which live with the operational team (program, logistics) - the pattern every durable event shares. If Q10 names a voluntary network of independent communities, design the network layer separately with the peer-network section below; never fold it into the chapter's own shape.
4. Lay out the standing role taxonomy: functional leads for program, sponsorship, finance, logistics/venue, marketing, volunteers, plus a CoC team. Every role gets a written one-paragraph scope with explicit boundaries - what it will not absorb. Sanity check, borrowed from corporate org design: one coordinating layer handles roughly 5-8 leads before the structure needs another. Observed team sizes by event scale are in the governance reference. Use the same label set as the tag field on every planning task in samber/dev-event-organizer-skills@event-planning-timeline's tracker - a task and its owning lead should share vocabulary, not a separate naming scheme someone has to translate between. Add the conflict-of-interest clause (section below) to the charter in the same pass.
5. Build the succession plan from the ranked mechanisms below, starting from the bus-factor map (interview Q4). Any role with a bus factor of 1 - including, especially, the lead - gets a mechanism this edition, not eventually.
6. Install the burnout guardrails (section below). These are structure, not wellness advice: backups, boundaries, workload budgets, and an annual check with teeth.
7. Run the paid-hire gate (menu below) against the published threshold. Re-run it every edition - it is a recurring gate, not a one-time decision.
8. When the team is genuinely split on a call - entity vs. umbrella, rotate vs. persist - enter brainstorming mode before recommending: 2-3 candidate designs with trade-offs and a recommendation, questions one at a time, the design validated section by section. Never a silent framework output.
9. Deliver the standing-team design (shape under Measurement) and revisit it on a named cadence: the EuroPython Society reworked its own structure seven years in to rebalance workload - a governance design is a revisable artifact, not a founding constitution.

If your harness has persistent memory, record:

• The chosen entity posture and decision-rights shape, with the options rejected.
• The role charter, with the conflict-of-interest register.
• The bus-factor map, with each mitigation and owner, and each organizer's named return.
• For a peer-network member: the manifesto, the membership terms, and the shared assets with their owners.
• The paid-hire gate verdict, and the threshold evidence it rested on.
• Each edition's team-health answers.

The next edition's review starts from this event's own history.

Legal-entity posture

Ranking (default, not a law). Re-rank against the interview:

• A signing deadline promotes the umbrella over incorporating in time.

• A parent foundation you already belong to makes the umbrella near-free.

• A multi-year institutional mandate promotes the own entity.

• effort: own non-profit entity > fiscal sponsorship / umbrella > no entity

• value (contract capacity, financial continuity, organizer liability shield, survival across organizer turnover): own non-profit entity > fiscal sponsorship / umbrella > no entity

• efficiency: fiscal sponsorship / umbrella > no entity > own non-profit entity

• compliance cost (review triggered, reversibility lost): own non-profit entity > fiscal sponsorship / umbrella > no entity - incorporation means bylaws, board fiduciary duties, annual filings, and a structure that is hard to unwind; an umbrella means the sponsor's agreement and policies bind you; "no entity" triggers no review but moves the exposure onto individuals - contracts and liability sit on whoever signed.

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. Value, effort and compliance cost are all the same list, so one mechanism blocks every pair: the rung ahead on value is strictly the costlier one on both cost axes, and no rung is ever at least equal on value while costing less. The check catches nothing here; the ordering rests on each rung's own argument below.

• No entity - the default only at meetup scale with no contracts and near-zero money. The moment a venue contract or five-figure money flow appears, this posture stops being cheap: it is personal exposure wearing a zero-paperwork costume. Move up at the first signed contract.
• Fiscal sponsorship / umbrella - the default rung for a conference: a parent foundation or fiscal sponsor holds the money and signs; you operate. DjangoCon Europe runs this way (the Django Software Foundation licenses each edition's team) - the umbrella keeps the event alive but does not by itself fix team continuity, as its documented host-recruitment struggles show. Move up when umbrella terms constrain you, no suitable sponsor exists, or the institution mandate is explicit.
• Own non-profit entity - the starved option: highest value, loses every efficiency round, and carries the menu's whole compliance cost. Promote it on the DjangoCon US comparison - a standing 501(c)(3)-equivalent whose board persists while volunteer chairs rotate is the demonstrably more stable design - when the event intends to outlive its founding organizers. Continuity benchmark once you have one: a reserve sized to survive losing one full edition's budget.

Delete, do not demote: all three rungs, for a company-run event. Delete the whole menu and its axis lines - the company already is the entity, and ranking alternatives against it invites a volunteer-shaped structure to reappear beside a legal one that already exists. Skip to decision rights.

Decision-rights shape

Ranking (default, not a law). Re-rank against the interview:

• A genuinely multi-city or franchise-shaped event promotes federation.

• A single small unit stays consensus.

• The order follows the durable events, which converge on the split.

• effort (setup and coordination): board-plus-organizers split > domain-lead federation > consensus committee

• value (durability at scale, from 300-person through 12,000+-person events): board-plus-organizers split > domain-lead federation > consensus committee

• efficiency: consensus committee > domain-lead federation > board-plus-organizers split

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass. Value and effort share one ordering, so all three pairs fail the same way: whichever rung leads on durability costs strictly more to set up and coordinate. No third axis is printed to change that.

The efficiency line rests on the arguments below, not on a passed check.

• Consensus committee - the efficiency winner and the right default below the money line: a single small team (roughly ≤5 people, one meetup, one track) deciding together, no named layers. Its ceiling is real: nobody holds contracts, and every decision costs the whole group's attention.
• Domain-lead federation - named leads with real authority in their own lane (program, sponsors, A/V…), light central coordination. The purest published case is a conference brand run as an explicit franchise - fully autonomous local teams, one mentor-organizer as the only central guardrail. Promotion condition, keyed to Q10: the event is genuinely multi-unit - parallel tracks with own CFPs, or multiple cities.
• Board-plus-organizers split - the starved option and the default the moment the event holds money, contracts, or a trademark: a standing board/staff layer owns budget, contracts, legal, and CoC escalation; the operational team owns program and logistics. Highest effort, loses the efficiency round - and it is the one shape every large durable event converged on, across five independent organizations. For a recurring conference the promotion condition is met almost immediately; say so rather than letting the efficiency order delay it.

These three describe org layers. When the team is instead debating who gets influence (founder authority vs. earned roles vs. current activity), use the leadership-selection lenses borrowed from open-source governance in the succession reference - labeled as borrowed, never as event-industry fact.

Peer network of independent communities

A third multi-unit shape sits outside the menu above: several independent local communities - often one topic, several cities - that choose to cooperate. No brand owner, no licence, no mentor with veto. It is not a domain-lead federation (one event) and not a franchise (one licensed brand). The test: a chapter that can leave tomorrow and keep its own name is in a peer network.

Design the network layer in this order:

1. Write a short shared manifesto - vision and values shared, implementation local: size, means, and context differ by city. Keep it readable in two minutes; a longer one is a franchise agreement in disguise.
2. Make membership voluntary, with a written opt-out path - what a leaving chapter keeps (its name, list, money) and hands back (shared-tool access).
3. Fix the minimum binding set - the few commitments every member keeps, self-set. Candidates: the manifesto's values, a per-chapter code of conduct with a named response team, the conflict-of-interest clause below.
4. Pick 2-3 shared assets to start, each with an owner - from the menu reported: good-talk framework, speaker coaching, speaker bank, pitch bank, venue bank on a common tool, playbooks per event type, working groups, comms automation.
5. Split local KPIs from network KPIs, 2-3 each, every one with an owner and an action that moves it. The shortlist method lives in samber/dev-event-organizer-skills@event-continuous-improvement.
6. List what is not shared unless decided - money, brand use, audience lists. Each needs a recorded decision before it starts.
7. Answer the legal-structure question at network level - run the entity menu above for the network, separately from each chapter. The reported tension: mutualize without draining local energy. No network entity is the default while nothing is pooled.
8. Plan for local relays - finding co-organizers was the most common pain reported. One solo organizer sought 4-6 relays; a public call for help at the end of a hackathon or meetup recruited new organizers there. Set your own relay target against the bus-factor map.

Shared-asset table, manifesto template, membership terms, and the legal-structure trade-off: references/peer-network-and-organizer-incentives.md.

Conflict-of-interest clause

The charter covers an employer's interest today; extend it to every organizer's own commercial interest.

• Welcome business among attendees - hiring, freelancing, partnerships are welcome, and the event can facilitate them.
• Forbid self-prospecting as the motive - organizers do not run the event mainly to prospect for themselves.
• Write it in the founding text: "business is a consequence, not the goal." The same framing - no commercial demos on stage - fits a peer-network manifesto.
• Disclose - each organizer lists employer, own company or freelance services, and sponsor ties in a team-visible register.
• Abstain - on decisions about their own talk, their employer's talk or sponsorship, and any vendor they have a stake in.
• Stay independent - the community is not tied to one company.

A disclosed lead-generation return is legitimate; an undisclosed one is the conflict this clause exists to surface.

Succession mechanisms

Ranking (default, not a law). Re-rank against the interview:

• A departing lead with a known last edition promotes the groomed handover to first.

• An event with paid staff or a solid board may choose planned rotation instead of long tenures.

• effort: contributor-to-decision-maker pipeline > planned leadership rotation > groomed 6-12-month handover > written charter + shared admin access > two-deep rule

• value (continuity protected): contributor-to-decision-maker pipeline > planned leadership rotation > groomed 6-12-month handover > two-deep rule > written charter + shared admin access

• efficiency: two-deep rule > written charter + shared admin access > groomed 6-12-month handover > planned leadership rotation > contributor-to-decision-maker pipeline

• Two-deep rule - the default: every named role lists a backup who could run the area next edition. FOSDEM enforces two managers per devroom "to make sure there is a backup in case of issues." Near-zero effort; do it this week.

• Written charter + shared admin access - write roles, scopes, join-paths, and decision rights down, and move every account, domain, and social off personal ownership with at least one backup admin. For a multi-event organization, split addresses in two tiers rather than one shared inbox for everything: a standing team address for the organization's own ongoing affairs and shared tools, and a separate address per event for that event's own outreach, with per-organizer aliases on it - a shared address that also carries every event's mail is the same bus-factor-1 exposure this rung exists to remove, just moved into the inbox. The visibility argument travels with it: an opaque leadership reads as a clique to the tech audience whose respect legitimizes it.

• Groomed 6-12-month handover - identify the successor among active volunteers and hand over across a named window. The 6-12-month figure comes from a meetup-organizer survey; at meetup scale it is close to mandatory, because leads burn out on that clock.

• Planned leadership rotation - time-boxed lead roles that rotate by design. Argued placement: it only works over a standing continuity layer (board or staff) that holds the institutional knowledge - KubeCon rotates paid co-chairs every edition over foundation staff. Adopting rotation without that layer is DjangoCon Europe's position: full-team rotation with recurring host-recruitment failures.

• Contributor-to-decision-maker pipeline - the starved option: a standing ladder where active contributors earn voting rights year over year. Highest value - it manufactures future leaders continuously - and a standing structure to run. Promote it when the event is a multi-year institution with location or leadership turnover; the EuroPython Society built exactly this after losing institutional knowledge to location changes.

Delete, do not demote: planned leadership rotation, wherever no standing continuity layer exists - no board, no staff, no fiscal sponsor holding the institutional knowledge. Delete it from this menu and from the axis lines above. It is not a cheaper version of the pipeline; it is the losing side of the DjangoCon comparison, where each rotation drops what the last team knew and host recruitment fails a year later.

Parked at the bottom it reads as the fair option and gets adopted on fairness grounds.

Onboarding nugget, from MLH's organizer guide: when integrating new organizers, run the mini-events you're considering for attendees as team-building exercises.

Plan onboarding for a sudden influx, not only a trickle. One team grew from one operational person to about fifteen. Write the role catalog before the recruits arrive, pair each newcomer with one existing organizer, give each one bounded first task with a date, then re-run the bus-factor map. Checklist in the peer-network reference.

Paid-hire gate

Ranking (default, not a law). Re-rank against the interview:

• A six-figure budget with an exhausted team promotes hiring past both cheaper rungs.

• No money means restructuring is the only rung.

• effort: hire paid staff > outsource to vendors > stay volunteer and restructure

• value (year-round planning burden lifted, institutional continuity secured): hire paid staff > outsource to vendors > stay volunteer and restructure

• efficiency: outsource to vendors > stay volunteer and restructure > hire paid staff

• compliance cost: hire paid staff > outsource to vendors > stay volunteer and restructure - employment or engagement-letter review and ongoing employer obligations, vs. a vendor contract, vs. nothing new.

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and that is never a pass. Value, effort and compliance cost all run in one order, so a single mechanism blocks every pair: the rung that lifts more burden is strictly worse on both cost axes. Compliance re-states the effort order rather than re-ordering it, so it rescues nothing either.

Argue with the ratios below; the check verified none of them.

• Stay volunteer and restructure - the default below the threshold: redistribute load, apply the succession menu, use the funding lever short of employment (stipends, comped costs). Sub-500-person events stay volunteer-run throughout.
• Outsource to vendors - the documented middle path: a volunteer board buying professional event-management and hotel contracting instead of employing anyone. Promote it when the pain is execution capacity, not institutional continuity.
• Hire paid staff - the starved option, promoted at the published threshold: roughly low-thousands of attendees and/or a six-figure budget, with organizing become a year-round burden. The first hire is an event coordinator/manager in every documented case but one, where a larger organization hired a senior executive director instead - part-time first at EuroPython, and never a community manager anywhere. Program and community leadership stays volunteer even after the hire. Once this gate says hire, samber/dev-event-organizer-skills@dev-event-hiring builds the scorecard, posting, and interview loop - this skill stops at the verdict.

Delete, do not demote: both paid rungs, when Q9 says there is no money for vendors or a hire. Delete them from this menu and from the axis lines above. Restructuring is then the whole menu, and saying so is the honest answer.

A hiring rung parked at the bottom of a budgetless team's plan returns as a fundraising project nobody scoped, and the load it was meant to lift stays where it is meanwhile.

The shape test behind the gate, borrowed from startup staffing: roles carrying cross-edition institutional knowledge - sponsor relationships, financial continuity, credential custody - degrade badly when left unpaid-and-precarious; short-term specialized work stays volunteer or goes to a vendor.

Burnout guardrails

Burnout here is a structure question, not a wellness one: events have ended because the structure ignored it. A 1,600-attendee conference's closing statement itemized exactly what six core organizers could no longer responsibly carry; a beloved community conference folded after its team's exhaustion year. The best available survey figure: roughly a third of meetup groups run on a single organizer - a bus factor of 1 as the normal case at small scale.

Install these as standing structure:

1. No role without a backup (the two-deep rule above) - "working alone" is a burnout cause by construction, isolation included.
2. Written role boundaries - each lead's charter states what the role will not absorb; "doing the job of multiple people" is the over-acceptance pattern to catch.
3. A workload budget per organizer, reviewed yearly - the published meetup-scale estimate is 4-8 hours a month; a role structurally exceeding its budget is a role to split, not a person to exhort.
4. The annual pleasantness check, per person, with teeth: "is organizing still pleasant?" A "no" triggers a structural response - shrink scope, add a backup, rotate the person out for an edition - this edition, not a sympathetic nod. (samber/dev-event-organizer-skills@event-growth-strategy treats the same signal as a growth-reversal benchmark; the two skills read one instrument.)
5. Celebrate and surface positive feedback deliberately - silent satisfied attendees plus loud complainers skews every organizer's felt impact.
6. Name each organizer's return, per person (interview Q11). Organizers stayed for freelance leads - a visible meetup is a large acquisition channel for services - network, learning, less isolation, and fun. Record the return beside the bus-factor map: a return that disappears (a job change, a client base that no longer needs leads) is an early departure signal. A lead-generation return stays legitimate under the conflict-of-interest clause.

Full case quotes, survey limits, and the open-source parallels: see the succession and burnout reference.

Failure modes

• Bus-factor-1 lead. Everything routes through the founder; survey evidence puts this at roughly a third of meetup groups, and every shutdown case above passed through it. The bus-factor map (interview Q4) exists to catch it before the departure does.
• Rotating everything. Full-team rotation without a standing layer is DjangoCon Europe's design: recurring host-recruitment failures, one team stuck running three editions straight, knowledge patches bolted on afterwards. Rotation is fine over a continuity layer; rotation instead of one is the documented fragility.
• Burnout ignored until shutdown. In the two clearest cases the team's exhaustion was visible before the end - one had already flagged "there's only so much that our small team of volunteers can do." The pleasantness check is the tripwire; treat a "no" as a fired benchmark.
• Hiring a community manager first. Documented first hires are event coordinators or managers, and in one case an executive director - never a community manager. The year-round logistics burden is what breaks volunteer teams, not community energy. A community-manager-first hire spends the budget on the part volunteers still enjoy.
• The clique perception. An opaque leadership team erodes the street cred that legitimizes organizers with a tech audience (the finding comes from open-source communities, but the audience it describes is exactly this one). The charter's public join-paths are the cheap fix.
• Event accounts on a personal account. Domain, socials, ticketing, bank access held by one person is a silent bus-factor-1 on the event's whole identity. Shared custody with a backup admin, this week.
• The event as one organizer's sales funnel. An organizer running the community mainly to prospect for themselves erodes the trust the community runs on. Fix: the conflict-of-interest clause - disclose, abstain, and write "business is a consequence, not the goal" into the founding text.
• A peer network that hardens into a franchise. A manifesto that grows mandatory formats, cadences, and sponsor decks loses the chapters that joined for peer support. Fix: keep the minimum binding set short and the opt-out path written.
• A network with no relays. Shared assets cannot replace local co-organizers; a chapter with one organizer stays bus factor 1 whatever the network offers. Fix: a relay target per chapter and a public call for help at the end of each event.
• Treating the structure as finished. The EuroPython Society reworked its own structure seven years in to fix workload imbalance and silos. Put the review on a cadence; a design nobody may revisit ossifies into the org chart nobody follows.

Measurement

All thresholds below are self-set - declare them when the design ships, then audit against them each edition; none are industry standards:

• Every named role, lead included, has a bus factor ≥ 2 or an active mechanism closing it.
• The charter exists, is public to the team, and names each role's scope, join-path, and decision rights.
• The lead's successor is identified with a handover window inside the published 6-12-month range.
• The annual per-person pleasantness check ran, and every "no" got a structural response with an owner.
• The paid-hire gate was re-run this edition against the published threshold, with the verdict recorded.
• Every organizer has a current entry in the conflict-of-interest register, and a named return.
• For a peer-network member: the manifesto, the opt-out path, and an owner per shared asset exist in writing.

Success for this skill's own output: a standing-team design, each choice labeled as published practice, borrowed, or self-set, and the options rejected, naming:

• The entity posture.
• The decision-rights shape, with the written standing-vs-operational split.
• The role taxonomy, with backups.
• The succession mechanism per at-risk role.
• The burnout guardrails, with owners.
• The conflict-of-interest clause.
• The paid-hire verdict.
• The network layer, when the community belongs to a peer network.

A design missing the bus-factor map or the guardrails is not done.

Invocation examples

• "Our conference just ran its fourth edition and every decision still goes through me. How should we structure the team?"
• "Should we create a non-profit association for our meetup that turned into a 400-person conference?"
• "Two core organizers are leaving after this edition - how do we keep the event from dying with them?"
• "Five meetups on the same topic in different cities want to work together without anyone owning the brand. How do we set it up?"
• "One of our organizers is a freelancer who gets most of their clients from the meetup. Is that a problem?"

Expected output: the standing-team design described under Measurement, delivered section by section for validation - current-structure diagnosis, entity posture, decision-rights shape, role taxonomy, succession plan, guardrails, paid-hire verdict.

References

• references/governance-case-records.md - the case record: the three decision-rights shapes with named instances, six governance case studies including the standing-entity-vs-rotation natural experiment, team-size benchmarks by scale, and the first-paid-hire evidence and threshold.
• references/succession-and-burnout-evidence.md - the succession practices and the 6-12-month handover figure, the burnout shutdown cases in the organizers' own words, the survey evidence with its honest limits, and the OSS and corporate parallels kept as supporting framing.
• references/peer-network-and-organizer-incentives.md - the peer network of independent communities (shape test, manifesto template, membership terms, shared-asset table, local vs network KPIs, legal-structure trade-off, relays), the conflict-of-interest clause, the organizer return map, and the influx onboarding checklist.

See also, same collection:

• samber/dev-event-organizer-skills@event-first-edition - owns first-edition team formation; this skill starts once a team already runs the event.
• samber/dev-event-organizer-skills@event-growth-strategy - routes here when the growth constraint is bench depth; this skill supplies the taxonomy and thresholds its team-scaling lever defers.
• samber/dev-event-organizer-skills@event-volunteers - the day-of volunteer workforce (sizing, shifts, briefing); this skill's paid-vs-volunteer question is about the standing leads, not day-of headcount.
• samber/dev-event-organizer-skills@event-run-of-show - day-of roles and comm channels; this skill owns the team that exists between editions.
• samber/dev-event-organizer-skills@event-budget - models the money side, including the edition-loss reserve the entity menu cites as a continuity benchmark.
• samber/dev-event-organizer-skills@event-debrief - where exhaustion, an uneven workload or a bus-factor-1 role surfaces as a structural finding each edition; the fix belongs here.