Hosting and moderating: planning, tech talks, brown bags

Sooner or later you stop only attending sessions and start running them: a design review you chair, a sprint planning you drive, a tech talk you give, a brown bag you host. Running a session is a distinct skill from participating in one, with its own phrases, and it is disproportionately visible; the person at the front of the room is being evaluated by everyone in it. The good news, as with meetings: it is formulaic, and the formulas are below.

Don't be confused: four overlapping roles. The chair owns a formal meeting's agenda and decisions. A facilitator owns the process (time, turn-taking, parking lot) but deliberately not the content, and may have no stake in the outcome. A moderator runs a Q&A, panel, or discussion between other speakers. A host (or MC) opens and closes an event and introduces others. In practice one person often plays all four; the useful distinction is content versus process: the more you personally argue for an outcome, the less you can simultaneously play referee, and for contentious design reviews it is standard to split the roles ("I wrote the doc, so Priya will facilitate").

The facilitator's contract

Whatever the session, the person running it owes the room five things, each with its stock phrases:

  1. Start and end on time. "It's two past; let's start. We'll protect the last five minutes for decisions."
  2. A stated goal. "By the end of this hour we need a decision on the storage engine; everything else is input to that."
  3. One conversation at a time. "Hang on, we've got two threads going; let's finish the quota question first."
  4. Tangents parked, not killed. "Good topic, wrong meeting; parking it." (And then actually following up, per Chapter 8.)
  5. Outcomes landed. The decision/owner/date close, every time.

Chairing a design review

The design review is the highest-stakes session most engineers ever run, because it mixes technical judgment with ego in a shared room. The chair's job is to keep the discussion about the design, in both directions: not letting critique become personal, and not letting politeness bury real objections.

Opening frame, worth saying almost verbatim:

Goal: a decision on the queue design by :50. The doc's been out since
Monday; I'll assume it's been read. Ground rules: concerns before
preferences, concrete over vibes, and comments on the design, not the
author. Ana, you flagged the biggest concern in the doc; start us off?

Moves specific to the chair role:

  • Order the fire. Blocking concerns first, preferences later: "Let's hear anything that would stop this design entirely before we discuss flavor." This prevents an hour of bikeshedding followed by a fatal objection at :55.
  • Translate heat into substance. When a comment arrives as a verdict ("this will never scale"), the chair converts it: "Let's make that concrete: at what load, and which component goes first?" You are doing Chapter 5's work on behalf of the room.
  • Protect the author. "Hold on, three people are talking at the author. One at a time, and let them answer." An author who feels ganged up on stops absorbing feedback entirely.
  • Name the silence. "The storage folks haven't said anything, and this lands on you; genuinely fine with it, or being polite?"
  • Close honestly. Decision, or explicitly not: "We're not deciding today; the open item is the failover cost, Ravi owns the analysis, we reconvene Thursday." A non-decision stated crisply beats a fake consensus.

If you are both author and chair (common on small teams), say the quiet part: "I'm biased here, so push hard; someone volunteer to keep me honest on time and tangents."

Running sprint planning and refinement

Planning sessions have their own working vocabulary. Refinement (the older name "backlog grooming" is being phased out in many orgs; you will hear both) is where stories get clarified and sized before planning; planning is where the team commits to a sprint's worth. Phrases that do the work:

  • Clarifying scope: "What does done mean for this story? Merged, deployed, or verified in prod?" (the definition-of-done question), "Is the spike included or is this build-only?" (a spike is a timeboxed investigation whose output is knowledge, not code).
  • Sizing: "I'd call it a 3; the unknown is the vendor API." / "This feels like two stories wearing a coat; can we split the migration from the UI?" / "Last time something looked this easy it took a sprint; what are we not seeing?"
  • Capacity honesty: "We're planning 80% capacity; Dana's on call and we have the audit deadline." / "That's a stretch goal, not a commitment; let's mark it as such." The commitment/stretch distinction is Chapter 7's estimate-versus-promise rule applied to the whole team.
  • Pushing back on scope pressure, as the facilitator: "We can add it, but the sprint is full, so name what comes out." (The costed yes from Chapter 10, used preemptively.)

Hosting a tech talk or brown bag

A brown bag is an informal talk over lunch (named for the packed-lunch bag), lighter than a formal tech talk; a lightning talk is a five-to-ten minute version. Hosting any of them is a sandwich: intro, timekeeping, Q&A, thanks.

  • The intro: one line of who, one of what, one of why-you-care: "This is Priya, who's been running our search infrastructure for three years. She's going to walk us through the reindexing incident and what it taught us about our schema. If you've ever been paged by search, this one's for you." Then get out of the way.
  • Housekeeping: "Forty minutes of talk, ten of questions. Drop questions in the thread as you go, or save them; we'll take them at the end."
  • Timekeeping: agree on signals beforehand; live, it sounds like "five-minute warning, Priya" or a chat message. Protecting the Q&A slot is the host's job, not the speaker's.
  • The thanks: specific beats generic, as always (Chapter 2): "Let's thank Priya; the aliasing trick alone was worth the hour."

Moderating the Q&A is where hosts earn their keep:

  • Seeding: have one question ready for the dead air after "any questions?" "I'll start while people think: what would you do differently today?"
  • The comment-disguised-as-question: let it run a beat, then: "And is there a question in there for Priya?" (said lightly, it gets a laugh and works); or convert it: "So the question is whether this generalizes beyond search; Priya?"
  • The rambler: "In the interest of time, let me compress that to: why not Elasticsearch? Priya?" Compressing someone's question is a service, not an insult, when done accurately.
  • The hostile question: absorb and normalize: "Fair challenge; Priya, take it wherever you want." The moderator's calm is contagious in both directions.
  • Closing: "Time for one more... and done. Thread stays open for the rest; recording goes up this afternoon."

Giving the talk yourself

The speaker's side, compressed to the phrases that matter:

  • Signpost relentlessly. "Three parts: the problem, what we tried, what I'd do differently. Part one." Spoken audiences cannot scroll back; structure said out loud is the only table of contents they get. Between parts: "That's the problem; here's what we tried."
  • Open with the audience's stake, not your agenda: "Show of hands: who has been paged by the search cluster?... Right. This talk is about why that keeps happening."
  • The unknown answer: "I don't know offhand, and I'd rather not guess at the front of a room. Catch me after, or I'll post the answer in the thread." (Chapter 3's "I don't know" plus a delivery plan, performed publicly.)
  • The demo failure: have the script ready because you will need it: "The demo gods have spoken; here's the screenshot version, and I'll post the recording of it working." Zero apologizing beyond one joke; the audience forgets a failed demo in minutes and remembers flustered recovery for years.
  • Running long: cut content, never the ending: "I'm going to skip the benchmarking section (slides have it) and jump to the takeaways."

Panels and AMAs

Two formats worth a paragraph each. Moderating a panel: your job is distribution and friction. "Sam, thirty seconds on the same question" keeps answers moving; "You two seem to disagree; say more about that" is the moderator's best sentence, because polite panelists will otherwise sand off every interesting difference. An AMA ("ask me anything") runs on the moderator batching and sequencing questions: "Bundling three related ones: what's the roadmap for X, and does it survive the reorg?" Protect the guest from pile-ons the same way a chair protects a design author.

👉 Hosting is ceremony at its most pleasant: you control the agenda and the clock. The last ceremony chapter is the opposite: the messages that arrive off-schedule and unwelcome. Slipped deadlines, production incidents, blocked dependencies, and your own mistakes, delivered early and well. On to Chapter 10.