I recently presented an introduction to retrospectives at Vanta as a tool for teams to use in a hypergrowth environment. The presentation was well-received, so I’ve converted it into a post in it’s interesting to others, too!

Why retrospect?

Companies that are growing as quickly as Vanta are moving fast and need to move even faster to build their presence in the market.

In this environment, these two things are true:

• Mistakes will happen. We’re moving fast, and things will break.
• What works today almost certainly will not work tomorrow.

We must embrace these truths, expect change, and anticipate the continual need to adapt. Retrospectives are a tool to discover opportunities for improvement both retroactively and proactively.

In Engineering, we use two types of retrospectives:

• Incident retrospectives: “Something bad happened. What did we learn, and what will we improve for next time?”
• Team retrospectives: “How might we improve how we work to preempt future bad things from happening?”

Incident retrospectives

Quality is a choice that trades off against speed. The best way to ship a product with no defects is not to ship a product at all. We’re moving fast and shipping a lot, and sometimes, things don’t go as planned.

When something goes wrong, the root cause is rarely pure human error. We need a depersonalized and blameless way to reflect and identify improvements to our processes and tools to learn from our mistakes and to prevent them from happening again. Framing incident retrospectives as blameless is essential – blameless retrospectives encourage honesty and lead to meaningful improvements. In contrast, creating a culture where it’s not OK to make mistakes discourages surfacing and addressing real issues.

We have an incident playbook to identify incidents, resolve them, and communicate internally and externally. When an incident is resolved, we have a retrospective template that covers, roughly:

• Timeline (what happened?)
• Root cause
• Resolution (how did we fix it?)
• What went well?
• What could we improve?
• Action items

Every two weeks, leadership from Engineering and Customer Experience reviews these retrospective documents to coach the team in diagnosing root cause issues and to ensure that we have appropriate action items moving forward. While it’s OK to make mistakes, we must use these opportunities to learn from them going forward, and this is the forum to ensure that that happens.

Team retrospectives

We often say that “every week is a new week at Vanta.” It’s true! We’re growing our customer base and team very quickly, and we’re building this rocketship while flying it. One of Vanta’s principles is bias for action, commit to iteration, essentially acknowledging how fast we’re moving and embracing evolving how we work.

A tool we use to identify improvements proactively is the team retrospective. Essentially, we’re assessing how we work today and identifying potential improvements before things break.

On a ~monthly basis, Engineering teams dedicate time to reflect on projects, processes, and working relationships to identify opportunities for improvement.

Teams can run retrospectives however they’d like. Our default format is:

1. Collect opinions and potential improvements from teammates independently to avoid bias, either in a shared document or on post-it notes. Our default framework is:
   • Start (what should we start doing?)
   • Stop (what should we stop doing?)
   • Continue (what should we continue doing?)
   • Puzzle (what questions do we have?)
2. Assemble these ideas, grouping them by theme.
3. Teammates vote on themes they’d like to discuss.
4. Discuss top-voted items and, where appropriate, next steps.

Like incident retrospectives, effective team retrospectives are depersonalized and blameless. When a team ritual grows stale, it doesn’t matter who came up with that idea in the first place. It’s broken, so rip it out, try something new, and move forward. Depersonalizing decisions encourages more people to volunteer suggestions, and a team that incorporates more opinions and feedback almost always delivers better outcomes.

One secret benefit of running team retrospectives run well is that teammates have a venue in which to surface their complaints. When someone brings up constructive feedback for how we work in a 1:1, I direct them to the next retrospective where the whole team can hear it. If others agree, great, let’s fix it! If the team decides to prioritize other improvements, they’ll see that in a way that’s fair and transparent.

Wrap

So that’s it! I hope you find these tools useful. Next time something breaks, consider running an incident retrospective to avoid making the same mistake again. Next time someone thinks your team’s processes feel stale or inefficient (spoiler: this is often in a high-growth environment), consider running a team retrospective to identify improvements.

Don’t squander a good mistake, no matter how small or spectacular; take advantage of opportunities to learn and improve! Remember, blameless retrospectives encourage honesty and lead to real improvements.