Five Tips for Sharing a Project Retrospective with Your Whole Company

I recently attended a retrospective led by a team of Atoms who worked on a large project. My colleagues were both vulnerable and knowledgeable as they shared challenges, successes, and hard-won lessons.

Two Atoms from the team shared their process for creating the project retrospective with me. I organized their thoughts into five tips your team can use to conduct a valuable, company-wide project retrospective.

1. Understand the Investment

The presenters consisted of four Atoms who spent a total of 68 hours over three weeks preparing the content. Much of this time took place during a full-day meeting when the team worked together to map out their plans for the retrospective.

Atomic’s leaders opted to make attending the presentation a payable block of time for anyone in the company. Our office coordinators also catered food for the lunchtime meeting. Together, this represented an investment of several thousand dollars, which inspired the presenters to make sure their content was worth the cost of creating and sharing their findings.

2. Strike a Balanced Tone

The project retrospective team discussed how to balance explaining what could have gone better on the project and highlighting the successes. A presentation that patted everyone on the back and skimmed over failures wouldn’t provide much space for growth. The same would be true if the presentation amounted to an hour of self-flagellation. In his excellent blog post on Blameless PostMortems during his time at Etsy, John Allspaw refers to finding middle ground as “balancing safety with accountability.”

The presenters told me that when they thought about their work over the last year, they stepped back and asked, “What could we have done better?” At the same time, those questions prompted them to recognize their accomplishments. They left room for those triumphs in their presentation, along with a discussion of what they would have done differently.

3. Know Your Audience

Our presenters advise other teams to think about who will be attending the presentation. The majority of Atoms are developers, but many of us are non-technical, so this project retrospective delved into both the technical and social dynamics of the project.

One of the presenters told me she focused on sharing human content. She said more than technical knowledge, Atoms learn interpersonal lessons from big projects.

The team also empathized with the audience by scheduling the presentation during lunch and holding it simultaneously in both offices. As a result, almost every Atom attended the presentation.

4. Make it Actionable

Atomic is typically working on a dozen software projects at any given time, and the presenters understood that some lessons from their project may only be relevant to them. To identify useful information, the team first brainstormed on the project’s successes, challenges, and respective lessons. Then they sorted their ideas into broadly applicable and less relevant ones, focusing on the most actionable insights for their hour-long presentation.

A developer told me that because of this, he didn’t end up sharing some of the most interesting lessons from the project. He said it was more important to respect the attendees’ time by making the information shared as applicable as possible.

As they prepared to present, the team also realized they had collected a separate set of findings that were actionable, but only to leaders of the company. Instead of examining those issues in the presentation, the team summarized them in a document for company leaders.

5. Sweat the Format

The presenters agreed that finding the right format to share their message was difficult. Should they present their lessons learned in a list? As a narrative? A chronology? How much time should they leave for questions? Would an hour be enough time for the presentation?

The presenters settled on using a slide deck and taking turns presenting their content as a group. Each member of the team explained a different part of the project:

  1. The first presenter gave the project overview and listed the stakeholders involved, the scope of the project, and its tech stack.
  2. The project delivery lead explained how she prepared for the day the project launched.
  3. A developer led the audience through a chronology of the day of the project’s launch.
  4. Our IT operations manager then shared the steps they took between noticing problems with the product and resolving them. He also shared insights about how he’d prevent those issues on future projects.
  5. Finally, a developer explored the project’s unique infrastructure and its limitations.

One presenter told me she wanted to make the presentation more interactive, and she’ll explore the idea of creating a retrospective workshop in the future.

Vulnerable Teams Build a Culture of Learning

The presenters told me the project retrospective received universally positive feedback. In addition to the money saved by applying lessons learned to future projects, the investment in developing the project retrospective paid off more subtly through increased trust and a culture of learning within our company.

I feel proud to work at a company where we can improve our craft by acknowledging our shortcomings and sharing what we learned by overcoming them.