event-debrief

Event Debrief

You run the organizing team's retrospective on one finished edition: the meeting, the reconstruction, the findings, and the log that reaches next edition's plan. Internal-facing only - nothing here reaches an attendee, a speaker or a sponsor.

Run it every edition, unconditionally. The SRE incident-postmortem lineage this skill borrows from gates a postmortem on a severity threshold (SEV1/SEV2, an outage over fifteen minutes); that gate does not transfer. A quiet edition where nothing broke still gets a debrief - the goal is improving a recurring asset, not containing an incident. "It went fine, let's skip it" is the failure this rule exists to prevent.

Five things arrive already decided. Read them, reconcile against them, never reopen them:

Sibling	Owns	You do
event-feedback	Collecting from attendees, speakers, sponsors	Consume its summary, never survey or write to participants
event-risk-management	Taxonomy, scoring, treatments	Check what fired against it, hand back a reconciliation
event-budget	P&L, next edition's numbers	Compare actual vs. planned, hand back the variance
event-run-of-show	Day-of execution	Log what broke as raw input, never re-diagnose
event-market-fit	Whether the concept still meets demand	Surface whether this edition hit the goals this team set, as a signal, never a go/no-go

Upstream boundary: trends across editions are not yours. You produce one edition's dated log; event-continuous-improvement aggregates editions - comparing this one to the last two duplicates its whole reason to exist.

What the field actually publishes about this

Published organizer guides give this a line or two at most. The mechanics that follow instead - when to hold the debrief, who attends, how the log reaches the next plan - come from the SRE incident-postmortem lineage, adapted to an asset that runs once a year rather than a service that breaks on a weekday. See references/field-precedent.md for the sourced detail.

Interview

Ask one question at a time, multiple-choice where possible. Questions 6 to 8 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. Which edition just ended, when did doors close, how many days ago? Decides debrief vs. archaeology.
2. What goals did the team set before the event, in its own words? If unwritten, say so - the review becomes reconstructed, not measured.
3. Who held a named role, and who can be in the room? A debrief missing the volunteer lead misses the half of the day only they saw.
4. Which of the four inputs already exist: feedback summary, risk register, planned budget, run of show? Each missing one is a reconciliation you can't run.
5. Volunteer-run or staffed? Changes who can safely say what and who can be given an action item.
6. When does next edition's planning actually start? That date is this skill's deadline.
7. One-off, final, or recurring for years? A closing and a compounding edition want opposite things from the same menus.
8. Effort ceiling: hours left, and what state the team is in - honestly. An exhausted team is the first finding, not a scheduling problem to route around.
9. Is leadership handing over after this edition, and does the event run as one unit or as several cities under a shared brand?
10. How many code-of-conduct reports did this edition receive, how many were resolved, and were any visible enough that the community already knows?
11. Is this event public, or private/NDA-bound?
12. Does the team already run a year-round tracker for something else?

Who is in the room and what they are paid

The axis that changes this skill's output is who is in the room and what they are paid - it decides what can be said and who can be handed a task. Volunteer-run: no employment relationship buffers the conversation, so candor is cheaper, but no manager absorbs an action item, and a criticised volunteer simply stops volunteering - a loss invisible in the log. Staffed: carry-through is structurally better since action items land on someone whose job includes them, but the debrief drifts toward performance review unless the blameless frame is stated and enforced explicitly. Mixed (the common case): state the frame most explicitly here - a volunteer and their day-job manager in the same room changes what the volunteer will say about workload.

Workflow

1. Run the interview. Pick the depth rung before booking anything.
2. Set the date immediately, hold it soon. No standard interval exists; propose one and calendar it before the team disperses.
3. Open with the blameless frame, out loud, in the room - the question is what conditions allowed this, never who caused this. Findings describe gaps and systems, never people.
4. Reconstruct the timeline before any analysis. Walk the edition chronologically. Reconstruction first, judgment second - a room jumping to opinions relitigates the loudest memory instead of the actual sequence.
5. Separate well from poorly as two explicit passes. Run "well" first - a practice that worked and goes unnamed is one quietly dropped next edition.
6. Reconcile against what exists: risk register, planned budget, run of show, Q2's goals. Four checks, four outputs, each to its owning sibling. Checklists: references/reconciliation-and-session-agenda.md.
7. Surface team-health findings and route them without solving them. Exhaustion, a role only one person could do, an unsized workload - structural findings for event-team-structure, not yours to fix.
8. Write each finding as a three-part entry: what happened, what was done in the moment, what changes next edition - deliberately shallow. Format and escalation criteria: references/lessons-learned-entries.md.
9. Give every open entry an owner and a due date, or close it explicitly. No orphans - an entry with no owner is a wish, not a lesson. If no action is needed, write "no action, because" rather than manufacturing one.
10. Decide the publication posture as a team, in the room, while findings are fresh.
11. Hand the log to event-continuous-improvement as one dated document, each reconciliation to its owning sibling, and stop.

If your harness has persistent memory, record:

• the dated log itself
• the goals this edition was measured against
• every action item with its owner and due date
• which findings were routed to which sibling

Next edition's debrief then opens with last edition's open items instead of a blank page - and that carry-over list is the single input samber/dev-event-organizer-skills@event-continuous-improvement cannot reconstruct later.

Every ranking below is a default, not a law; it shifts with context and with who executes it. Where a constraint deletes a rung, strike it from that menu's axis lines too - a rung surviving in the ordering survives in the reader's head and comes back as scope. Re-rank all three menus against what you already know about this team:

• A team whose members run sprint retrospectives at work buys the deeper depth rungs far more cheaply than the effort axis assumes.
• An event with a published-recap tradition already sits at the publication menu's default.
• A team that already keeps a shared tracker running year-round makes the tracking menu's starved option nearly free, because it is an existing habit rather than a new standing job.
• A team where one person holds three roles has already produced the finding that the depth menu is trying to buy.

Debrief depth

Ranked menu - findings that actually change next edition, bought per unit of the team's remaining energy. All three orderings are judgment rather than a published standard: organizer guides prescribe no debrief format.

• effort (hours, calendar coordination, facilitation): multi-track written review > per-track sessions > written pre-read plus one session > one session
• value (findings surfaced that would otherwise be lost): multi-track written review > per-track sessions > written pre-read plus one session > one session
• efficiency: written pre-read plus one session > one session > per-track sessions > multi-track written review

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: whichever rung surfaces more costs strictly more team-hours. No third axis blocks or rescues a pair; the efficiency line rests on the argument that follows.

Efficiency inverts the middle of the list because the two rungs on top of value are also the two on top of effort. Hours are the binding constraint right after an event, and per-track coordination scales worse than the detail it buys.

• One session - a single 60-90 minute meeting, notes captured live into a dated log.
• Written pre-read plus one session (default) - every named role submits a well/poorly list beforehand; the session discusses rather than collects. Buys the quiet organizer's findings and stops the first speaker anchoring the room.
• Per-track sessions - separate debriefs per workstream, then one consolidation session. Promote when named workstream leads worked genuinely independently - no single room holds everyone who knows what happened.
• Multi-track written review (starved rung) - per-track sessions plus a written document per track, consolidated into a full edition report. Tops value and effort, so efficiency never picks it. Promotion condition, keyed to Q9: a leadership handover (incoming team inherits a written record) or a franchise/multi-city event whose sibling organizers read each other's reviews.

When the "team" is one or two people, delete both track-based rungs rather than demoting them - five track sessions for two people is ceremony.

The retro table

A single meeting produces minutes; a standing table kept open across the cycle produces something a meeting cannot - room for dissent to survive past the moment it was raised. Structure it with five columns - Who / Observation / Agrees / Disagrees / Comments - and let anyone add a row at any time, not only during the scheduled session. Agreement and disagreement are columns, not a comment thread that quietly closes; a row stays open until the team is actually ready to close it, never just until the meeting ends.

Preserve some findings as raw testimony rather than folding every voice into one summary line. Two people describing the same practice in contradictory terms - one calling it too rare, another too frequent - is real signal a synthesized average would erase into "seems fine." Where a topic drew genuinely split reactions, keep both quotes on the table instead of picking the louder one.

A documented refusal is itself the artifact, not a failure to act. Writing "no action, because [reason]" directly onto the row is what stops an identical suggestion resurfacing next edition as if it had never been considered - the same no-action discipline step 9 already asks for action items, applied here to the table itself. Do the same for a call that genuinely split the team: record both positions on the row rather than letting one side win by attrition, so the debate stays available to whoever revisits it.

Publication posture

Ranked menu - community trust and accountability bought per unit of drafting, review and exposure. This is the one menu here carrying real exposure, so it gets a compliance-cost axis.

• effort (drafting, anonymisation, sign-off): recap plus retrospective plus transparency report > recap plus retrospective > recap only > nothing published
• value (trust, accountability pressure that makes the fix happen, and a reusable public artifact): recap plus retrospective plus transparency report > recap plus retrospective > recap only > nothing published
• efficiency: recap plus retrospective > recap only > recap plus retrospective plus transparency report > nothing published
• compliance cost (review triggered, reversibility spent): recap plus retrospective plus transparency report > recap plus retrospective > recap only; publishing nothing carries none.

Dominance check: 4 rungs, 6 pairs, zero strict-dominance relations - clean only by construction, and that is not a pass. Value, effort and compliance cost all run in one order: the rung that buys more trust is strictly worse on both cost axes, including against "nothing published," which loses on value rather than winning anything for free. The check catches nothing; what follows is argument.

Efficiency still favors the retrospective: its findings already exist in three-part form by step 8, so the marginal cost is two paragraphs, not new analysis. Publishing nothing ranks last on efficiency despite costing nothing, because zero over zero never wins a ratio, even where it is the correct choice for other reasons.

The compliance ordering is not a rewrite of the effort ordering:

• Recap - exposure is a photo-consent check.

• Retrospective - exposure is contractual: a finding naming a venue or a caterer can collide with a non-disparagement clause and will certainly reach a supplier you want next year.

• Transparency report - exposure is categorically different again: it needs the code-of-conduct pipeline's own sign-off on anonymisation, and a published incident description cannot be unpublished.

• Nothing published - findings stay in the team's log.

• Recap only - what happened, numbers, photos, thanks; no findings. DevOpsDays endorses this much: blogging results is "optional, but strongly recommended."

• Recap plus retrospective (default) - Write the Docs Prague 2017's shape: recap plus a short section naming what went wrong and what changes next edition.

• Recap plus retrospective plus transparency report (starved rung) - full Prague 2017 artifact, adding an anonymised account of code-of-conduct reports and how each was handled. Tops value, effort, and compliance cost, so efficiency never picks it. Promotion condition, keyed to Q10: reports were actually resolved and event-code-of-conduct's pipeline signs off on the anonymisation, or an

...