Running Effective Meetings and Retrospectives
A room full of people is one of the most expensive things a project spends — here's how to make sure it's worth it.
Beginner
TopNotchNote
Notes that matter
does this need to be a meeting?
A meeting is interactive communication — the most expensive of the three communication modes, because it requires everyone's real-time attention at once. Before scheduling one, it's worth asking whether the same outcome could come from a push update or a pull-based shared doc instead. A meeting earns its place when it needs a real-time decision, a discussion that genuinely benefits from back-and-forth, or alignment that a written update can't reliably produce.
meeting types in project work
| Type | Purpose |
|---|---|
| Kickoff | Align the team on the charter, goals, and how they'll work together |
| Status / standup | Quick check on blockers, not a detailed status readout |
| Working session | A specific decision needs to be made, with the right people in the room |
| Steering committee / sponsor review | Higher-level checkpoint on direction, budget, major risks |
running a good one
A few habits separate a useful meeting from a wasted hour: a clear stated purpose (ideally, what decision needs to get made), an agenda circulated beforehand so people can prepare, inviting only the people who actually need to be there, someone assigned to capture decisions and action items, and ending with clear owners for whatever comes next — not just "great discussion, let's follow up."
retrospectives: reflecting on how, not what
A retrospective is a dedicated meeting to reflect on how the team worked — not on what got built, which status meetings already cover. A common structure is Start / Stop / Continue: what should the team start doing, stop doing, and keep doing. Held regularly (end of sprint, or at defined project milestones) rather than only once at the very end, a retro is one of the few structured opportunities a team gets to actually improve its own process instead of just repeating it.
Retrospectives only work with psychological safety — people need to feel safe naming a real problem without it turning into blame. The PM's job during a retro is keeping the conversation about the process or system that produced a problem, not about which individual is at fault. A retro that turns into finger-pointing teaches people to only say safe, surface-level things next time, which defeats the whole purpose.
a short example
A team's daily standup had ballooned to 45 minutes because everyone gave a full detailed update to the whole group. The PM restructures it around one rule — blockers only, details taken offline — and it drops back to 15 minutes. In a retro after a rough sprint, the team surfaces that the real issue wasn't any one person's performance but an unclear handoff process between two subteams; framed that way, the team agrees on a specific process fix for the next sprint instead of anyone feeling singled out.
practical notes
If a recurring meeting has no clear purpose or decision left to make, it's a candidate to become an async update instead — a meeting that used to matter doesn't automatically keep earning its slot on the calendar.
A retrospective is wasted effort if the action items from the last one are never revisited. Opening each retro with "how did last time's action items go" keeps the practice from becoming a ritual with no follow-through.