Creating a High Trust Retro for Your Next Project

Your most recent project is over, and there are wins and misses. How do you create a retro that gets to the heart of the matter?

Your most recent project is over, and while you’re celebrating completion, there are questions left unanswered. You want to know what happened to delay that launch, why we missed a proposal deadline, or how we released a less-than-lovable set of product features. So the going idea is to hold a “retrospective” on the project — to call all of the participants to the conference room and talk about what happened, where we missed the mark, and how we’ll never ever make that mistake again.

Retros are often framed in the context of learning and ‘growth mindset,’ and with a great plan in place, it can be exactly that. But a few pitfalls can actually make retros contribute to lower trust ,among teams and lower performance in an organization — the exact opposite of what you’re trying to achieve with the practice. So how do you ensure a high trust retro that improves future performance?

What is a Project Retrospective?

A project retrospective (retro!) is a regularly occurring in a business cadence that takes place at the completion of a project. The attendees should include all active project participants and all project stakeholders and decision-makers. A retro should occur as quickly after the completion of a project as possible, so as to maximize learning while it’s fresh!

Why Do a Project Retro?

The goal of a project retrospective is to get the participants of a project together to build a common understanding of the successes and challenges of that work, so that everyone can learn and improve upon the next one.

To be succinct: the problem we’re trying to solve with a project retro is that of shared ownership of a project’s result and shared understanding of how to improve future performance.

A Good Retro is a High Trust Engagement

To accomplish these two primary goals, retros need to be high-trust engagements. That means the participants must come in on a generally equal playing field (an executive doesn’t get more air time or have their opinion count more than a project manager in the room) the space needs to feel safe to offer opinions, the truth needs to be told about the results of the efforts, and there should be no “elephants in the room” — no big looming issues or questions that are being left unsaid — at any point.

Why does it matter if the retro is “high trust”? The reason is because trust creates willingness to change. When we feel threatened, we will either fight or flee. If a retrospective feels like a “calling to the carpet” for any person or team; or like a “let’s all get together and talk about why it’s obvious that development was the reason we missed our deadline,” participants will likely either a) get defensive or b) get out of there (physically, or even just mentally checking out). When this happens, it’s doubly frustrating for participants — everyone feels frustrated by unresolved issues for the project, and everyone feels afraid of messing up the next one. No bueno.

A few little tweaks can help create a high trust atmosphere. Here we go.

Guidelines for a High Trust Retro

Creating an atmosphere of high trust isn’t about holding hands and doing trust falls. A “high trust” retro should be a rigorous review of the project, with participants taking clear ownership for execution that needed improvement, and with stakeholders taking clear ownership for changes to scope or expectations. There should be room for celebration, as well as accountability; learning, as well as clear planning for future success. Here are a few things that will help everyone take the best next step.

#1: Always do them, and use the same exact format every time.

One of the best ways to create trust is to ensure that everyone knows what they’re getting into every time they walk into a retro. So, from the beginning, do a retro for every project (over a certain size, perhaps) and use the exact same questions every time. Definitely make sure to not just do retros when the result is less-than-ideal. This will have two results: 1. People will be afraid when a retro is called. And 2. Successful projects will not get proper celebration and learning, which is demotivating for everyone.
When it comes to asking the same questions every time, some of those questions will feel difficult at your first retro. But if you set it up as “hey, so some of these are hard questions, but they’ll get easier every time!”, you’ll see trust in the process. When people know what to expect in the retro, and like there won’t be a new section of questions or discussions at the next one, they’ll be more likely to open up and offer honest feedback. It means that even if you’re in the hot seat this month, you know that it’s just part of the established process, not a personal attack on you or your work.
Ideally, you’ll line up and communicate the retro format to all participants before the project even starts. That way, you’re saying “at the end of this, we’re going to talk about these things.” But if that’s not possible, start with your next retro, and be consistent in format going forward.

#2: Say What You Said!

In a retro, make sure there’s no revisionist history — like “we said we’d launch these 3 features, not all 5 of them — those other two were nice-to-haves.” Clearly say what you said you’d do, and on what timeline, and how you objectively performed against those commitments. Try these three discussion questions:
- What exactly did we say we would do?
- What are our results against those commitments and timelines?
- Did we accomplish anything NOT on our list of commitments?

#3: No shit sandwiches.

A shit sandwich is when you couch a hard conversation with a lot of praise and celebration in order to lessen the blow of the bad news in the middle. In a retro it looks like this:

Retro Agenda
Intro: OMG We did it!!! 3 months late but we DID IT. (5 min)
Discussion: We were late and it’s several people’s fault and we’re going to talk about it and hear what went wrong. (50 min)
Wrap-Up: OMG though we did it! Lots of people are really sad right now but…cold beers for everyone! (5 min)

The problem is, those kind words and celebrations often get lost — people only hear the bad stuff in the middle. Instead, make sure each section of the retro includes positives and challenges. Try this instead:

Retro Agenda
Intro: Who is someone who helped you with something difficult on this project? (10 min)
Discussion: Review objective results; 3 topics for discussion (35 min)
Wrap-Up: What is one thing you learned in this project? (15 min)

#4: Don’t Use Retros as Personal Performance Conversations

Retros are for learning what happened and why in a project. If you have already made up your mind about what happened and who might be responsible for a project failure, it’s really time for a performance conversation.

So, if you are saying “well, I know that the problem is the design team, who failed to produce working designs by Feb 15, so that’s what we need to talk about,” then you have already decided that the designers have underperformed. If you already know that someone has a performance issue, and you haven’t talked to them about it personally before the retro, you will likely end up blindsiding an individual or team in front of a group. This creates a bad situation for the person who has underperformed, and a fear factor among the rest of the group of being publicly reprimanded for performance.

But, if you’ve spoken with the person ahead of the retro and they can own the mistake, they’ll come into the conversation owning their shortcomings and challenges and speaking proactively about how to learn from mistakes.

A simple gut check is this: “Am I willing to change my mind about why I think this happened?” If the answer is no, have the performance conversation first, in private. Then own that result together.

#5: No Swooping.

Swooping is when the stakeholder or decision-maker who has barely had time to participate in the project in any meaningful way suddenly wants to talk a lot about why the project didn’t hit a deadline. This creates low trust.

Instead, make sure the “Talk: Listen ratio” aligns with relative project participation. The talk:listen ratio is how much you talk vs. how much you listen during the meeting. If you were highly involved as a stakeholder or the lead developer, maybe your ratio is 3:1 — you talk 3x more than you listen. If you are a stakeholder who wasn’t very hands-on but had a vested interest in the result, maybe flip that to a 1:3 ratio, and listen 3x more than you talk.

Eight High Trust Retro Questions

To get started on building your agenda, here are some questions you can try at your next retro:

1. What problem were we trying to solve with this project?
2. Do you think we set the right priorities with this project, why or why not?
3. What are you most proud of in this project?
4. What is one thing you wish you’d known before this project started?
5. Who is someone who helped you during a challenging part of this project?
6. What is one thing you’ll ALWAYS do on future projects, and one thing you’ll NEVER do on future projects?
7. What is a resource you wish we had to help our projects work better?
8. Active project participants, what do you need from stakeholders? Stakeholders, what do you need from project participants?

Final advice: occasionally the team should retro the retro. Ask at the end of the session if there are tweaks to the format or the questions that might make it better. Check in with participants individually to find out if they are finding retros helpful. And be willing to change things (with good communication) when it makes sense.