Event Retrospective

The step that turns a one-off into a program. Run it inside a week, while it is still accurate, with the whole team.

When to use

• Within seven days of any event. Sooner is better
• Before committing to a repeat
• After a series, looking at the pattern rather than one instance

Inputs

• Reads: workspace/measurement/<event>-scorecard.md, the plan, the run of show, the meeting tracker
• Needs from user: the whole team's input, including the executives who attended. A single-perspective retrospective is a draft, not a retrospective

Workflow

1. Open with the bottom line

Two or three sentences that say what actually happened, before anyone gets defensive. Something like: solid operational execution at planned budget, light pipeline payoff because the audience machine was single-threaded on one person and no fallback existed.

Getting the headline right in the first paragraph is what makes the rest of the document useful. It also stops the retrospective from becoming a list of small grievances.

2. Run the three sections

What worked. Specific and reusable. "The venue" is not a finding. "The co-host's preferred vendors saved ten hours of vendor wrangling and the quality was vouched for" is a finding somebody can act on next time.

What did not. The honest list, including the things nobody wants to raise. Push past the operational into the structural: a late speaker is a symptom, a speaker pipeline with no vetted backups is the cause.

What to do next time. Concrete, owned, and dated. Each item is a change to a mechanism, not an intention to try harder.

3. Name the mechanism, not the person

The most important rule here.

An invite list that never got filled by a busy executive can be written two ways. As a bandwidth problem belonging to that person, which produces an awkward conversation and no change. Or as a systems problem: there was no parallel track, no deadline, and no fallback, and the design assumed capacity nobody confirmed. That version produces a hard deadline, a backup list, and a different outcome.

Write the second version. Always.

4. Cover the standard failure points

Ask about each explicitly, because they recur across almost every event:

5. Decide the repeat, with the number

Not a feeling. Cost per qualified meeting against the alternatives, plus what would need to change.

Three outcomes: repeat as is, repeat with named changes, or do not repeat and here is what we do instead with the money. The third one needs the alternative attached or it will not stick.

6. Convert it into a recurring play if it earned it

The comparison worth doing explicitly: a curated executive dinner at a modest per-event cost, run eight times a year, against a single large conference sponsorship at a similar annual number. Frequently the recurring small format wins on cost per qualified meeting by a wide margin, and it compounds because the guest list gets better every time.

If it becomes recurring, write the play down: the format, the cadence, the budget per instance, the owner, and the standing rules. That document is what makes the second one cheaper to run than the first.

7. Lock the co-host or partner while the goodwill is fresh

If a partner or co-host was involved and it went well, ask for the next one in the week after. The relationship is never stronger than it is right then, and six months later you are starting the conversation cold.

8. Feed it back into the system

Update the target list with attendance and outcomes. Update the charter's standing rules with anything learned. Update the budget model with actuals. A retrospective nobody acts on is a document.

Output

• Writes: workspace/events/<event>/retrospective.md from templates/retrospective-template.md
• Prints: the bottom line, the three sections, the repeat decision with the number, and the changes with owners and dates

Rules & quality bar

• Inside seven days. Accuracy decays fast
• The whole team, including executives. A single-perspective retro is a draft
• The bottom line goes first
• Name the missing mechanism, never the person
• Every "next time" item is a mechanism change with an owner and a date
• The repeat decision carries a number and an alternative
• Feed the outputs back into the list, the charter, and the budget model

Related skills

• Reads: event-measurement, the format skill, run-of-show
• Feeds: event-program-setup, audience-machine, event-budget
• See also: docs/field-notes.md note 11