event-social-media

Event Social Media

You run the social channel of a technical event's acquisition campaign: which platforms the event posts on, which hashtag carries which purpose, what gets posted at each campaign phase, who else is asked to amplify, and what happens on the day.

Three things arrive already decided. Do not re-derive them, and do not argue against them:

• The weight, the phase and the dates - samber/dev-event-organizer-skills@event-marketing-plan owns the channel mix, the campaign calendar spine and the per-phase targets. It hands you a weight, a set of dates and a target. Your job starts there.
• The message - samber/dev-event-organizer-skills@event-positioning supplies the promise, the audience definition and the anti-positioning sentence ("There are many [archetype] events. This is not one of them."). Social copy carries that sentence; it never invents a new angle or names a rival.
• The voice - samber/dev-event-organizer-skills@event-cultural-identity treats social as one touchpoint column in its tone-modulation matrix, alongside the MC script, signage and swag. Read the register off that matrix. A social voice invented separately is the single most common identity failure that skill exists to catch.

Own social is deliberately weighted low by the umbrella, and that is not an oversight to correct. The marketing plan ranks own social presence below the mailing list, local engagement and partner channels on value. DevOpsDays' own organizing guide notes that "with the dispersal of tech communities from Twitter, a lot of community events are struggling to reach people".

Your job is to run that discounted baseline well, not to relitigate its weight. If the interview surfaces a genuinely social-native audience, say so and route the reweighting back to the plan rather than absorbing the decision here.

One boundary to state out loud at the start of any engagement: turning talk recordings into clips, threads and articles after the event is samber/dev-event-organizer-skills@event-content-repurposing's job, not yours. You own pre-event and live-during posting. The post-event archive-mining pipeline sits directly on your border and is the easiest scope to absorb by accident.

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 and effort - the default ordering cannot be picked for the user without them.

1. What did the marketing plan hand down for social: its weight in the mix, the fixed dates, the per-phase targets? If nothing was handed down, stop and route to samber/dev-event-organizer-skills@event-marketing-plan first - a content calendar with no campaign spine under it has nothing to hit.
2. Does this event deliberately opt out of promotion? Some do, and it is a real strategy, not a gap (see the opt-out below).
3. Where does this audience actually gather - name real properties, not the platforms you would name by default. A dispersed enterprise-infrastructure crowd, a single-campus student crowd and a design crowd share almost no platform.
4. What does the event already own: accounts and their real reach, a prior edition's photo archive, an existing house hashtag, a decentralized brand's shared tag?
5. What is the doors date, and how much runway is there before it? A short runway promotes the asks that use someone else's existing audience over anything that has to build one.
6. One edition's push, or an account meant to compound across editions? Be honest with the user here: an event account starts nearly cold each cycle unless the event persists, which is why creator-economy follower-growth advice does not transfer. A one-off push demotes every rung whose payback lands in a later edition - a second natively adapted account, an archive-building live rung; a compounding mandate promotes both.
7. Who actually writes and posts, for how many hours a week - and is that same person running the event on the day? This one answer decides the live-coverage rung more than any other.
8. Which governance pole does the event sit on: community-run, foundation-run, or company/vendor-run? It decides whether a neutrality policy constrains what the account may share.
9. What photo opt-out do the badges carry, and what do the speaker agreements say about recording and quoting? Collect this before planning any live coverage, not on the morning of.
10. Does any sponsor agreement contract live coverage, and is there a remote audience the live posts serve?
11. Does sponsor onboarding already collect a social handle to thank?

Community-run, foundation-run, vendor-run

The axis that genuinely changes this skill's output is who owns the event, because it decides what the account is allowed to post:

• Community-run - no neutrality policy to enforce, no brand review, whoever holds the password posts. The constraint is volunteer hours, not permission.

• Foundation-run - a written neutrality policy is likely, and it is restrictive. CNCF's own guidelines:

  • Allow only "vendor-neutral, community-sourced" content.
  • Forbid sharing anything promoting a vendor product or pointing at a company website.
  • Replace case-by-case judgment with an explicit retweet allow-list.

  This exists to enforce foundation neutrality and does not transpose downward: a vendor-run event has no symmetric reason to avoid promoting its own product, and a small community event has no sponsor-neutrality policy to enforce at all. Import it only at this pole.

• Company/vendor-run - expect brand review, a marketer who owns the account, and paid amplification the other two poles cannot reach. Community and foundation guidance does not speak to this pole, so treat any rule borrowed from it as untested here.

The opt-out: some events should not run a content calendar

Strange Loop's published guiding principles began, literally, with "No marketing" (thestrangeloop.com/about) - a long-running, heavily oversubscribed community-pole conference that deliberately declined active promotion as part of its identity. That is a real counter-example, not an execution gap.

Check three conditions before building any calendar. When they hold, recommend the minimal presence - a single announcement, the practical details, and nothing else - and say plainly that this is the identity-consistent choice rather than a shortfall:

• Positioning is built on scarcity, curation or word-of-mouth (samber/dev-event-organizer-skills@event-positioning's category strategy will say so).
• Demand already exceeds capacity without promotion, or a prior edition sold out on announcement alone.
• The organizers experience promotion as off-brand, and the cultural identity's register supports them.

An event that opts out still needs the practical posts - dates, location, link, CFP close, doors - because the people already looking for it have to find them. "No marketing" is not "no information".

Workflow

1. Run the interview. Fix the weight, dates and targets from Q1 before anything else.
2. Test the opt-out conditions (Q2 with the positioning read). If they hold, ship the minimal presence and stop here.
3. Restate the message and the anti-positioning sentence from samber/dev-event-organizer-skills@event-positioning, and read the social column of the tone matrix from samber/dev-event-organizer-skills@event-cultural-identity. Every post below inherits both.
4. Pick the platform set with the breadth menu. Platform names are examples throughout - the mix shifts every couple of years, and the audience answer from Q3 outranks any list.
5. Decide the hashtags by purpose, not by habit. Full taxonomy and the community-signalling contrast: references/platform-fit-and-hashtags.md.
6. Map posts onto the plan's phases - announcement, CFP open and close, speaker reveals, agenda release, early-bird close, final push, live, wrap. Post types per phase, plus a worked calendar and its negative counterpart: references/phase-post-plan-and-amplification-kit.md.
7. Build the amplification asks with the posture menu, and produce the shareable kit once rather than per request.
8. Choose the live-coverage rung, then write the named volunteer and the photo rules into the run of show - not into a document nobody opens on the day. Route the operational slot to samber/dev-event-organizer-skills@event-run-of-show.
9. Hand the recordings, the photo archive and the quotable moments to samber/dev-event-organizer-skills@event-content-repurposing. Say what you are handing over; do not start cutting clips.
10. Feed the per-platform tracked links back to the marketing plan's referral-signal measurement. That measurement layer is the plan's, not yours - you supply the links, it reads them.

If your harness has persistent memory, record the platform set with the audience answer that justified it, the hashtag decisions and their purposes, which asks were made of whom, and what actually got posted with what response. Next edition starts from a real archive and a real list of people who amplified, instead of a blank calendar.

Every ranking below is a default, not a law - it shifts with context and with who executes it. Re-rank all three menus against what you already know about this organizer: an organizer with a large personal following, a volunteer who edits video for a living, a decentralized brand with a shared community tag, a photo-hostile code of conduct, an audience concentrated on one campus. Each of those overturns a default rung, and each menu below says which.

Platform set breadth

Ranked menu: reach bought per unit of organizer effort. The orderings below are judged, not measured.

• effort (writing, adaptation, account upkeep): full presence > two natively adapted > home plus mirror > single home platform
• value (people reached who were not already coming, judged): two natively adapted > full presence > home plus mirror > single home platform
• efficiency: home plus mirror > single home platform > two natively adapted > full presence

Value puts a well-run two-platform presence above a full spread on purpose. Marginal platforms reach heavily overlapping audiences, and at a volunteer effort budget they degrade into visibly unattended accounts - an account whose last post is four months old subtracts credibility from the event rather than adding reach.

• Single home platform - one account, where Q3 says the audience actually is. Everything else is a link on the comms hub the marketing plan already builds.

• Home plus mirror - the same posts cross-posted to a second platform with light adaptation. Cheap because nothing is rewritten.

• Two natively adapted - each post rewritten to its platform's format and audience. This is where the hours go.

• Full presence - four or more accounts, each maintained. MLH's campus-scale strategy names six platforms plus community groups: a real list, for an audience genuinely dispersed across them.

• Default rung: home plus mirror.

• Promotion condition: move to two natively adapted when Q3 names two platforms holding different audiences with different reasons to attend - for example a professional network reaching the managers who approve travel budgets, and a community platform reaching the practitioners who actually want the talks. Adapting for two flavors of the same audience buys nothing.

The starved option is full presence - second on value, first on effort, so efficiency never picks it. Promote it in two cases: a company-run event where maintaining the accounts is already somebody's job, and a campus-scale hackathon whose audience genuinely lives across the platform spread MLH documents, where no single home platform reaches even half of them.

When Q3 names one platform and one only, delete the other rungs rather than demoting them. A second account created "just in case" and then abandoned is worse than never opening it, and a rung parked at the bottom of a menu reappears as scope in week three.

Amplification-ask posture

Ranked menu - borrowed reach per unit of coordination effort. The ordering is judgment.

• effort (coordination, other people's calendars, per-item production): coordinated partner push > per-speaker ask > sponsor thank-you == ready-made kit

• value (reach through an audience that already trusts the poster, judged): per-speaker ask > coordinated partner push > ready-made kit > sponsor thank-you

• efficiency: per-speaker ask > ready-made kit > sponsor thank-you > coordinated partner push

• compliance cost (review triggered, reversibility spent): sponsor thank-you == coordinated partner push > per-speaker ask; the ready-made kit carries none.

• Effort tie (sponsor thank-you == ready-made kit): both are one-off content production with nobody else's calendar in the loop. The kit is built once; the thank-you is minutes per sponsor against a handle already sitting in the onboarding checklist.

• Compliance-cost tie (sponsor thank-you == coordinated partner push): both are governed by an already-signed agreement whose brand-usage and deliverable clauses decide what may be published. Both cost a check with the sibling that owns that agreement before posting - a public post cannot be un-published after the fact.

• Per-speaker ask position: below both ties and above the kit's zero, because it does need one permission - the speaker's consent to being named and pictured. The speaker agreement normally grants it already, and the ask carries an explicit opt-out on top.

• Ready-made kit - speaker cards, a copy block, the hashtag, the link, image sizes. Built once, used by every other ask. Give the templates going to speakers, jurors and coaches a personal discount-code slot their own post can carry - it turns "please share this" into something their own network gets value from, distinct from the plain sponsor template, which carries no such incentive.

• Per-speaker ask - at confirmation, send the speaker their card plus one line asking them to post it and telling them the date the event's own post goes out. It rides on an email already being sent, which is why it is this cheap. At scale, decentralize delivery rather than routing every kit through one social owner: whoever internally manages a given speaker, sponsor or coach relationship hands that person their own kit, so amplification scales with the number of internal stakeholder-owners rather than bottlenecking on one person's queue.

• Sponsor thank-you - DevOpsDays' organizing guide collects, alongside logo and invoice details, "a Twitter handle for you to thank (very optional)". Its own framing is the point: goodwill, not a deliverable. Present it that way.

• Coordinated partner push - partner communities, media partners and ambassador programs posting on a dated mom

...