How to Run an Effective Agency Retrospective

Your agency just finished a big project. Everyone's relieved it's over. Now what?

Most agencies move straight to the next project. Which is a missed opportunity.

The retrospective is where you extract learning. Where you figure out what worked, what didn't, and what you'll do differently next time.

But most retros are awful. They devolve into complaint sessions. Or the owner does all the talking.

Or nobody says anything because they're worried about politics. The retrospective becomes theater.

This post covers how to run a retrospective that actually changes how your team works.

Why Retrospectives Matter

They prevent repeated mistakes. If you don't explicitly review what went wrong, you'll do it again. Different project, same problem. You'll keep making the same mistakes indefinitely.

They build team cohesion. A well-run retro shows people that you care about their experience. That you're serious about improving. That feedback matters.

They surface systemic issues. Individual project problems are noise. But when three projects in a row had the same issue? That's a system problem. Retros reveal patterns.

They celebrate wins. Teams need acknowledgment. Retros are a chance to say "we shipped something great. Here's why it worked."

They prevent burnout. Teams that never reflect on what's hard become resentful. Teams that reflect and try to improve feel heard and supported.

Timing

Do the retrospective within three days of project completion. Not the same day (people are tired).

Not two weeks later (details are foggy). Three days is the sweet spot.

Block one hour. Ninety minutes max. If you need more than 90 minutes, you have too many topics or the discussion is inefficient.

Format: Start-Stop-Continue

This is the simplest, most effective retrospective format.

You ask three questions:

1. What should we start doing? (New things to try)
2. What should we stop doing? (Things that aren't working)
3. What should we continue doing? (Things working great)

Spend 20 minutes brainstorming. Everyone writes ideas on sticky notes.

One idea per note. Don't talk yet, just write.

Then spend 40 minutes discussing. Group similar ideas.

Discuss why each came up. What's the underlying problem or success?

Then spend the final time deciding: Of all the ideas, which will you actually implement? Pick 2-3 maximum.

A Better Format: The Four Ls

If Start-Stop-Continue feels bland, use the Four Ls.

1. Liked: What did we like about the project?
2. Learned: What did we learn?
3. Lacked: What was missing?
4. Longed for: What did we wish we had?

This frames the discussion more positively. You're not just listing what went wrong. You're also celebrating what went right.

Liked and Learned get more discussion than Lacked and Longed for. This sets a better tone.

You're not a team of complainers. You're a team that does good work and wants to get better.

Facilitation Techniques

Ground rules first. Tell the team: "This is a safe space. We focus on systems, not people. We're not here to blame anyone. We're here to improve our process."

Normalize silence. Some people think fast, some slow. After you ask a question, sit in silence for 30 seconds. Let people think. If you jump right into discussion, fast talkers dominate.

Go around the room. Don't let discussion devolve into whoever-has-something-to-say. Go around the room. "Sarah, what did you like about this project?" This ensures quieter people participate.

Dig into the why. When someone says "I hated the client communication," don't move on. Ask why. "What specifically was difficult? What would have made it better?" You're looking for the actionable insight, not just the complaint.

Manage the dominator. If one person is talking 80% of the time, gently redirect. "Thanks. Let's hear from someone who hasn't spoken yet."

No fixes in the retro. If the discussion drifts to "so here's how we'll fix this..." stop it. The retro is for identifying issues. The fix comes later in a separate conversation.

Things to Watch For

The all-blame session. One person (usually the client) gets blamed for everything. Redirect to system-level thinking. "Is there a process we could have put in place that would have prevented this?"

The silent majority. Half the team isn't talking. Maybe they're uncomfortable. Maybe they disagree and don't want to say so. Take a break. Approach them privately. "I noticed you didn't say much. Is there something on your mind?"

The unsolvable complaint. Someone complains about something you can't control. The client was demanding. Weather was bad. Budget was small. Acknowledge it, don't dwell on it. "That was a constraint. What could we have done differently within those constraints?"

The ownership trap. Avoid "You should have..." or "Why didn't you...?" This makes people defensive. Instead, "How could we have prevented this?" This makes it about the team and the system.

Implementation

A retrospective that changes nothing is pointless. So at the end, decide what you'll actually do.

Review all the ideas. Ask: "If we could only do 2-3 things differently on the next project, what would they be?"

Pick 2-3. Write them down. Assign who's responsible for making it happen. Set a review date (usually the next retro) to check in on implementation.

Document it. Create a retro summary one-pager that everyone gets. Highlights, decisions, action items.

Common Retrospective Mistakes

Retro for every small project. Only do retros for projects where you can actually learn something. A small support ticket? Skip it. A three-month build? Definitely retro.

Inviting too many people. Keep it to the core project team plus a facilitator. Eight people max. More than that and it becomes a social event, not a working meeting.

Focusing on blame. The goal isn't to figure out who messed up. The goal is to figure out what system failed and how to fix it.

Forgetting to celebrate wins. Retros shouldn't be all complaints. Make sure you're also acknowledging what worked great.

Not following through. You decide to "improve communication" and then do nothing. It's worse than not having a retro because it signals that you don't care about the decisions you make.

Frequently Asked Questions

Should clients be in the retro? No. This is a team-only conversation. Clients in the room change what people say. Do the retro after the client relationship ends.

What if nobody has complaints? That's amazing. Go deeper on the "Liked" and "Learned" sections. What made this project work? How can you replicate that on the next project?

How do we handle sensitive topics (like someone's poor performance)? The retro isn't the place for that. If you need to give feedback to a specific person, do it privately after the retro.

Should we require attendance? Yes. It signals that this matters. If people are optional, people will skip. And if a key person skips, they miss the context.

What if people disagree on what happened? That's normal and good. Different perspectives are valuable. Don't try to reach consensus. Acknowledge the different views. "Some people felt X, others felt Y. Both are valid."

How do we implement recommendations if they require budget? Budget them for the next project or the next quarter. If a retro recommendation is truly important but requires resources, make it a priority.

Should we do retros for failed projects or problem clients? Absolutely. Those are the most important ones. You'll learn the most from your hardest projects.

The best agencies are the ones that systematically learn from every project. That requires retros. And retros only work if they're well-facilitated, safe, and actually lead to change.

Run your retrospectives right, and you'll see your team's quality and efficiency improve noticeably within a few months.