SKILL DETAIL
event-growth-strategy
samber/dev-event-organizer-skills/event-growth-strategy
Grow an established technical event edition over edition, or decide not to - the demand-headroom read, one discrete lever per edition (venue squeeze, track or day addition, venue step-up, price-led growth), the contract-risk gate on venue moves (deposits, attrition penalties, F&B minimums, long lead times), the pricing posture before scaling, and deliberate non-growth (caps, lotteries, shrinking back down) as a real strategy. Use whenever asked whether a conference or hackathon should grow, how to scale capacity, whether to add a track, a day or a venue, or how to stay small under excess demand. Do NOT use for a first launch - use samber/dev-event-organizer-skills@event-first-edition - or multi-event portfolios - use samber/dev-event-organizer-skills@event-portfolio-strategy.
Installation
npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-growth-strategy
技能文件
SKILL.md
最近同步 · 2026年10月19日
evals/evals.json›
{
"skill_name": "event-growth-strategy",
"evals": [
{
"id": 1,
"prompt": "I organize VectorConf, a 400-seat conference on embedded ML in Rotterdam. Our first edition took about three weeks to sell out. This year's second edition sold out in 25 minutes and we ended with a 170-person waitlist, plus one sponsor emailed us out of the blue asking about next year. The convention center across town has a 900-seat hall available in 14 months and wants a 40% deposit to lock the date. The whole team is hyped. Can you help us plan the move and figure out what we'd need to make 900 work?",
"expected_output": "A recommendation against signing the 900-seat venue: the demand-headroom gate fails on repetition (edition one sold out in weeks, not minutes), so the next step is a venue squeeze in the current hall, with the financial exposure of the proposed jump spelled out and a warning-sign watch installed.",
"files": [],
"expectations": [
"Recommends against signing the 900-seat venue for the next edition",
"Applies a demand-headroom gate and states its signals must repeat across editions, so a single fast-sellout edition is insufficient evidence",
"Notes the first edition's three-week sellout means the sub-hour sellout has not yet repeated, which is why the gate fails here",
"States the gate's composite threshold: sellout well under an hour, a waitlist around 30-50% of capacity, and unsolicited sponsor inbound, all required together",
"Labels the headroom heuristic a research synthesis rather than a published industry standard",
"Recommends venue squeeze (extracting more capacity from the current venue via layout changes) as the default next rung",
"Notes squeeze headroom is bounded by occupancy or fire-code sign-off",
"Warns that 900 seats sizes to aspiration and that any future step-up must be sized to the proven number plus a modest buffer",
"Names the deposit exposure, typically 25-50% at signing, as part of the financial risk of a venue move committed long before that edition's demand is visible",
"Mentions attrition or food-and-beverage minimum penalties owed even when attendance falls short of the commitment",
"Checks or asks whether the 25-minute sellout was manufactured through batch ticket releases before trusting the signal",
"Recommends exactly one growth lever for the next edition rather than several at once",
"Pairs the recommendation with a warning-sign watch built on the four reversal benchmarks (sellout speed slowing, no-show rate rising, single-sponsor revenue share, organizers reporting the work unpleasant), each with an owner and a check date"
]
},
{
"id": 2,
"prompt": "Our community-run conference LatticeDays (350 attendees, database internals) turns 10 next year. We've sold out three years running, the waitlist hovers around 120, and our anchor sponsor offered an extra 40k EUR if we make the anniversary edition huge. The plan on the table: move to a 1,200-cap venue, add a second track, and bolt on a workshop day, all for edition 10. Can you sanity-check the plan and help us sequence the announcement?",
"expected_output": "A rejection of the combined plan: one discrete lever for edition 10 with the others explicitly rejected, the 350-to-1,200 jump identified as the deleted multi-rung leap, the anniversary-plus-sponsor pressure named as the force that resurrects it, adjacency ordering, the whole-product check, mitigation pairing, and the financial gate.",
"files": [],
"expectations": [
"Rejects running the venue move, track addition, and day addition together in one edition",
"States the rule of one discrete lever per edition",
"Treats the jump from 350 to a 1,200-cap venue as a deleted option removed from the menu entirely, not an option ranked last",
"References the documented case of a roughly 300-person event leaping to a roughly 1,300-person format in one edition and drawing 'does not scale' verdicts from its own community",
"Identifies the anniversary milestone plus the anchor sponsor's 40k EUR as exactly the pressure that quietly resurrects the deleted leap, and resists it",
"Orders growth steps by adjacency, track then day then satellite city, each step small enough that credibility and playbook transfer",
"Applies a whole-product check to any venue step-up: AV, networking infrastructure, and the volunteer bench must scale along with the seats",
"Recommends exactly one lever for edition 10 and names the rejected rungs explicitly",
"Pairs any track or day addition with the documented mitigation of recording everything and protecting unstructured time",
"Names the hallway-track dilution trade-off rather than presenting the chosen lever as free",
"Requires the pricing posture to be decided before scaling, not after",
"Runs the financial risk gate on any venue-touching lever, covering deposits, attrition and food-and-beverage minimum penalties, and the 9-18 month lead time"
]
},
{
"id": 3,
"prompt": "I run SolderSocial with two friends - a hands-on hardware festival. We grew it from 140 to 280 people last year because demand was crazy (sold out in minutes, waitlist over 100). Honestly, the bigger edition was miserable to run; I caught myself dreading the production weekends and my co-organizer half-joked about quitting. Ticket demand is still hot. We're deciding between keeping 280 or pushing to 400 next year. What would you do?",
"expected_output": "A hold-or-shrink recommendation: the organizers' own misery is a fired reversal benchmark that overrides green demand signals, deliberate shrink is presented as a documented legitimate strategy with its budget cost, and the answer routes through the reach-versus-intimacy call into the allocation-mechanism menu rather than a growth lever.",
"files": [],
"expectations": [
"Treats the organizers' dread and the miserable-to-run report as a named reversal benchmark, not a mood to push through",
"Recommends holding at or shrinking below 280 rather than growing to 400, despite the hot demand signals",
"Presents deliberate shrink as a documented, legitimate strategy rather than an admission of failure",
"Notes the documented shrink case accepted roughly a 50% production-budget cut as the price of going back down",
"Notes that in documented cases organizer burnout preceded any financial or operational trigger, making it a leading indicator",
"Forces the reach-versus-intimacy choice explicitly and warns that drifting into a middle size serves neither",
"Presents allocation mechanisms from the non-growth menu: hold the cap, group-purchase ban, application plus lottery, deliberate shrink",
"Names the documented bias of first-come-first-served allocation: it favors those with time and money",
"Recommends application plus lottery specifically when the cap is about who is in the room, not just how many",
"Treats any shrink as a pricing event too, adjusting the price to the smaller product instead of letting the old price ride",
"Does not propose hiring staff or delegating as a way to push growth to 400 through the burnout signal",
"Notes the waitlist doubles as the standing demand instrument while capacity holds"
]
},
{
"id": 4,
"prompt": "PixelForge Days is a free, no-registration community event about open-source game tooling that we run with about 30 volunteers. Last edition roughly 2,500 people showed up, popular rooms were impossible to get into, and the hallways were rammed. Demand clearly keeps growing. We're debating adding a registration system with a hard cap, or finding money to rent a bigger paid venue. Which way should we go?",
"expected_output": "A recommendation to scale through track and room addition, the natural default for a free volunteer-run event where the financial axes collapse, with room-level overcrowding control instead of gate-level caps, the documented cost named, and the portability boundary of this lever ordering stated.",
"files": [],
"expectations": [
"Identifies the event as the free, volunteer-run posture where the financial axes of the growth menu collapse",
"Recommends adding tracks or rooms as the natural default lever for a free event",
"Recommends against introducing registration with a hard cap as the primary fix",
"Cites the documented free event that scaled to 8,000+ visitors and 79 tracks with no registration at all",
"Names the documented cost of that model: chronic room overcrowding, because the capacity problem relocates from the gate to each room",
"Recommends room-level control, staffing the door and using full-room signs, rather than gate-level caps",
"States the free-event lever ordering holds only because there is no ticket revenue and no per-head financial risk, so it does not transfer to a ticketed conference",
"Pairs track addition with the mitigation of recording sessions and protecting unstructured time",
"Names hallway-track dilution as the universal documented trade-off of track addition",
"Asks for or references demand evidence (visitor growth or a demand read) before committing the lever",
"Asks clarifying interview questions one at a time rather than as a single batch"
]
},
{
"id": 5,
"prompt": "TensorTide is our 900-person applied-AI conference, fifth edition coming up. Sellout took 6 weeks two years ago and 10 weeks last year, and attendance slipped from 1,150 at peak to about 900. Most of our early attendees came through our own meetup networks, and those referrals are clearly drying up. The board's plan is to reignite buzz by adding a second track and going for 1,200 next edition. Does that plan hold up?",
"expected_output": "A rejection of the growth push: slowing sellout is a fired reversal benchmark meaning hold or shrink, the ceiling diagnostic identifies channel decay routed to the marketing plan rather than a capacity lever, and the attendance slide is read against the documented market-wide post-pandemic contraction before any per-event diagnosis.",
"files": [],
"expectations": [
"Rejects the board's plan to add a track and target 1,200 next edition",
"Identifies the year-over-year sellout slowdown from 6 weeks to 10 weeks at flat-or-lower attendance as a firing reversal benchmark",
"States that a fired reversal benchmark means hold or shrink the next edition, never push through with growth",
"Runs a ceiling diagnostic distinguishing saturation, channel decay, and quality collapse before discussing any lever",
"Diagnoses the drying-up meetup-network referrals as channel decay rather than audience saturation",
"Routes the channel-decay problem to samber/dev-event-organizer-skills@event-marketing-plan rather than to a capacity lever",
"Reads the attendance decline against the documented market-wide contraction, with independent in-person events running 30-40% below pre-pandemic attendance per a 2023 industry write-up",
"States that the market-wide contraction is not evidence this event mismanaged its growth",
"Routes the soft demand back to samber/dev-event-organizer-skills@event-market-fit for a fresh demand read before any growth work",
"Recommends holding capacity roughly flat, with no growth lever this edition, while the acquisition channels are rebuilt",
"Warns that buying a bigger commitment ahead of proven demand loses money even at attendance that looks respectable"
]
},
{
"id": 6,
"prompt": "OrbitCon (community-run, cloud-native, currently 500 seats) has sold out in under 30 minutes for three straight editions, with waitlists around 200 each time, and two sponsors approached us unprompted this year. We're finally moving to a bigger venue, roughly 700 seats. Our treasurer proposes raising ticket prices 60% since demand obviously supports it and the raise would cover the bigger venue on its own. How should we set up the move and the pricing?",
"expected_output": "The step-up is confirmed as gated-and-passed, but the 60% raise is rejected in favor of the default posture: a public community-price commitment funded by sponsorship cross-subsidy, with supporter tier and early-bird ladder as complements, the sponsor-concentration dependency named with a self-set threshold, the financial gate run, capacity sized to proven demand, and execution handed to the venue-sourcing skill.",
"files": [],
"expectations": [
"Rejects funding the step-up primarily through the 60% ticket-price increase",
"Recommends the default posture of a public community-price commitment: individual prices held, funded by sponsorship cross-subsidy",
"Cites the documented case that held individual prices flat while cutting student tickets around 40% across five years of venue growth",
"States the pricing posture must be decided before the scaling, not after",
"Presents a supporter-tier cross-subsidy, a premium tier whose surplus funds other attendees' access, as distinct from a VIP upsell",
"Presents early-bird laddering, dated or volume-gated tiers, as complementary to the community-price commitment rather than an alternative",
"Names the dependency the public commitment creates: it is only as durable as the sponsor base funding it, so the sponsor-concentration watch matters more once it is public",
"Sets a self-set single-sponsor revenue-share threshold declared before the growth push as a reversal benchmark",
"Routes exact price-setting mechanics to samber/dev-event-organizer-skills@event-ticket-pricing",
"Confirms the demand gate passes here on repeated sub-hour sellouts, a waitlist around 40% of capacity, and unsolicited sponsor inbound",
"Runs the financial risk gate on the venue move: deposits typically 25-50% at signing, attrition and food-and-beverage minimum penalties, 9-18 month lead time, and post-pandemic venues rarely renegotiating",
"Sizes the new capacity to the proven number plus a modest buffer rather than an aspirational one",
"Hands venue search and negotiation execution to samber/dev-event-organizer-skills@event-venue-sourcing"
]
},
{
"id": 7,
"prompt": "A growth advisor pitched us this for KernelFest, our 600-person systems conference: release tickets in eight small weekly batches so each drop sells out in minutes, screenshot the sellouts for social proof, then use the sold-out-eight-times story to justify booking a 1,000-seat venue next year. It sounds clever and costs nothing. Should we run it, and how would we structure the batches?",
"expected_output": "A refusal: batch drops engineered for sellout optics are deleted from the menu because manufactured scarcity corrupts sellout speed, the very signal the growth gate reads, so batch-sellout screenshots cannot justify a venue step-up; the genuine headroom gate and honest demand instruments are laid out instead, with volume-gated early-bird tiers distinguished as a legitimate pricing mechanism.",
"files": [],
"expectations": [
"Refuses to run the batch-release plan",
"States that ticket drops engineered to manufacture sellout optics are deleted from the menu entirely, not merely discouraged",
"Explains the reason: manufactured scarcity corrupts sellout speed, the exact demand signal the growth gate reads",
"Refuses to use batch-drop sellout evidence to justify booking the 1,000-seat venue",
"Requires the genuine headroom gate instead: organic sellout well under an hour, a waitlist around 30-50% of capacity, and unsolicited sponsor inbound, repeated across editions",
"Distinguishes legitimate volume-gated early-bird tiers, a pricing mechanism such as a first-N-tickets tier, from batching engineered for sellout optics",
"Notes that any event's historical sellout speed must be checked for batch manufacturing before the signal is believed",
"Points to the waitlist as the honest standing demand instrument instead of manufactured drops"
]
},
{
"id": 8,
"prompt": "Our API-infrastructure company runs MeshWorks Summit, a 600-person user conference with tickets at 99 USD. Finance flagged that the event loses about 180k USD a year against ticket revenue and says growing it just deepens the loss, so they want it capped or cut. Our DevRel lead says demand is the strongest it has ever been: sold out early, big waitlist, customers asking for more seats. How should we decide whether the summit grows next year?",
"expected_output": "A company-run analysis: growth judged on pipeline and adoption outcomes rather than ticket revenue, the ticket-revenue shortfall declined as the deciding metric, the substitutions flagged as judgment calls, sponsor-concentration risk translated into budget-owner risk, venue-contract exposure kept in full, and the standard gates (repeated demand evidence, one lever, declared watch) still applied.",
"files": [],
"expectations": [
"Identifies MeshWorks Summit as company-run and applies the company-run substitutions to the financial axes",
"Judges the growth decision on pipeline and adoption outcomes, not ticket revenue",
"Declines to treat the 180k USD ticket-revenue shortfall as, by itself, the growth-blocking metric",
"Flags the company-run substitutions as judgment calls rather than established event-industry practice",
"Translates sponsor-concentration risk into budget-owner risk: the budget owner changing their mind",
"States the venue-contract exposure still applies in full despite the funding model, covering deposits, attrition and food-and-beverage minimums, and lead time",
"Still requires the demand-headroom evidence, repeated fast sellouts with a waitlist share and inbound interest, before choosing a lever",
"Recommends exactly one discrete lever for the next edition if growth is chosen",
"Installs the warning-sign watch with trigger values declared before the sale opens"
]
}
],
"trigger_queries": [
{ "query": "Our conference sold out in 15 minutes with a 300-person waitlist - should we book a venue twice the size?", "should_trigger": true },
{ "query": "Should our established conference add a second track next year?", "should_trigger": true },
{ "query": "We've run three editions of our developer conference. How do we decide whether year four should be bigger?", "should_trigger": true },
{ "query": "Demand for our annual hackathon keeps growing but we like it small. Can staying small be a real strategy?", "should_trigger": true },
{ "query": "Is it a mistake to double our event's capacity in one year?", "should_trigger": true },
{ "query": "Our community conference outgrew its venue. What are our options besides moving?", "should_trigger": true },
{ "query": "How risky is signing a much bigger venue for next year's edition?", "should_trigger": true },
{ "query": "We want to add a workshops day to our conference - what does that actually cost us beyond money?", "should_trigger": true },
{ "query": "Attendees keep asking us to bring our conference to a second city. When does that make sense?", "should_trigger": true },
{ "query": "Our tickets sell out instantly every year. How do we know if we should expand?", "should_trigger": true },
{ "query": "The team is exhausted but the event keeps selling out. Do we have to keep growing?", "should_trigger": true },
{ "query": "What's the smartest way to grow a 200-person tech conference to 400?", "should_trigger": true },
{ "query": "Should we cap attendance at our developer festival or let it keep growing?", "should_trigger": true },
{ "query": "We're thinking of running a ticket lottery instead of first-come-first-served for our capped event. Good idea?", "should_trigger": true },
{ "query": "Our conference got too big and lost its soul. Can we shrink it back down?", "should_trigger": true },
{ "query": "How much bigger can we safely go next edition?", "should_trigger": true },
{ "query": "waitlist is huge again this year, time for a bigger room?", "should_trigger": true },
{ "query": "Our anchor sponsor wants us to double the event for their anniversary. Should we?", "should_trigger": true },
{ "query": "When should an established conference add parallel tracks versus an extra day?", "should_trigger": true },
{ "query": "We fit 450 people in our hall last year - can we squeeze more in without moving venues?", "should_trigger": true },
{ "query": "Is one sold-out edition enough evidence to book a venue twice the size?", "should_trigger": true },
{ "query": "How do we grow the event without pricing out the community that built it?", "should_trigger": true },
{ "query": "Free community event, no tickets, rooms are overflowing - how do we scale it?", "should_trigger": true },
{ "query": "Should we keep our event at 150 people even though we could sell 300 tickets?", "should_trigger": true },
{ "query": "Our conference attendance dropped from 1,200 to 800 - did we grow too fast?", "should_trigger": true },
{ "query": "Planning next year's edition: same size, bigger, or smaller?", "should_trigger": true },
{ "query": "What signals tell us our event has real headroom to grow?", "should_trigger": true },
{ "query": "We're debating banning group ticket purchases at our capped event. Thoughts?", "should_trigger": true },
{ "query": "The organizing committee can't agree whether to stay single-track. Help us decide.", "should_trigger": true },
{ "query": "Next edition we could do a bigger venue OR a second track OR an extra day - which one first?", "should_trigger": true },
{ "query": "Do slimmer chairs and a tighter room layout count as a real growth strategy?", "should_trigger": true },
{ "query": "How do I know if my annual conference is ready for a second day?", "should_trigger": true },
{ "query": "Our event has sold out in under an hour three years running - what now?", "should_trigger": true },
{ "query": "Scaling our conference to twice the size: what could go wrong financially?", "should_trigger": true },
{ "query": "Should demand or venue availability drive our capacity decision next year?", "should_trigger": true },
{ "query": "The last edition felt too crowded but the waitlist is still 200 deep. What do we do?", "should_trigger": true },
{ "query": "We doubled last year and regret it. How do we walk it back without looking like a failure?", "should_trigger": true },
{ "query": "Growth plan for edition five of our infrastructure conference - where do we start?", "should_trigger": true },
{ "query": "Attendance keeps climbing - when do we say no to more growth?", "should_trigger": true },
{ "query": "Is it crazy to deliberately shrink a sold-out conference?", "should_trigger": true },
{ "query": "We're launching our first developer conference next spring - how many tickets should we plan for?", "should_trigger": false },
{ "query": "How do I figure out whether there's real demand for a Rust conference in my city before announcing it?", "should_trigger": false },
{ "query": "What should we charge for early-bird versus standard tickets?", "should_trigger": false },
{ "query": "Help me negotiate the venue contract terms for next year's conference.", "should_trigger": false },
{ "query": "Build me a 12-month planning timeline for our 500-person conference.", "should_trigger": false },
{ "query": "We run a conference and a podcast - should we add a hackathon to the portfolio?", "should_trigger": false },
{ "query": "Single-track or multi-track for the brand-new conference we're designing from scratch?", "should_trigger": false },
{ "query": "What overbooking ratio should we use to absorb no-shows at our free meetup?", "should_trigger": false },
{ "query": "How do we promote our conference to sell the tickets we already have?", "should_trigger": false },
{ "query": "Our waitlist process is a mess - how should day-of waitlist promotions work?", "should_trigger": false },
{ "query": "How should we structure the standing volunteer team for our recurring conference?", "should_trigger": false },
{ "query": "What's the ROI case for our company running a user conference at all?", "should_trigger": false },
{ "query": "User conference versus multi-city roadshow - which format fits our devtools startup?", "should_trigger": false },
{ "query": "How do we price our sponsorship tiers for next year?", "should_trigger": false },
{ "query": "Draft the sponsorship prospectus for our 800-person conference.", "should_trigger": false },
{ "query": "How do we keep our conference's Discord active between editions?", "should_trigger": false },
{ "query": "Growth strategy for my B2B SaaS - we're at $40k MRR and stalling.", "should_trigger": false },
{ "query": "How do I grow my tech newsletter from 2,000 to 10,000 subscribers?", "should_trigger": false },
{ "query": "Our monthly meetup needs more members - how do we grow attendance month over month?", "should_trigger": false },
{ "query": "Set up a ticket-swap promotion with a conference in the neighboring city.", "should_trigger": false },
{ "query": "How do we measure whether last edition met attendee expectations?", "should_trigger": false },
{ "query": "Run a retrospective on what went wrong at this year's edition.", "should_trigger": false },
{ "query": "Which cities should our company's first developer roadshow hit?", "should_trigger": false },
{ "query": "How big should the prize pool be for our hackathon?", "should_trigger": false },
{ "query": "We've decided to move venues - find and shortlist options for 1,000 people.", "should_trigger": false },
{ "query": "What's a reasonable catering budget per attendee for a two-day conference?", "should_trigger": false },
{ "query": "How do I reposition our conference now that a big competitor event launched?", "should_trigger": false },
{ "query": "Should our conference add a livestream so remote folks can attend too?", "should_trigger": false },
{ "query": "Write the CFP text for our new two-track program.", "should_trigger": false },
{ "query": "How many parallel sessions can our schedule grid fit across three rooms?", "should_trigger": false },
{ "query": "I organize conferences for a living - how do I level up to a senior producer role?", "should_trigger": false },
{ "query": "We want to license our conference brand to independent organizers in other countries - what should the license require?", "should_trigger": false },
{ "query": "Estimate the market size for developer conferences in Southeast Asia.", "should_trigger": false },
{ "query": "Mid-sale ticket numbers look soft this year - is the edition still viable?", "should_trigger": false },
{ "query": "What conversion rate should our event landing page be hitting?", "should_trigger": false },
{ "query": "How do we grow our open-source project's contributor base?", "should_trigger": false },
{ "query": "Should our team spin up a second annual conference on a sister topic?", "should_trigger": false },
{ "query": "What should go in the sponsor renewal deck after this year's edition?", "should_trigger": false },
{ "query": "Pick the best week next year to hold our conference.", "should_trigger": false },
{ "query": "How do we handle refunds for attendees who can't make it anymore?", "should_trigger": false }
]
}
references/growth-case-studies.md›
# Growth case studies
The case record behind the skill's levers, caps, and failure modes. Every figure below comes from organizer statements, event sites, or contemporary press unless flagged otherwise. Three figures are contested between credible sources - report those as ranges, never pick one silently (see the last section).
## GopherCon - venue step-up triggered by visible over-demand, then a track and a day
- 2014 debut (Denver, Marriott): the team "had to change our room layout twice and negotiate with the Marriott twice to get bigger space because we had more demand for tickets than we had space for people" (Gopher Academy blog, 2016). The step-up trigger arrived as real-time, in-event overflow, not a projection.
- 2015: moved to the Colorado Convention Center, "effectively doubling our capacity" - one discrete step, not incremental growth.
- 2016: added two parallel afternoon tutorial tracks, pre-empting the fragmentation critique in the CFP announcement itself: "Everything will be recorded and available after the conference, so while it's impossible to be in three places at once, you won't miss out." This was the named mitigation for hallway-track dilution.
- 2019 (San Diego, 1,800+): deliberately chose a single venue "offering both rooming and programming under one roof" specifically "to maintain the tight sense of community" - a counter-example to "bigger requires a sprawling campus." Also added a fourth day (Community Day).
- 2024 (Chicago): "over 800 attendees" - a material drop from the ~1,800 peak. Flag: the figure comes from a sponsor recap, not an organizer post-mortem. Treat it as indicative, and read it against the market-wide post-pandemic contraction, not as a growth mistake.
- Pricing ladder: Early / Standard / Late tiers, group discounts (5% for 5-9, 10% for 10+) on standard tickets only.
## Rails World - capacity doubling plus track addition in one edition, then the squeeze
- 2023 (Amsterdam): single-stream, sold out "in less than 45 minutes" (DHH). Attendance is a contested figure - see the last section.
- 2024 (Toronto): "more than 1,000 Rails developers from 57 countries," two days, two tracks. DHH: "we are going to nearly double the capacity for attendance." Venue, sponsorships, and CFP were announced ~9 months ahead, the practical lead-time floor in action - compressing GopherCon's two-edition pattern (venue move, then tracks) into one edition.
- 2025: rather than sign a third, larger venue, returned to the Amsterdam venue. DHH: "The venue we returned to was already at capacity the first time around, but Amanda managed to fit a third more attendees by literally using slimmer chairs!" - the clearest documented venue-squeeze case, and the skill's default rung.
## RailsConf - a governance ending, not a growth failure
- Grew to six tracks over three days by 2014-15 ("Three days and six tracks, that was huge!" - Evil Martians recap). It ran a premium "Supporter Ticket" tier explicitly funding its Scholars and Guides accessibility programs.
- The 2022 rupture (DHH's "No RailsConf" post after losing the standing opening keynote) and the 2025 final edition were governance and politics, in the organizers' own accounts. The Rails Foundation launched Rails World as successor, and DHH framed it as "the baton has been passed."
- Flag: never cite RailsConf's ending as a grew-too-big case. It is the skill's canonical example of a governance ending misread as a growth failure.
## FOSDEM - track-based free scaling, the third posture
- Free, no registration, all-volunteer (LWN.net 2025: "None of the organizers are paid"). Visitors grew from ~4,000 (2011) to 8,000+ (since 2017). The 2025 edition ran "over 1,100 events and 79 tracks."
- Scales almost entirely by adding devrooms/tracks - never by capping attendance. Room-level control instead: "If there is risk of overcrowding, place somebody at the door and use the full signs" (Devroom Managers Manual).
- The documented cost: recurring attendee reports of queues and "overcrowded rooms often impossible to enter." No free-entry model escapes overcrowding. It relocates the capacity problem from the gate to each room.
- Portability warning: this lever ordering only works because there is no ticket revenue and no per-head financial risk - it does not transfer to a ticketed conference where the venue contract and per-head math are load-bearing.
## PyCon US - the accessible-pricing scaling commitment
- Organizers' own words (2016): "we have kept our Individual and Corporate prices stable as the conference has moved into larger and more expensive venues, but we have slashed our Student ticket prices by more than 40% over five years!"
- Mechanism:
- Sponsorship cross-subsidizes registration.
- A needs-based financial aid program (average grant ~$700 in 2017).
- Early-bird gated by volume ("the first 800 tickets"), not date.
- Scaled to ~2,400-3,000 total attendees across a dozen venue moves with a foundation staff of 8 - the strongest documented counter-example to "scaling forces price increases," and the reason a public community-price commitment is this skill's recommended default posture.
## XOXO - grew, tried double, deliberately shrank
- Passes sold, year over year:
- 2012: 400 passes, sold out in ~50 hours.
- 2013: ~700, with an application process filtering commercial intent.
- 2015: capped ~1,000.
- 2018: ~2,300, the deliberately large "experiment" ("double the size" - organizer Andy Baio).
- 2019: reversed. Organizer McMillan named three reasons (Fast Company):
- The giant venue "felt isolated."
- "2,300 people is too many for a festival billing itself as a place for creatives to forge meaningful relationships."
- Administering it felt "actively unpleasant."
They accepted "roughly a 50% reduction in our production budget" as the price. Baio on the smaller edition: "It was the most relaxed and most fun I've had in seven years running the event."
- Allocation: application + lottery, explicitly "to counter" the bias where "a first-come, first-serve system typically favors those with time and money," prioritizing underrepresented attendees.
- The 2024 finale: cap at 1,000, pass price cut from $500 to $250 by shortening the program, after the sponsorship that had funded ~20% free passes receded - "The tech companies... stopped spending money on independent events like XOXO" (OPB). Sponsor concentration ended the event while attendee signals stayed warm.
## Monktoberfest - cap for damage control, kept for quality
- First edition (2011) capped at 100 "as damage control… a small disaster would be preferable to a large one" (organizer Stephen O'Grady). Today ~150: he "could sell twice as many tickets as he does" but keeps it small for intimacy - the same cap, reframed from risk hedge to quality choice.
- Group-purchase ban as allocation: "It made it much less likely that large groups of attendees… would form cliques."
- A category of constraint worth naming: some signature elements are physically unscalable (the brewery "just don't brew enough" of the event's signature beer for 300-400) - an argument for a cap independent of venue, money, or bandwidth.
## Brooklyn Beta - the single-edition leap, the deleted option
- Attendee counts by edition:
- 2010: ~150-200.
- 2011-12: ~300, sold out.
- 2013: the usual 300-person conference _plus_ a one-day ~1,300-person event in "an amazing (but very expensive) venue" (founder Chris Shiflett, flagging cost and strain in real time: "we had more hiccups than in previous years").
- Community verdict, documented: "I'm just not sure it scales well from 300 to 1300" and "the acoustics in the hangar-like space battled against the speakers" (Jeremy Keith) - a venue-fit failure at the leapt-to scale.
- The loop, in an organizer's words: "Being small is a big part of what made the conference so intimate and amazing, and being so intimate and amazing was what made the conference so popular… in 2013 they made the decision to break it wide open."
- Flag: the 2014 ending was a deliberate wind-down (the founding "fight" framed as won, plus organizer life changes) - nothing indicates insolvency or sponsor pullback. Cite this case for the format-leap-breaks-intimacy failure mode only, never as a financial collapse.
## GigaOm - the cash-flow cautionary tale, not an event-growth case
- A company-level insolvency (March 2015) with events as a major revenue line: it "didn't even have enough money to pay vendors helping to put on its Structure Data conference," cancelled nine days before doors.
- Flag: this is corporate overextension, not one event outgrowing itself. Use it only to illustrate that venue and vendor commitments turn a cash-flow failure into a nine-days-out cancellation - nothing else transfers.
## Web Summit - the outlier upper bound
- Dublin years under one founding team:
- 2010: ~400.
- 2012: 4,200.
- 2014: 22,000, the year of the notorious Wi-Fi failures.
- 2015: ~42,000, then relocation to Lisbon after exceeding any Irish venue, a compound trigger of national venue ceiling, infrastructure strain, and government-support disputes.
- Founder Paddy Cosgrave: "We tried with a small team in 2010 but had no idea we would have had 42,000 attendees come to Dublin in 2015."
- Flag: this ~100x-in-five-years rate rode a broad general-tech topic, and it is the record's upper bound, not a benchmark. The documented normal for niche developer conferences is roughly doubling per discrete step. The base year itself is contested - see below.
## Contested figures - always report the range
Three conflicts exist where credible sources disagree, with no reconciliation available. Never collapse them into one number.
- **XOXO 2019 size**: "capped at 750" (Wikipedia) vs. ~1,200 (Fast Company) for the same year. Cite as "roughly 750-1,200, sources disagree."
- **Rails World 2023 attendance**: "700+ Rails developers" (rubyonrails.org) vs. DHH's "700 tickets in less than 40 minutes" and, elsewhere, "the lucky 650 attendees." Possibly tickets-sold vs. show-ups, but unreconciled. Cite as "roughly 650-700+."
- **Web Summit's first year**: 2010 (~400 attendees) is the usual starting point, but some sources cite a ~150-person 2009 precursor. Any growth multiple ("~100x") shifts with the disputed base year - say so when citing it.
references/venue-and-money-mechanics.md›
# Venue and money mechanics
The financial risk layer under every growth decision, the demand-headroom heuristic and the cases behind it, the three pricing-evolution mechanisms, and the two warning patterns that fire before the money does.
## Venue contract risk mechanics
- Deposits typically run 25-50% at signing, balance due 14-30 days out.
- Hotel room-block **attrition penalties** and **food-and-beverage minimums** are the core exposure: the organizer owes the shortfall even when attendance lands below the committed block or minimum. An over-built edition can lose money at an attendance number that looks respectable.
- Lead time: conferences of 300+ attendees are typically booked 9-18 months ahead. A venue step-up decision therefore has to be made a year or more before the bigger edition runs - long before that edition's own demand is visible.
- Post-pandemic tightening: venues have become "frequently unwilling" to renegotiate minimums - the older case studies operated in a more forgiving contract environment than today's.
- Downside caps to negotiate when a step-up is promoted:
- The smallest deposit and shortest attrition/minimum commitments available.
- Venues run by nonprofits or with flexible room blocks.
- Capacity sized to the proven number plus a modest buffer, never the aspirational one.
## The demand-headroom heuristic
Across every documented step-up case, organizers did not grow into projected demand. They waited for demand to visibly exceed supply, then took one discrete step. The observed signals:
- Sellout speed (sub-hour sellouts).
- Real-time in-event overflow (twice-renegotiated room layouts).
- Waitlists.
- Unsolicited sponsor inbound.
The skill's gate applies a composite threshold, a starting heuristic and not a published industry standard. It requires all of the following, repeated across editions:
- Sellout well under an hour.
- A waitlist around 30-50% of capacity.
- Unsolicited sponsor interest.
No "sell out in X weeks or don't grow" rule exists in the literature. The event's own history (via `samber/dev-event-organizer-skills@event-market-fit`'s pace instruments) beats it as soon as two editions of data exist.
The repetition requirement is the load-bearing part: one viral year misleads, and sellout speed itself is manufacturable through batch releases - check for batching before believing it.
## Pricing evolution across editions - three complementary mechanisms
Decide the posture before scaling, publicly, so growth doesn't quietly price out the base that built the event. The three mechanisms combine, and the strongest cases run at least two:
1. **Early-bird laddering** - dated tiers (Early / Standard / Late) or volume-gated tiers ("the first 800 tickets"), with group discounts confined to the standard tier. It manages the sales curve, but does not by itself protect accessibility.
2. **Supporter tier cross-subsidy** - a premium tier "priced at a premium to help fund" scholarships and accessibility programs. Distinct from a VIP upsell: the surplus is spent on other attendees, and saying so is part of the tier's value.
3. **Public community-price commitment** - the recommended default: hold individual prices flat (or cut student prices) across venue step-ups, funded by sponsorship cross-subsidy. One event held prices stable through five years of larger, costlier venues while cutting student tickets 40%. Note the dependency this creates: the commitment is only as durable as the sponsor base funding it, exactly why the sponsor-concentration watch below matters more once this posture is public.
Pricing can also move deliberately _down_ when shrinking: a case where organizers halved the pass price by shortening the program, framed as "a fair compromise." Shrinking is a pricing event too - plan it, don't let the old price ride on a smaller product.
## Warning patterns that fire before the money does
**Sponsor concentration** - sponsorship is usually the revenue majority for independent developer events, and tickets are "almost always priced at less than the actual cost." Sponsors budget a year ahead, so a single sponsor's withdrawal hits a growth budget with no time to replace the revenue before the edition runs. One event lost the sponsorship that had funded a fifth of its passes while attendee enthusiasm stayed high.
The threshold ("no single sponsor above X% of revenue") is self-set: declare it before the growth push. Treat crossing it as a reversal benchmark even mid-success.
**Organizer burnout as a leading indicator** - in two independent cases, the organizing team's own stress preceded any financial or operational trigger. One shrank a doubled event after administering it felt "actively unpleasant," and one wound down after organizer life changes.
A small team hits its human ceiling before its financial one. Treat a bandwidth or "no longer fun" report as a legitimate, named input to the hold/shrink decision, not a soft complaint to override with green demand numbers.
**Market-wide contraction context** - as of a 2023 industry write-up, the average independent in-person event still ran 30-40% below pre-pandemic attendance (virtual down a similar amount from its peaks). Read a single event's plateau against this baseline before diagnosing a demand ceiling: market context is not a per-event failure signal, and growth-rate expectations calibrated on pre-2020 cases need tempering.
SKILL.md›
---
name: event-growth-strategy
description: Grow an established technical event edition over edition, or decide not to - the demand-headroom read, one discrete lever per edition (venue squeeze, track or day addition, venue step-up, price-led growth), the contract-risk gate on venue moves (deposits, attrition penalties, F&B minimums, long lead times), the pricing posture before scaling, and deliberate non-growth (caps, lotteries, shrinking back down) as a real strategy. Use whenever asked whether a conference or hackathon should grow, how to scale capacity, whether to add a track, a day or a venue, or how to stay small under excess demand. Do NOT use for a first launch - use samber/dev-event-organizer-skills@event-first-edition - or multi-event portfolios - use samber/dev-event-organizer-skills@event-portfolio-strategy.
license: MIT
metadata:
author: Samuel Berthe
version: "1.1.0"
---
# Event Growth Strategy
You are a growth strategist for established technical events. Decide whether the next edition should be bigger, the same size, or smaller, and through which single lever, for an event that has already run at least one edition.
You consume a demand read from `samber/dev-event-organizer-skills@event-market-fit`. You never rebuild its signals, and you never plan a first launch.
Scope edge, stated up front: growing by opening a satellite city with the _same_ organizing team is the far end of this skill's lever ladder, gated on saturating the current city first.
The decentralized franchise model is out of scope:
- A brand licenses independently-run city editions, the model one community event used to grow from one city in 2009 to 80+ documented editions.
- It is not owned by `samber/dev-event-organizer-skills@event-portfolio-strategy` either, since that skill covers one team running multiple formats.
Route it out when a user asks for it. Do not absorb it:
- Growing by voluntary cooperation with independent local communities - a shared manifesto, no licensed brand - goes to the peer-network section of `samber/dev-event-organizer-skills@event-team-structure`.
- The brand-licensing half (recruiting, vetting and enforcing standards on teams you do not run) remains an open edge no skill covers yet.
## Interview
Ask one question at a time, multiple-choice where possible. Questions 6-8 exist because the menus below diverge sharply on time-to-effect, durability, and effort - the default rankings cannot be picked for the user.
1. How many editions have run, at what capacity, and what did the last edition actually do - sellout time, attendance vs. tickets sold, waitlist size?
2. Community-run or company-run? (Changes which financial axes even apply - see the split below.)
3. What does the latest demand read say - the composite from `samber/dev-event-organizer-skills@event-market-fit` (attendee return, sponsor renewal, sellout-speed trend), or at least the raw signals? If no read exists, route there before continuing.
4. What is the event's core value: hallway-track intimacy (everyone in one room) or program reach (breadth, parallel choice)? (This decides which menu you are even in.)
5. What is the venue situation: known headroom in the current venue, contract renewal date, lead time to the next edition?
6. Is there a date by which the growth call must land (venue signing deadline, sponsor budget cycle)? (A near deadline promotes the fast levers - squeeze, pricing - over a venue move.)
7. Is the next edition a one-off bigger bet, or one step in a compounding annual asset? (A compounding mandate promotes slow, durable levers and stricter demand gates; a one-off tolerates neither the step-up's lead time nor its contract exposure.)
8. What is the effort ceiling: organizer hours, volunteer bench depth, financial risk appetite - and, asked directly, is organizing this event still pleasant? (A "no" is a growth signal in its own right - see Measurement.)
9. What assets already exist that the default ranking assumes away - a trusted venue relationship with room to grow, a standing waitlist, a deep sponsor bench, a second-city community already asking?
10. Does the capacity cap exist to shape who is in the room, or only how many?
## Community-run vs company-run
What changes the menus is who owns the event (same split `samber/dev-event-organizer-skills@event-market-fit` and `samber/dev-event-organizer-skills@event-first-edition` use):
- **Community-run** - ticketed or donation-funded, external sponsors, volunteer-heavy: every financial axis below applies in full, and all the documented evidence in this skill comes from this pole.
- **Company-run** - funded by a marketing budget, with the vendor as its own main sponsor. The venue-contract exposure is real, but the revenue math changes: you judge growth on pipeline and adoption outcomes, not ticket revenue, and sponsor-concentration risk collapses into "the budget owner changes their mind." These substitutions are judgment calls rather than established event-industry practice - flag them when used.
A free, volunteer-run community event is a third posture worth naming. With no ticket revenue and no per-head financial risk, the financial axes collapse, and track addition becomes the natural default lever. One documented event scaled this way to 8,000+ visitors and 79 tracks with no registration at all, at the documented cost of chronic room overcrowding.
## Workflow
1. Run the interview. Require a demand read (Q3): this skill starts where `samber/dev-event-organizer-skills@event-market-fit`'s go call ends. On a hold, pivot, or stop read, stop here - growth work on a red read is growing into empty space.
2. Gate on repeated demand, not one viral year. The headroom heuristic is a research synthesis, not an industry standard - say so when you apply it. It requires all of the following, repeated across editions:
- Sellout well under an hour.
- A waitlist of roughly 30-50% of capacity.
- Unsolicited sponsor inbound.
3. Diagnose which ceiling is actually near before picking a lever, borrowing from network-growth theory rather than event-industry practice:
- **Saturation** - the local audience or sponsor pool for this topic is tapped.
- **Channel decay** - the personal networks that filled early editions are producing less. This routes to `samber/dev-event-organizer-skills@event-marketing-plan`, not to a capacity lever.
- **Quality collapse** - a bigger edition already degraded what attendees valued. This argues against growth even when demand looks green.
4. Force the reach-vs-intimacy choice explicitly (Q4):
- Reach routes to the growth levers menu.
- Intimacy routes to the deliberate non-growth menu.
The documented failure is drifting into a middle size that serves neither. The choice is the deliverable, not a formality.
5. When the choice is genuinely open or contested inside the team, enter brainstorming mode before recommending:
- 2-3 candidate growth paths with trade-offs and a recommendation.
- Questions asked one at a time.
- The plan validated section by section, never a silent framework output.
6. Pick **one** lever from the growth menu for the next edition - one discrete step per edition. Order steps by adjacency, borrowed from segment-expansion strategy: track → day → satellite city, each step small enough that credibility and playbook transfer. Jumping several rungs in one edition is the deleted option below.
For any step-up, check the whole-product layer, also borrowed from that strategy. A bigger venue with the same production scales the chairs but not the event: no upgraded AV, networking infrastructure, or volunteer bench. It fails at the new scale as an experience, not as marketing.
7. Run the financial risk gate for any venue-touching lever, all documented (see the mechanics reference):
- Deposits typically 25-50% at signing.
- Attrition and F&B minimum penalties owed even under a shortfall.
- 9-18 months lead time for 300+ attendee events.
- Post-pandemic venues rarely renegotiate.
Size the new commitment to the _proven_ number plus a modest buffer, never the aspirational one.
8. Decide the pricing posture _before_ scaling, not after: the recommended default is a public community-price commitment cross-subsidized by sponsorship - the documented flagship case held individual prices flat and cut student tickets 40% across five years of venue growth. Supporter tiers and early-bird ladders are complementary, not alternatives. Price _setting_ mechanics route to `samber/dev-event-organizer-skills@event-ticket-pricing`.
9. Pair the chosen lever with its named mitigation:
- Tracks or days dilute the hallway track, so record everything and protect unstructured time (the documented organizer mitigation).
- Caps concentrate scarcity, so pick an allocation mechanism from the non-growth menu.
Never present a lever as free.
10. Commit, then install the warning-sign watch: the four reversal benchmarks under Measurement, each with an owner and a check date. Any one firing means hold or shrink the next edition, not push through.
If what surfaced isn't a growth problem at all, route out instead:
- Soft demand routes to `samber/dev-event-organizer-skills@event-market-fit`.
- No bench for the step routes to `samber/dev-event-organizer-skills@event-team-structure`.
- A second format or event question routes to `samber/dev-event-organizer-skills@event-portfolio-strategy`.
If your harness has persistent memory, record for each edition:
- The chosen lever and the rungs explicitly rejected.
- The demand evidence it rested on.
- The financial exposure accepted.
- The pricing commitment made.
- The four watch-signal values.
The next edition's decision starts from this event's own history, not from generic cases.
## Growth levers
Ranking (default, not a law - re-rank against the interview: a hard signing deadline promotes squeeze and pricing, a compounding mandate strengthens every gate, an owned asset like a trusted venue or a second-city community promotes a normally-later rung; and for a free volunteer-run event the financial axes collapse, making track addition the default):
- effort: `venue step-up > day addition > track addition > venue squeeze == price-led growth` (tie argued: both are executed with partners you already have, inside the already-signed footprint - a layout renegotiation with a known venue, a pricing change on your own sales page; days of coordination, not months, and no new program to produce)
- value (additional demand served per edition): `venue step-up > day addition == track addition > venue squeeze > price-led growth` (tie argued: the documented record treats them as one rung - organizers used them interchangeably or together to grow program surface and admitted demand inside the existing venue relationship; they differ in what they cost, not in what they buy)
- efficiency: `venue squeeze > price-led growth > track addition > day addition > venue step-up`
- compliance cost (contract review triggered, reversibility lost): `venue step-up > day addition > venue squeeze > track addition == price-led growth` (tie argued: neither touches a contract - the rooms are already inside the signed footprint, and pricing is a unilateral change)
- **Venue squeeze** - the default rung: extract more capacity from the known venue via layout, bounded by occupancy/fire-code sign-off. The documented flagship case fit a third more attendees into a hall already "at capacity" with tighter layout and slimmer chairs, instead of signing a third, larger, unproven venue. Move up a rung only once squeeze headroom is exhausted _and_ the demand signals have repeated.
- **Price-led growth** - grow revenue and demand management without adding seats: early-bird laddering, a premium supporter tier that cross-subsidizes accessible tickets, group-discount design. Decide it alongside whatever else you pick (workflow step 8). Mechanics belong to `samber/dev-event-organizer-skills@event-ticket-pricing`.
- **Track addition** - parallel sessions inside the existing venue and days, the second-most-common documented lever and the entire scaling model of the free-event pole. Universal documented trade-off: hallway-track dilution - every organizer who used it reported the same concern, and it is the exact lever the deliberate-cap events refuse on principle. Always pair with the recording-plus-unstructured-time mitigation.
- **Day addition** - an extra day (tutorials, community day) extending every cost line: venue rental, catering, volunteer shifts, attendee hotel nights. Same value rung as a track, higher effort and a contract amendment.
- **Venue step-up** - the starved option: a discrete jump to a bigger venue (the documented cases doubled capacity in one move), highest in value but losing every efficiency round and carrying the menu's whole contract exposure. Promote it when demand has visibly exceeded supply across repeated editions with the cheaper rungs exhausted, _and_ the downside is capped: smallest negotiable deposit, shortest attrition/minimum commitments, capacity sized to proven demand plus a modest buffer. Then hand execution to `samber/dev-event-organizer-skills@event-venue-sourcing`.
The single-edition multi-x leap is deleted from this menu, not ranked last: several rungs at once, or a one-edition jump past roughly double. The clearest documented case took a ~300-person event to a ~1,300-person format in one edition and drew "doesn't scale" verdicts from its own community.
Its later wind-down was a deliberate choice, not a collapse - cite the leap for the format failure only. Parking it at the bottom would let a milestone year or an anchor sponsor quietly resurrect it.
## Deliberate non-growth and allocation
A real strategy, not a footnote: two of the strongest-brand events in the documented record cap on purpose, and one grew, tried double, and reversed. When the interview picks intimacy - or a reversal benchmark fires - choose an allocation mechanism instead of a lever.
Ranking (default, not a law - re-rank against the interview: an event whose cap exists to shape _who_ is in the room, not just how many, promotes the application mechanisms):
- effort: `deliberate shrink > application + lottery > group-purchase ban > hold the cap`
- value (control over the room, protection of the core experience): `deliberate shrink > application + lottery > group-purchase ban > hold the cap`
- efficiency: `hold the cap > group-purchase ban > application + lottery > deliberate shrink`
**Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass.** Value and effort are the same list, so one mechanism blocks all six pairs: the mechanism that buys more control over the room costs strictly more, including every pair against holding the cap, which loses on value rather than winning anything for free.
No third axis is printed. The check catches no misordering. The efficiency line rests on the arguments below.
- **Hold the cap** - the default: keep capacity flat, sell first-come-first-served, run a waitlist. Near-zero effort, and the waitlist doubles as the demand instrument `samber/dev-event-organizer-skills@event-market-fit` reads. Known documented bias: first-come-first-served favors those with time and money.
- **Group-purchase ban** - refuse large group ticket blocks. Documented anti-clique mechanism from a deliberately-capped ~150-person event: it keeps the room from arriving pre-clustered. Move up from hold-the-cap when group buyers start dominating allocation.
- **Application + lottery** - applications with intent questions, then a lottery, with real per-edition effort. The documented case used it explicitly to counter first-come-first-served bias, prioritize underrepresented attendees, and filter commercial intent. **Promotion condition, keyed to Q10**: the cap is about composition, not just count.
- **Deliberate shrink** - the starved option: go back down. The documented case doubled to ~2,300, then reversed for three named reasons: venue isolation, lost intimacy, and organizer stress ("actively unpleasant"), accepting roughly a 50% production-budget cut as the price. Highest effort and cost, it loses every efficiency round, but promote it when a reversal benchmark has fired, especially the burnout one, since it is the documented response, not an admission of failure.
Batch-released ticket drops engineered to manufacture sellout optics are deleted from this menu, not demoted: manufactured scarcity corrupts sellout speed, the very signal this skill's growth gate reads.
## Failure modes
- **Growing into empty space** - capacity bought ahead of proven demand: the "amazing (but very expensive) venue" the documented postmortem flagged in real time. The financial gate (workflow step 7) exists for this. An over-built edition loses money at attendance that looks respectable.
- **Reading one fast sellout as headroom** - one viral year misleads, and the gate requires repetition. Check sellout speed for batch-release manufacturing before believing it.
- **Quality collapse noticed too late** - "Being small... made the conference so intimate and amazing, and being so intimate and amazing... made it so popular." This documented loop shows growth eroding the value that caused it. Run the ceiling diagnostic before the lever choice, not after the complaints.
- **Sponsor concentration funding the step** - sponsors budget a year ahead (documented), and a single sponsor's exit blows a hole no replacement can fill in time. The documented final-edition case ended exactly this way: sponsorship receded while attendee signals stayed warm.
- **Burnout treated as a mood, not a signal** - in two independent documented cases, organizer stress preceded any financial trigger. "Actively unpleasant" is a named reversal benchmark here, not a complaint to push through.
- **Governance endings misread as growth failures** - the documented case of a major community conference ending in 2022-2025 was a governance and politics rupture, not overexpansion. Never cite an event's ending as "grew too big" without checking the organizer's own account.
- **Benchmarking against outliers** - the fastest documented case scaled ~100x in five years on a broad general-tech topic, and its base year is itself disputed: a ~150-person 2009 precursor vs. a ~400-person 2010 start, report the range. A niche developer conference doubling per step is the normal documented pattern, not a failure against that curve.
## Measurement
Reversal benchmarks - any one firing stops or reverses the growth push (the specific trigger values are self-set and must be declared before the sale opens):
- Sellout speed slows materially year-over-year at flat or higher capacity.
- No-show/attrition rate rises as the event scales.
- A single sponsor exceeds the revenue share you set in advance (self-set - declare the threshold now, not after a sponsor grows into it).
- The organizing team reports the work has become actively unpleasant.
Context to temper expectations: a 2023 industry write-up found independent in-person events running 30-40% below pre-pandemic attendance - a market-wide contraction, not evidence any single event mismanaged growth.
Success for this skill's own output is a growth plan that names all of the following:
- Exactly one lever, or one allocation mechanism.
- The demand evidence it rests on, with each figure marked documented or self-set.
- The financial exposure accepted and its cap.
- The pricing posture.
- The lever's paired mitigation.
- The four watch signals, with owners and check dates.
A plan missing the watch or the mitigation is not done.
## Invocation examples
- "Our 300-person conference sold out in 20 minutes with a 200-person waitlist. Do we sign the 600-seat venue?"
- "We're debating adding a second track next year - what does it cost us besides money?"
- "Demand keeps growing but organizing stopped being fun. Can we just not grow?"
Expected output: the growth (or non-growth) plan described under Measurement, delivered section by section for validation:
- Demand evidence.
- Ceiling diagnostic.
- Reach-vs-intimacy call.
- Chosen lever with rejected rungs.
- Financial gate result.
- Pricing posture.
- Mitigation.
- Watch plan.
## References
- [references/growth-case-studies.md](references/growth-case-studies.md) - the documented case record behind every lever and cap: venue step-ups, the squeeze, track-based free scaling, accessible-pricing scaling, the deliberate caps and the shrink, the overexpansion postmortems, the outlier - including three contested figures that must be reported as ranges.
- [references/venue-and-money-mechanics.md](references/venue-and-money-mechanics.md) - venue contract risk mechanics (deposits, attrition, F&B, lead times), the demand-headroom heuristic and the cases behind it, the three pricing-evolution mechanisms, and the sponsor-concentration and burnout warning patterns.
See also, same collection:
- `samber/dev-event-organizer-skills@event-market-fit` - produces the demand read this skill consumes; a soft read goes back there, never into a lever.
- `samber/dev-event-organizer-skills@event-first-edition` - zero-to-one launch; this skill starts at edition two.
- `samber/dev-event-organizer-skills@event-ticket-pricing` - owns price-setting mechanics; this skill only decides the posture.
- `samber/dev-event-organizer-skills@event-venue-sourcing` - executes the venue search and negotiation once a step-up is decided.
- `samber/dev-event-organizer-skills@event-planning-timeline` - turns a committed lever and its 9-18 month lead into the work-back plan.
- `samber/dev-event-organizer-skills@event-portfolio-strategy` - one team running several events or formats; the franchise edge named above belongs fully to neither skill.
- `samber/dev-event-organizer-skills@event-team-structure` - its peer-network section covers independent local communities cooperating under a shared manifesto, the voluntary form of the franchise edge.