When I was coming up, we called them postmortems. Some people call them retros or sunsets.
Whatever you call them, it is a review of a project that takes an honest look at what went well and what did not.
A review of a project is not like a review of a person. It’s important for two reasons. One, by gathering a group and focusing on what went well, you both reinforce that behavior and make sure it lodges in the collective memory of the organization. By discussing what didn’t work, you can identify any problems in the process so you can fix them.
Sounds straightforward, right? But many organizations don’t take advantage of this simple step. It’s been a while since I’ve done a Consigliera College where I write up some important basics for mid-career readers. So today I’m going to go over what makes an effective retro.
First, understand where it’s appropriate. A retro is best after a project or sprint where a group works together on something that can be assessed or measured in some way. Since retros have been an established part of development scrums for years, I’m not going to talk about dev, I’m going to talk about other projects that don’t usually get retros.
When I did new business pitches, big or small, I would do a retro after every one. I’ll use that as an example, since I’m so familiar with it, but think of any project in your world that would fit – from a board meeting to a fundraising gala.
Do the retro as soon after the project end as possible. I’d give people a day to recover and then schedule the meeting.
Make it non-negotiable. People don’t like retros. Be clear that no one on the team gets to skip it unless they are ill. Reschedule if need be to get the key team members together. It’s better to hold this meeting in person if possible but it can of course be done on video.
Depending on how large your team is, you might want to make it into two meetings. When I did a pitch with lots of senior executives, some of them in the C suite, I would hold one retro for the senior people and one for the mid-level team who did the bulk of the work. This would free up the team who did the work to talk honestly about challenges. The designer who had to stay up all night because the Chief Creative Officer blew past his deadline by six hours is more likely to tell me that fact in a meeting without the CCO.
I would start the meeting with a clear set of guidelines. First, tell the truth, and tell it all. Second, no one should take any feedback personally. We worked as a team and we’re going to grow as a team. Third, that includes feedback for me, the project owner. If anyone doesn’t feel comfortable sharing something with me, you can tell – insert name of Appointed Deputy Person here. Four – everything in this meeting is confidential. I will talk about learnings to other people, but I won’t say where they came from.
Then I would reiterate why this meeting is important – so we can capture what worked and didn’t work and do more of the good stuff and less of the unskillful stuff.
At this point, especially in the first few, a whole team would be staring at me blankly. They knew the things that went wrong, but they weren’t ready to say them.
I would start with appreciative inquiry, saying the good stuff first. What went well? I would be ready with three of four examples. It can be something small and tactical, or large. I’d get specific and give credit. “Ellen’s project management was fantastic, she stayed calm and collected and held the execs accountable in a really skillful way.”
Capture these. Write them up on a whiteboard. Keep them in a folder you can review before the next project. Get curious. Why was Ellen able to stay so focused? Because Julie took all her other projects and Ellen only had to focus on the new business pitch. Good to know. To recreate those circumstances for the next pitch, you’ll need to make sure the PM team is able to do this again.
Then ask for what didn’t work. Try to get to solutions. If the problem was that Rachel was up all night because the CCO didn’t meet his deadline, you can capture that information and then get to solutions. Heaping scorn on the CCO’s name may feel good, but it’s not helpful. What could we do differently next time? If this is a chronic problem with the CCO, we could give him a fake deadline. (Yes, friends, new business people do this.) How fake does it need to be? 6 hours? 12 hours?
Get tactical. Stay in solutions. Capture everything.
If you, like me, are the project lead and run these retros, you’ll need to work on your own emotional regulation. Sometimes you’ll get feedback that is exaggerated, or misses the reality of your job and responsibilities. It’s not unusual for people – especially executives – to blame the project lead for circumstances outside her control. Try not to react, and don’t argue. The goal of a retro is to get as much information as possible. You can sift it and prioritize it later.
Be clear about what you can and cannot fix. Once, I ran a pitch in which the pitch team of executives decided to go out gambling the night before a pitch, since we had traveled to a place that was within driving distance of a big casino town. They stayed out late, drank too much, and their performance in the pitch presentation the next day reflected it. They sucked. We lost. I had told them the risks of their choice, but they weren’t interested in listening to me. With executives like that, unfortunately, there is little you can do.
At the end of this process, you should have a list of things to make sure you do again and how to repeat them, as well as pitfalls to avoid. Get this list out when you start work on the next project and review the key findings. This will get any new team members up to speed quickly, and start the team off well.
After a few retros, you’ll find that this is an invaluable practice to build effective team dynamics and avoid danger zones.
Because even when we lost a pitch, if we as a pitch team did the best we could, and ran as smoothly as possible, it felt like less of a loss. Losing because you are bested by a better agency is different, at least to me, than losing because your team fucked up in ways that should have been avoidable.