How to Run Engineering Retrospectives That Actually Change Things

The Retrospective That Doesn't Work

You've been in this meeting.

Sixty minutes, the whole team. Sticky notes on a virtual board divided into "what went well," "what didn't," and "action items." Everyone is polite. The same themes come up as last quarter. Three action items are added to a doc. The doc is never opened again until the next retro.

This is theater. It has the form of reflection without the function of improvement.

The problem isn't the format. It's that retrospectives are treated as a ceremony instead of an improvement engine.

What a Good Retro Actually Does

A well-run retrospective does one thing: it changes something about how the team works before the next retrospective.

Not generates insights. Not documents problems. Changes something.

That's a much higher bar than most teams hold themselves to.

Before the Meeting

Gather data first. Don't walk in cold. Before the retro, share a lightweight prompt with the team: "What's one thing that slowed you down this sprint? What's one thing that worked well?" Async, low-stakes, 5 minutes. People arrive having thought about it.

Pick a specific focus. A retro that covers everything covers nothing. If your deploy process was painful this sprint, make that the topic. Narrow scope produces specific actions.

Rotate the facilitator. If the same person runs every retro, you'll optimize for their blindspots and comfort zone. Rotate quarterly. The person who least wanted to facilitate usually runs the most honest meeting.

During the Meeting

Spend 10 minutes max on "what went well." This matters for morale, but it's not where change happens. The improvement-oriented discussion needs the time.

Name patterns, not incidents. "The deploy on Tuesday broke staging" is an incident. "Our deploys break staging about once a week, and we don't know why" is a pattern. Patterns get fixed. Incidents get sympathy.

Push for root causes. When something went wrong, ask why until you get to something actionable. "CI was slow" → "why?" → "tests are unparallelized" → "why?" → "nobody has prioritized it" → "how long would it take?" → "two days." Now you have an action item worth taking.

The five-whys technique is blunt but effective:

Problem: We shipped a bug that broke the export feature.
Why? It wasn't caught in QA.
Why? QA only runs happy-path tests for exports.
Why? Nobody wrote the edge case tests.
Why? Edge cases weren't documented in the ticket.
Why? The ticket template doesn't prompt for them.

Fix: Update the ticket template.

Timebox ruthlessly. A retro without a timekeeper drifts into a general venting session. Keep a visible timer. Move on when time is up, not when the discussion is exhausted.

The Action Item Problem

Most retro action items fail for three reasons:

1. Too vague: "improve communication" is not an action item.
2. No owner: "the team" will do nothing.
3. No deadline: undated items are wishes, not commitments.

A good action item has a verb, a name, and a date. "Marcus will add edge-case prompts to the ticket template by next Wednesday." That's an action item.

Limit yourself to two or three per retro. Three real commitments are better than ten intentions.

Following Up

At the start of the next retro, spend five minutes reviewing the action items from last time. Did they happen? If not, why not?

This is the discipline that most teams skip and most teams need. Without accountability, the retro is a journal entry: honest, private, and without consequence.

A running doc (or a section in your team wiki) of past retro actions and their status creates organizational memory. You can see whether your improvements are holding or regressing.

The Long-Term Payoff

Teams that run retrospectives well don't just get better at specific things. They develop a shared vocabulary for naming problems early, a habit of structured reflection, and, importantly, evidence that raising problems leads to solutions.

That last part is the hardest to build and the most valuable. When people believe the retro changes things, they bring their real problems to it.

When they don't, they sit politely through the theater.

The difference is follow-through. Show it once, and people start to believe.