How we run project retrospectives at Intercom

One of the first things that struck me when I started working at Intercom was the culture of transparency and how every team is constantly striving for improvement.

One of Intercom’s core values is that we’re serious about wanting to be the very best. One of the things we can do to implement this value is to be open and honest with each other about our strengths and weaknesses, with a willingness to learn and always keeping in mind that we can do better next time.

The definition of insanity is doing the same thing over and over again, but expecting different results.

That’s why you’ll find us actively seeking feedback on our work every day. Intercomrades are generous with their time and ideas in a genuine effort to help others improve. We share feedback with each other all the time, not just for bi-annual or annual reviews. We want to keep getting better and our feedback loop is a really important part of this.

At the same time, we move fast at Intercom. We’re always focused on the next goal so it can sometimes happen that we don’t take enough time to reflect on the things we’ve done really well and what we haven’t done so well. Retrospectives (retros) are a tool we use to reflect on how we’ve worked together and how we can improve for the future.

There are a few different types of retros at Intercom at different levels of teams and they form an integral part of team planning. Those retros happen weekly within the Product teams and Brand Design and Product Design also hold their own retros.

What I’m focussing on here are project-specific retros. These happen when we have large cross-functional projects involving multiple teams and often multiple office locations in various time zones.

Project retrospectives

As we grow our company, we’re constantly evolving our processes. Actually, we’re not big on heavy processes at Intercom but we do put frameworks in place to help guide us and we’re always iterating on them. What worked for us three months ago might not work for us now or in the future. Added to that mix are teams located in different time zones and on different continents, so there’s always going to be scope for improvement.

Building software is never a perfect process and that’s okay. Without retros it would be hard to take learnings from what hasn’t gone so well and to figure out ways to work better together next time around. As the saying goes, the definition of insanity is doing the same thing over and over again, but expecting different results. That’s where retros come in.

Running your project retro

The aim of any retro is to learn. You want everyone in the room to feel that they can voice their honest opinions and experiences from the project and by the end of it all, everyone will have an increased insight into what worked, what didn’t work and how things can be done differently next time.

At Intercom, these are some steps we take to ensure we get the most out of our retros.

1. Get the right people in the room

Anyone who worked on the project should be in the room – designers, engineers, product managers. Make sure each function is represented. There’s no point running a retro with only half the voices you need in the room. I always gather a list of key people who I know definitely need to be present and reach out to them to see if there are other people on their teams they’d like to attend as well.

2. Ask for input before you begin

I use FunRetro to gather input in advance and usually ask for three types of input – things that made us Glad, Sad and Mad. This allows you to use the time in the meeting to actually discuss the issues at hand, not for gathering feedback. It also gives everyone visibility into how others are thinking and allows the group to focus on the most important areas. The time when everyone is gathered in the room is both extremely valuable and extremely expensive, you want to get the most out of it.

3. Stick to the point

Lots of things happen in the course of a project and they’re not all related to how teams or groups work together. In other companies, I have seen retros deviate away from what actually happened during the project to more general work-related issues that weren’t specific to the project. This is bad and something I’m very conscious of now in my current role. So as the facilitator, you need to steer things back on topic if you see this happening. The time at the retro is to discuss what happened during the project, how the group worked and how the group can work better together in future.

4. It is a democracy

Everyone’s opinion should be heard in the retro. One thing I have found to be useful is asking people to vote on the issues they want to talk about. Start with the issue that received the most votes and try to discuss at least three more items. If 25 minutes go by and you’re still discussing the first item, try to steer the discussion towards an action or solution and move on.

5. Be open and honest

It’s vital that everyone in attendance at a retro feels that it is a safe space and is comfortable sharing their viewpoints. Everyone should strive to be open and honest but never accusatory. Remember that you’re all in the room because you care about a common goal. You’re all on the same team.

6. Actions and owners

Have an action to take away and an owner for each item discussed. This is a good way to draw a line under an item and it focuses the group on problem solving instead of complaining. Of course, a little bit of complaining is to be expected and that’s fine – just not for the whole retro.

7. Get consensus

Get consensus from the group on actions. If everyone doesn’t agree, I generally go with the the majority. You should always make sure everyone knows that if the action or solution doesn’t work out, it can be reviewed again and changed in the future.

8. Keep to the time limit

Everyone is busy. In my experience, you should try to start wrapping up five minutes before the allotted time is over. I’m not a believer in retros that take half a day, I do mine in an hour. I find it’s hard to keep focus once it goes over the hour and it’s a huge chunk of time to take out of anyone’s day.

After the retro

When the retro is over, I always share the outcomes and lessons learned by email with the rest of Intercom R&D. The mail clearly states who was at the retro, what we discussed and what the action items were. I also include a link to all of the items that were contributed but weren’t discussed.

Sharing the outcomes widely gives everyone visibility.

In my experience a group will often focus on more negative things in the retro because that’s where the opportunities for learnings are. That’s totally fine but it’s important to remember that lots of good things also happen during a project and they should be acknowledged at this point too. Where things haven’t succeeded, it’s important that we learn why so we can change our process for the next time.

Sharing the retro outcomes widely gives everyone visibility into the issues encountered and what has been taken from that. At Intercom, we embed the lessons we’ve learned into our frameworks wherever we can. After all, it’s pointless if you forget about what was learned as soon as you walk out of the retro.