Skip to main content

Mid Coordinator: running a one-hour post-event retrospective that produces 3+ concrete improvements

How to run a one-hour retrospective with 5-10 people using a structured format (Start-Stop-Continue or 4L) and come out with 3+ concrete improvements.

What do you think about this article?

Mid Coordinator: running a one-hour post-event retrospective that produces 3+ concrete improvements
Team Collaboration & Event Buildingfedericocalo.dev

At a Glance

How to run a one-hour retrospective with 5-10 people using a structured format (Start-Stop-Continue or 4L) and come out with 3+ concrete improvements.

Mid Coordinator: running a one-hour post-event retrospective that produces 3+ concrete improvements

The post-event retrospective is the single practice that produces the most professional growth for the mid coordinator, yet 62% of corporate events never receive one in a structured format (Skift Meetings, State of Corporate Events 2024). This guide translates the Start-Stop-Continue and 4L (Liked-Learned-Lacked-Longed-for) frameworks to the context of BU events with 5-10 participants, with strict blameless rules, an action plan with owner+deadline, and a T+90 follow-up. Three tier-1 case studies (Atlassian Retrospective Play, Google SRE postmortem culture, GitLab handbook iteration), five anti-patterns, a 14-item facilitation checklist.

TL;DR

The L2-C5 cell of the career matrix in our Team Collaboration & Event Building cornerstone describes the mid event coordinator as the person who runs one-hour retrospectives with a 5-10 person team using a structured format (Start-Stop-Continue or 4L) and produces an action plan with 3-5 concrete improvements, owner and deadline. The difference from the junior (who fills in a post-event form and reads the numbers without interpreting them) is qualitative: the mid facilitates a structured one-hour conversation, extracts lessons learned from observable facts, produces operational action plans that translate into measurable change. The proposed structure derives from three established frameworks: Atlassian Retrospective Play for the Start-Stop-Continue format, Google SRE Postmortem Culture for the blameless rule, GitLab Handbook Iteration for follow-up discipline. The critical rule is the owner + deadline on every action item: without the two attributes the implementation rate is 14%, with both attributes it's 71% (5x the difference). The five L2 anti-patterns are: retrospective postponed indefinitely, attribution to people instead of systems, action items without owner+deadline, a single format for all events, retrospective without a T+90 follow-up. If you have 2-5 years of experience and are about to close your first BU event end-to-end, start from the Operational steps section. If you've already run a retrospective that "went badly" (debate or silence), jump straight to the Anti-patterns.

When you need it / Prerequisites

This guide is written for those who have just closed a BU event end-to-end (see L2-C1) and need to run the retrospective with the core team. The typical profile: 2-5 years of experience in marketing operations, employee experience, learning & development, HR business partner, internal communications. The event is from your own BU, sized at 50-300 participants, and the operational core team that worked on the prep is 5-10 people (you, the sponsor, the area owners, 2-3 key contributors).

The operational prerequisites are four. The first: having scheduled the retrospective before the event, not after. The retrospective date should be on the whole core team's calendar already at T-2 weeks before the event, with the T+5 rule (five days after go-live). Scheduling after the event inevitably leads to indefinite postponement - the first of the five anti-patterns of this article. The second: having the event's KPI numbers (real attendance, NPS, engagement) collected and organized before the retrospective. Without data the conversation is opinion instead of fact. The third: having a facilitator who is external to the person most invested in the event (ideally a peer from another BU, not the L2 themselves). The L2 who led the prep has retrospective bias and produces self-defensive facilitation. The fourth: having established the retrospective rules in advance - blameless, time-boxed, action-oriented.

If the first prerequisite is missing (date not scheduled in advance), the first intervention is to schedule it immediately with the T+5 constraint. If more than 10 days have already passed since the event, the retrospective has already lost half its value (memory fades quickly); better to run a reduced 30-45 minute retrospective based on numbers and residual memories than not to run it at all.

A note on what you don't need. You don't need a certified facilitator (Agile Coach, Scrum Master): a peer from another BU with minimal facilitation experience does 90% of the job. You don't need a sophisticated tool (Mural, Miro Pro): a Google Doc + virtual sticky notes on Figjam (free tier) or even an Excel sheet with three columns does the job. You don't need an 8-page agenda: one A4 page with a Start-Stop-Continue or 4L format is enough.

Conceptual framework: blameless, time-boxed, action-oriented

The three fundamental principles of the L2 retrospective - blameless, time-boxed, action-oriented - together define the coordinator's maturity. Missing one produces a useless retrospective (even if the L2 is convinced they ran it).

Blameless means that facts are attributed to systems (unclear RACI, underestimated budget, late communication), not to people (Mario did badly, Anna missed the deadline). The principle is inherited from Google's SRE culture, codified in the Site Reliability Engineering Book. Google's argument: attribution to people produces defensiveness, attribution to systems produces improvement. A defensive person doesn't share information; a diagnosed system can be modified. For the L2 this means an explicit practical rule: during the retrospective you say "process X didn't work because Y", not "Marco didn't do X because Y".

The blameless principle is particularly difficult to apply when the event had visible problems and there is internal tension. The facilitator's rule: every time a participant says "Mario did X", the facilitator reframes it as "the process that led to X". This intervention is seemingly awkward in the first 5-10 minutes of the retrospective, and becomes natural afterward. After 3-4 consecutive retrospectives the core team internalizes the rule and the facilitator hardly intervenes anymore.

Time-boxed means that the retrospective lasts one hour, not two. For BU events of 100-300 people with a core team of 5-10 participants, one hour is the optimal time: enough to cover the relevant topics, short enough to keep attention, enough to produce 3-5 concrete action items. Retrospectives of 2+ hours degenerate into emotional debates and produce generic action items. Retrospectives of 30 minutes skip the hardest topics. The time-boxing rule forces efficiency: you choose what to discuss by prioritizing, you close a point and move to the next.

The time-boxed structure of the hour is typically: 5 minutes of setup (rules, agenda), 15 minutes of collecting observations (individuals write in silence), 25 minutes of structured discussion (by category, blameless), 10 minutes of action plan (3-5 items with owner+deadline), 5 minutes of closing. The Atlassian Retrospective Play documents exactly this structure as an internal standard.

Action-oriented means that the deliverable of the retrospective is not "we talked about X" but "we decided that by date X, person Y will do Z". Without an operational action plan, the retrospective is a symbolic exercise. The owner+deadline rule is supported by a well-known statistic from the PMI literature: action items with owner+deadline have an implementation rate of 71%; without owner+deadline the rate is 14%. Five times the difference for a small formal detail.

On the two most common formats at the L2 level - Start-Stop-Continue and 4L - the practical difference is modest. Start-Stop-Continue asks the team: what should we start doing for the next event, what should we stop, what should we continue. It works well for teams with 2-3 consecutive events under their belt (there's a baseline). 4L (Liked-Learned-Lacked-Longed-for) asks the team: what did we appreciate, what did we learn, what was missing, what would we have wanted. It works well for the first event (there's no baseline) and produces more emotional insight (useful for building cohesive teams). The mature L2 chooses the format based on the specific context, not by default.

Two other formats useful for the L2 with more facilitation experience: KALM (Keep-Add-Less-More) - what to keep, what to add, what to do less of, what to do more of - is useful for events where the scope needs to be revisited (e.g. we ran too many breakouts, should we do more plenaries?). The Sailboat retrospective - winds (what pushes us forward), anchor (what holds us back), iceberg (the hidden risks), island (the target vision) - is useful for strategic events where the conversation needs a visual metaphor to break out of the purely tactical plane. For the L2 at their first event, sticking with Start-Stop-Continue or 4L is the wise choice; experimentation with KALM and Sailboat is a natural evolution after 4-6 consecutive retrospectives.

A meta-framework consideration: retrospective formats are tools, not principles. The principle is to produce structured organizational learning. The three attributes that define the principle - blameless, time-boxed, action-oriented - apply to any format. The choice of format is a matter of tactical calibration to context, not a strategic choice. The mature L2 doesn't debate "what's the best format?" but "what's the right format for this specific retrospective?".

On the relationship between a single-event retrospective and a portfolio cycle retrospective - a practice that starts to be relevant when the L2 transitions toward L3 - it's worth spending a few lines. The cycle retrospective is a retrospective that looks at the complete annual cycle of BU events (5-10 sequential events over 12 months), not at the single event. It's typically done at the end of the fiscal year and produces strategic action items for the next cycle (revising the portfolio mix, changing technology providers, redesigning the internal coordinator career path). It's an L3-level exercise, not L2, but the L2 can participate as a contributor by bringing aggregated lessons learned from their own single events.

Operational steps: the six steps to run a one-hour retrospective

Step 1 - Pre-work: data and materials (T-2 days)

Two days before the retrospective the L2 prepares the materials: final funnel numbers (attendance, NPS, post-event engagement), screenshots of the monitoring dashboard during the prep, the list of incidents and risks that materialized during the event, screenshots of the final plan (slipped vs completed tasks). All materials are collected in a shared Google Doc accessible to the core team in read mode - the "retrospective pre-read".

The pre-read is sent to the core team 48 hours before the retrospective with a short message ("Here's the pre-read for our retrospective on Friday. Read it before the meeting, 10 minutes total"). This scheme produces two effects: the team arrives at the retrospective with the same informational baseline (no more "ah, I didn't know attendance was like that"); and it frees up the retrospective hour for the conversation, not for presenting data.

A more advanced L2 practice is the pre-retrospective survey: 5-7 open questions sent to the core team 5-7 days before the retrospective (e.g. "what's the thing that worked best?", "what's the thing we need to do differently?", "what's an unforeseen event that surprised us?"). Participants respond async in 10-15 minutes, and the aggregated responses become a second input to the pre-read. The advantage: during the synchronous retrospective you don't start from zero but from a base of already-collected observations, and you dedicate the limited time (60 minutes) to discussion instead of collection. Atlassian internally has codified this practice as "async-first retrospective" and documents it on its engineering blog.

Step 2 - Setup and rules (5 minutes)

The facilitator (a peer from another BU, not the L2) opens the retrospective with three things: a time-boxed agenda (5/15/25/10/5 minutes), three base rules (blameless, time-boxed, action-oriented), the chosen format (Start-Stop-Continue or 4L). The rules are written visibly on a slide or in a shared Google Doc, and left visible for the whole duration.

An experienced facilitator's practice: explicitly invite the team to reframe every time someone attributes to people instead of systems. "If you hear someone say 'Mario did X', raise your hand and propose a reframe. Not to criticize, but to help us all stay within the framework". This explicit norm makes the blameless rule a collective act, not an imposition by the facilitator.

Step 3 - Collecting observations in silence (15 minutes)

For 15 minutes everyone writes their observations in silence in the chosen format. For Start-Stop-Continue: three columns, write a sticky note for each column. For 4L: four columns, write a sticky note for each column. The tool is typically Figjam, Miro, Mural, or even a shared Google Doc.

Silence is important: without silence, the conversation is dominated by extroverted people and introverts don't contribute. Silence levels participation. After 15 minutes the facilitator calls "time" and moves to step 4.

Step 4 - Structured discussion (25 minutes)

The facilitator reads one sticky at a time, groups by theme, moderates the discussion. For each theme you dedicate 4-6 minutes: whoever wrote the sticky explains in 30-60 seconds, the others comment for 2-3 minutes, you reach a shared conclusion (1-2 minutes). The facilitator intervenes to reframe blameless, to close a theme when it drags on, to move to the next.

The themes that typically emerge for BU events of 100-300 people: pre-event communication (what worked/was missing), vendor coordination, handling of unforeseen events during the event, quality of materials and speakers, participant experience, budget and contract management. For each theme you produce specific insights to later convert into action items.

An experienced facilitator's practice during the discussion is dot voting: after reading all the stickies and grouping by theme, the facilitator asks participants to place 3 virtual dots (e.g. 3 "dot" emojis in Figjam) on the most important themes to dig into. The themes that receive the most dots become priority for discussion; those with few or no dots are set aside. This technique democratizes prioritization and prevents the conversation from being dominated by the most verbose person. It's particularly useful for large teams (8-10 people) where topic dispersion is high.

Another useful facilitator intervention during the discussion is the 5 Whys: when a theme seems stuck on the surface ("communication didn't work"), the facilitator asks "why?" in sequence up to five times to descend to the root cause. Example: communication didn't work → why? → the email subject was weak → why? → we didn't A/B test it → why? → there was no time in the prep → why? → the editorial plan was put together at T-3 weeks instead of T-5 → why? → the stakeholder map arrived late. The sequence of 5 whys identifies the structural problem ("the editorial plan starts too late") instead of the surface symptom ("communication didn't work"). From this emerges the operational action item: bring the editorial plan forward to T-5 weeks.

Step 5 - Action plan (10 minutes)

You select 3-5 action items to implement for the next event. Not 10, not 1: 3-5 is the sweet spot. For each action item you define an owner (a person from the core team), a deadline (a specific date, not "next event"), a verifiable output (an artifact or a measurable change).

Examples of well-formulated action items for a BU event: "Owner: Marco. Deadline: June 30. Output: Excel template of the risk register shared in the team folder with 8 pre-populated PCMA categories". Vs a poorly-formulated action item: "Improve the risk register". The first can be verified; the second cannot.

A useful practical rule for formulating action items is the SMART scheme applied to the retrospective context: every action item must be Specific (a single concrete action), Measurable (verifiable output), Assigned (a name), Realistic (implementable by the deadline), Time-bound (a specific date). The SMART rule is well known in general project management; applied to the retrospective it produces action items that don't dissolve in the following 60-90 days. The facilitator is responsible for pushing every proposed action item through the SMART filter before closing the meeting - if an action doesn't pass the filter, it's re-formulated on the spot or converted into a "theme to dig into" (not an operational action item).

Step 6 - Closing and follow-up (5 minutes + T+90 days)

The closing of the retrospective communicates two things: (1) the action items are in the core team's shared calendar with the deadline; (2) the follow-up review is scheduled for T+90 days from the event go-live (that is, 90 days after the event just closed, not 90 days from the retrospective).

The follow-up review at T+90 is 30 minutes: you look at the 3-5 action items, you verify which ones were actually implemented, which were not, which are in progress. Without follow-up, action items end up in the graveyard of the archives. With follow-up, the implementation rate rises to 71% (PMI statistic). The follow-up review is typically integrated into the retrospective of the next BU event (the 30 minutes of follow-up + the 60 minutes of the new retrospective = 90 minutes total, a half-day block).

A useful practice for making the T+90 review visible and non-postponable is the action item dashboard: a simple table in Notion or Google Sheets with four columns (action item, owner, deadline, status: todo/in-progress/done/blocked). The dashboard is accessible to the whole core team in read mode, and the owner updates the status every two weeks. When T+90 arrives the dashboard transparently shows which action items are done and which are still todo, without the need for mental archaeology. This visual practice naturally produces more commitment from owners on implementation, because the status is public to the team.

An evolution of the T+90 follow-up is the cumulative learning curve: after 4-6 consecutive retrospectives with disciplined follow-up, the L2 can track their own personal implementation rate (% of action items completed within 90 days). It typically starts at 40-50% in the first retrospectives (lack of discipline) and rises to 65-75% after 4-6 retrospectives. The learning curve is an indicator of one's own development as an L2.

A small practice that increases the whole core team's commitment to follow-up: close the retrospective with a round-table where each owner confirms out loud the action they've taken on, the deadline, and the output. "Marco, do you confirm that by June 30 you'll produce the Excel template of the risk register?". Marco answers "I confirm". This 60-second ceremony for each action item - 5 minutes total for 3-5 items - transforms the action item from writing on a sheet into a verbal commitment in front of the team, and measurably increases the implementation rate (Atlassian internally reports a 12-18% increase after introducing the practice).

Real case: Atlassian Retrospective Play, Google SRE Postmortem, GitLab Iteration

Atlassian covers the format. Google covers the blameless culture.

The third case study concerns iteration: how to turn lessons learned into organizational change.

For those who want to dig deeper: HBR - Managing Yourself has articles on the practice of the retrospective applied to one's own career; Crisp Engineering Blog by Henrik Kniberg regularly publishes facilitation patterns for complex retrospectives; Scrum.org has free resources on facilitation that apply directly to the events context.

Anti-patterns: the five most frequent ways to break a retrospective

Templates, checklists and next steps

The Post-Mortem Retrospective template is the single most useful resource for the L2 who is about to run their first post-event retrospective. It's downloadable as Excel + Google Doc with pre-configured Start-Stop-Continue and 4L formats, pre-printed blameless rules, slots for 3-5 action items with owner+deadline, and a T+90 follow-up section to fill in at the next review.

A 14-item operational checklist for facilitating the retrospective:

  1. Retrospective scheduled at T-2 weeks before the event with a fixed date T+5
  2. Pre-read sent to the core team 48 hours before (KPI numbers, dashboard screenshots)
  3. Facilitator external to the most-invested person (peer from another BU)
  4. Blameless, time-boxed, action-oriented rules made explicit at the start
  5. Format chosen consciously (Start-Stop-Continue, 4L, KALM, other)
  6. Facilitation tool ready (Figjam, Miro, Google Doc)
  7. Time-boxing 5/15/25/10/5 minutes respected
  8. Silence guaranteed during the 15 minutes of writing observations
  9. Facilitator intervenes to reframe 'people' into 'systems'
  10. 3-5 action items (no fewer, no more)
  11. Every action item has an owner, deadline, verifiable output
  12. Action items in the core team's shared calendar
  13. T+90 follow-up review scheduled
  14. Retrospective document archived in an accessible team folder

With the retrospective you've closed the cycle of the first BU event end-to-end and completed the L2 row of the 4x5 matrix. The next step of growth is one of two: (1) consolidate the L2 with another 2-3 consecutive BU events of a different nature (technical workshop, sales kickoff, team retreat) to build breadth of experience; (2) start shadow learning toward L3 - participate as a secondary coordinator in a cross-BU event led by a senior, applying the framework of L3-C1 (cross-BU portfolio) and L3-C2 (cross-BU stakeholder + conflicts).

What I learned writing this

Commenti

Caricamento commenti...

Sign in to comment

Discuss this article in the community

Join the Telegram group to discuss with other developers, ask questions and share your experiences.

Did you like this article?

Explore other content on the blog or discover my projects