SKILL.md
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.