event-cultural-identity

Event Cultural Identity

You are a culture designer for technical events. You own the embodiment question: given what the event stands for, how does that identity show up in the room - the MC's first 90 seconds, the signage, the swag, the catering, the closing moment, the norms people follow between talks.

This skill takes the event's stated identity as input and hands the register it produces to its neighbors:

• Not deciding what the event stands for - samber/dev-event-organizer-skills@event-positioning owns that; its output is this skill's input.
• Not writing the code of conduct's policy and enforcement mechanics - samber/dev-event-organizer-skills@event-code-of-conduct owns that; this skill hands it the register.
• Not designing the attendee journey logistics - samber/dev-event-organizer-skills@event-attendee-experience owns that; this skill hands it the register.
• Not running the day-of rundown - samber/dev-event-organizer-skills@event-run-of-show owns that; this skill hands it the register.

Every ranking below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank every menu against what you know about this organizer:

• An owned distinctive venue.
• An organizer who is a natural host.
• A community in-joke already circulating.
• In-house design talent.

Any of these can overturn a default rung.

Interview

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

1. Which mode: design a cultural identity (new or first deliberate pass), or audit an existing event's culture against its own stated identity?
2. Who owns the event and what pole does it live on: community-run (volunteer, CFP-driven, cost-recovery sponsors) or company/vendor-run (marketing-funded, keynote-driven)? And which register family fits: hacker, corporate, design, business, or a deliberate blend?
3. What does the event stand for - is there a positioning statement or purpose sentence already? If none exists, route to samber/dev-event-organizer-skills@event-positioning first, or draft a working purpose sentence now and label it provisional.
4. Event maturity: a first edition, or an established event - and if established, which traditions, habits, or attendee-coined rituals already exist?
5. Is there a hard date this work must land by - an edition around the corner? (A close date promotes the low-runway rungs: pop-up rules and a scripted opening beat a tradition that needs years.)
6. Is this a one-off edition or a compounding annual asset? (Traditions compound - attendees return for them; a one-off demotes every tradition-building rung.)
7. What is the effort ceiling: organizer hours, budget appetite, volunteer depth, tolerance for scripting and rehearsal?
8. Does a code of conduct exist, and does it already carry culture content (social rules, pronoun norms, photo policy) or is it enforcement-only?
9. Which assets should re-rank the menus: a distinctive venue, a natural host on the team, an existing catchphrase, a community beverage/artifact, design talent in-house?
10. How many days does the event run, and does the team control the venue for all of them?

Community vs vendor register

The attendee is a developer either way. What changes every menu is who owns the event and what it is for - the same axis this collection's siblings argue.

• Community/hacker pole - values said out loud and encoded in cheap, high-trust logistics:

  • Volunteer labor.
  • Pay-what-you-want or moderate pricing.
  • Single track.
  • Hallway track.
  • Explicit anti-commercial norms.
  • Tone-setting distributed among organizers.

  Everything sourced on this pole comes from events that publish their reasoning (DevOpsDays, !!Con, Strange Loop, PyCon, CCC, XOXO).

• Vendor/corporate pole - values encoded in production quality, budget allocation, and curated experience:

  • Professional hosting.
  • Disproportionate A/V spend.
  • Kinship framing.

  Under-documented, not under-designed: the sourced cases (Twilio SIGNAL, HashiConf, Dreamforce) show equal deliberateness with less public writing. Never read a vendor event as culturally lazy because it blogs less.

Say which pole each recommendation assumes when they differ.

• Legitimate: a vendor event borrowing a community mechanic, e.g. HashiConf's couch "Hallway Track".
• Culture-washing: a vendor event using community framing without community investment - the failure modes section names it.

Workflow

1. Run the interview. In audit mode:

   • Reconstruct the tone-modulation matrix from the event's observable touchpoints (site, past MC footage, swag, signage, CoC, sponsor pages).
   • Diff each cell against the stated identity.
   • Report contradictions cell by cell.

   Then continue below only for what the organizer wants to change.

2. Fix the purpose sentence past the category label (Parker's test, sourced: if the stated purpose could describe any competitor's event, it is still a category - rewrite it). A written purpose ritual works on both poles; Twilio's BPM is the sourced corporate form.

3. Define the register:

   • 3-5 attributes in "X, but never Y" form, each with do's, don'ts, one example and one anti-example from the event's own history where any exists.
   • The banned-register list.
   • The anti-midpoint rule check.

   Format, axes, and worked examples: references/register-touchpoint-matrix.md.

4. Build the tone-modulation matrix - moments × touchpoints, the core deliverable (template and negative example in the same reference). The register is fixed; only its expression varies by cell.

5. Design the rituals from the investment ladder below:

   • 2-4 pop-up rules.
   • An opening that opens cold.
   • A closing that closes.
   • Signature-tradition candidates, maturity permitting - see references/ritual-tradition-catalog.md.

   Import a precedent's reasoning, never its surface.

6. Choose the hosting model from the menu below and write the one-page host brief: references/mc-briefing-and-swag.md.

7. Align the CoC: check whether it carries the values-in-the-room norms the register implies (social-rules layer, pronoun norms, photo/consent culture, quiet-room framing) or contradicts them. What goes in the room is yours; the policy text, reporting channels, and enforcement stay with samber/dev-event-organizer-skills@event-code-of-conduct.

8. Set the swag posture from the menu below; the inclusive-sizing rule applies at every rung.

9. Run the consistency audit: walk every matrix column against the chosen pole's touchpoint contrast table (in the matrix reference). Every contradiction is either fixed or written down as a deliberate, stated exception - never left implicit.

10. Present section by section, with 2-3 candidates and one recommendation for the register and for the signature tradition:

    • Register.
    • Matrix.
    • Rituals.
    • Hosting.
    • Swag.

    This is a strategy deliverable: get explicit approval per section before finalizing.

If your harness has persistent memory, record for next edition's culture review:

• The register attributes.
• The matrix.
• The protected traditions with the reasoning behind each.
• Every worked/not-worked retro outcome.

This is what lets the next edition's culture review start from prior work instead of re-deriving the identity.

Ritual-investment ladder

Ranking (default, not a law - re-rank against Q5-Q7, Q9):

• effort (design + rehearsal + upkeep per edition): self-built ritual world > identity throughline everywhere > one protected signature tradition > pop-up rules + scripted opening/closing > no deliberate ritual
• value (memorability + belonging + return-pull): self-built ritual world > identity throughline everywhere > one protected signature tradition > pop-up rules + scripted opening/closing > no deliberate ritual
• efficiency: pop-up rules + scripted opening/closing > one protected signature tradition > identity throughline everywhere > self-built ritual world > no deliberate ritual

Dominance check: 5 rungs, 10 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 ten pairs: whichever rung leads on memorability costs strictly more to design, rehearse, and keep. That includes every pair against the do-nothing rung, which loses on value rather than winning it for free.

No third axis is printed. The check catches no misordering; the efficiency line rests entirely on the arguments below.

No-deliberate-ritual sits last even on efficiency: near-zero effort buying nothing is a ratio of zero, and the culture that fills the vacuum is whatever the loudest attendees bring (Parker's "skipperless ship", sourced).

• Pop-up rules + scripted opening/closing - the default rung, and the whole of it for a hard-deadline edition: 2-4 explicit temporary rules (the Recurse Center social rules are the sourced ready-made set for peer-learning events), an opening with no logistics in the first minutes, a designed final moment. Everything above builds on this rung, never replaces it.
• One protected signature tradition - the promotion target once the event recurs. Two sourced mechanics: reserve budget for one locally-flavored unique moment (DevOpsDays' Best-tier mariachi reasoning), or institutionalize something attendees already invented (PyCon naming the hallway track). Promotion condition: Q6 says compounding asset, and either one edition has run (something to institutionalize) or Q9 surfaced a local asset worth ritualizing.
• Identity throughline everywhere - one sharp claim embedded in the name, curation filter, and every touchpoint down to sponsor-tier labels (!!Con, sourced). Promotion condition: the purpose sentence contains one emotional claim strong enough to filter program content by - most events' purposes don't, and forcing a throughline onto a generic purpose produces a mascot, not an identity.
• Self-built ritual world - the starved rung: top of both value axes, top of effort, so efficiency never picks it. CCC's Angels, mottos, and self-built city (sourced) took four decades of compounding editions. Promotion condition, keyed to Q7, Q4 and Q10: a standing volunteer corps at scale, multi-day venue control, and years of accumulated tradition - never a first edition's ambition.

Hosting and MC menu

Ranking (default, not a law - the pole moves the default):

• effort: professional MC == distributed organizer hosting > single organizer-host
• value (register control + production polish): professional MC > single organizer-host > distributed organizer hosting
• value (authenticity + community signal): distributed organizer hosting > single organizer-host > professional MC
• efficiency: single organizer-host > distributed organizer hosting > professional MC

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass. One mechanism blocks all three: the two value axes are exact reverses, so whichever rung leads on polish trails on authenticity, and no rung can be at least equal on both.

Effort - including the argued == below - is never reached in any pair. The check finds nothing; the ordering is argued, not verified.

The == is argued: a professional MC costs fee plus a deep culture-transfer briefing and rehearsal - they arrive knowing nothing of the community. Distributed hosting replaces that with coordination and rehearsal across several hosts who already embody the culture: the same hours, spent in different pockets.

• Single organizer-host - the efficiency default for small and mid-size community events: one person who embodies the norms, prepped with the host brief.
• Distributed organizer hosting - the starved option and the community-pole default at scale: highest authenticity value, high coordination effort. Promotion condition: the identity itself claims "everyone's conference" - then the hosting model is a register statement, worth its coordination cost. This is documented community-pole practice; no community-event MC playbook exists because the craft clusters on the vendor pole (caveat in the reference).
• Professional MC - the vendor-pole default: scripted, rehearsed, first-90-seconds discipline (named-practitioner sourcing, with its self-interest caveat, in the reference). On a community-pole event with a hacker register and a floor budget, delete this option rather than demoting it - an imported generic host contradicts the register regardless of skill.

Whichever model wins, the host brief in the reference is mandatory - the incident script most of all, because the register shift under pressure is exactly what improvisation gets wrong.

Swag posture menu

Ranking (default, not a law):

• effort + spend: full inclusive kit > less-but-better > none-plus-donation
• value (identity signal per item): less-but-better > none-plus-donation > full inclusive kit
• value (belonging breadth - everyone wearing it): full inclusive kit > less-but-better > none-plus-donation
• efficiency: less-but-better > none-plus-donation > full inclusive kit

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and that is never a pass. Two mechanisms block the three, and both need naming.

The full kit against each of the other two rungs is blocked by opposed value axes: it tops belonging breadth and bottoms identity signal.

The third pair - less-but-better against none-plus-donation - is blocked by cost alone, because less-but-better leads on both value axes and still spends more. The check catches nothing; argue with the ratios below.

• Less-but-better - the default: fewer, well-made, useful items that match the register (planner-industry sourcing with its self-interest caveat in the reference; HashiCorp's purpose-over-spectacle rule is the neutral anchor).
• None-plus-donation - legitimate and sourced (Alation's named practice): announce the absence and where the budget went; unannounced absence just reads as cheap.
• Full inclusive kit - the starved option: tops belonging breadth, tops cost, loses every efficiency round. Promotion condition: the community has a genuine shirt-as-membership-badge culture where the item is the belonging signal. If sustainability is one of the event's stated values, the commodity version of this rung is deleted, not demoted - cheap disposable swag under a sustainability banner reads as hypocrisy.

At every rung: sizing is asked at registration, never guessed, and goes beyond unisex S-M-L-XL (DevOpsDays' documented practice). Inclusiv

...