You’ve just finished a big project, and everyone’s heads are swimming. You know things didn’t go perfectly, but at the end of the day you shipped on time. You’re feeling pretty good... and then your project manager schedules a post-mortem.

Post-mortems – or Retrospectives – are not something to dread. They are a critical step in growth and development, as well as essential to an organization or team maintaining its health. They provide a moment to look back and learn from where you’ve been before taking the next step forward. In fact, at SpiderOak, we run a retrospective not only at the completion of major milestones and resolution of failures but also at the end of each and every sprint.

Our retrospectives are broken down into three steps. As I may have mentioned before, we use the Atlassian stack so if you do, too, you may see familiar vocabulary. Atlassian actually has a retrospective template you can use if you don’t want to re-invent the wheel.

What went well?

It’s important to start with the good. A well-used retrospective happens at the end of a project or time-boxed chunk of work. Your team has just completed something! Give yourselves a minute to celebrate! Bonus: if you start by focusing on what went well, everyone will be more inclined to participate in the conversation. (Imagine showing someone a project you’re proud of having their first response be to show you how it could be improved. Do you really want to continue the conversation at that point?)

What could have gone better?

We find this phrasing is more productive than “what went wrong?” or “what did we do poorly?” See again how you feel when your work is criticized, however constructively. This part of the retrospective usually takes a bit longer. Identifying what could have gone better ought to lead to a discussion on how to improve it, which takes us to the final step.


Based on the “what could have gone better” discussion, you should end up with specific actionables. Do your best to record these items so that it is very clear what the team decided on. “John will work with Ops to improve the staging environment”, or “Simone will be the documentarian next round” should be written down in the retrospective notes page. Actionables should be carried out as quickly as possible. We find it's actually really useful to start a sprint retrospective by looking at the previous sprint’s retrospective notes. Revisiting that document’s actionables before beginning the new discussion is intended to make sure we hold ourselves to at least try out the ideas we’ve come up with to make our lives easier. We definitely have some retrospective notes floating around that read: “We’re still struggling with X, but that’s because we did not action our proposed solution from last sprint. We'll implement that this round”.

Things to Consider

Retrospectives only work if they are a group discussion. If you are trying retrospectives for the first time, it can help to have an assigned person running the retrospective. The leader should do everything within their power to foster discussion with the rest of the team as well instead of opining on what they think should change. That person may want to prepare for the retrospective by having one “went well” and one “room for improvement” item in their back pocket in case the room is very quiet. Another discussion fostering trick is to turn the “room for improvement” on yourself, especially if you’re in a managerial role on this team. It’s hard to criticize your team or teammates. Saying something like, “I could have communicated the reasons behind our scope change more clearly” can open the door for others to speak up. Bonus points if you can follow up with a direct request for participation such as, “does anyone have suggestions for the best way to communicate changes?”. (If you're a leader trying to foster an open communicative atmosphere, you may want to read up on psychological safety.)
If your team has been doing retrospectives for a while, try rotating whose job it is to run the meeting. Sometimes realizing what it looks like from the driver’s seat can motivate people to speak up when they’re in a participant role.

Retrospectives are all about improving your process and communication. The goal is less to praise yourselves (although this has value too!) or let off steam about what’s not going well (again, there’s some value here) and more to get everyone on the team thinking and sharing in order to make small shifts in your strategies that will have lasting impact. If you’re in a managerial role on this team, try using the retrospective as a time to listen instead of a time to steer. And remember; retrospectives work best when there is trust. If someone brings up a seemingly trivial item they’d like to see improved, do what you can to resolve it. Sometimes small asks are a subconscious way to test the waters and see if larger asks will be welcomed down the line.