Growing our team with retrospectives

In my years in tech and leadership, one thing I have learned about myself is that I hate telling people what to do. That might sound weird coming from a manager, but it's true! The most important part of my job is to hire an amazing team and help them to do their best work – the "what" and "how" is mostly up to them. A manager who tells everyone what to do is killing morale and probably isn't making the best choices for their team.

It's especially important for a team to make their own decisions when it comes to defining process. We engineers may cringe at the word “process” because we associate it with red tape that slows us down from building and shipping things, but really, process is just an articulation of how we work together to get things done. If your team has a way of building quickly without red tape and without stepping on each other's toes, then that's process too! In my experience, helping a team to identify and solve problems in their process is the best way to make everyone happier and more productive.

At Plaid, we take an agile-like approach to how we think about process. If our team's process isn't working, we talk about it in a retrospective (aka "retro") and figure out how to change it. Many companies don't begin retros until they are large and have many processes in place, but we feel that retros are especially valuable at our size and rate of growth. Plaid's engineering organization is rapidly growing. In the Salt Lake City office where I work, we have plans to grow from 20 to 60 engineers this year. Processes that worked just a few months ago may not work now. A culture of continuous process improvement helps us to stay ahead of growing pains like inefficient collaboration, error-prone coding practices, and interpersonal conflict.

Why retros?

I was first introduced to retros many years ago when I was an engineer on a team that was going through a rocky time. The team lead recognized that there were a lot of bottled up feelings and decided to call a retro to clear the air. That first meeting was very emotionally charged – I realized just how much bottled-up discontent had been quietly eating away at team morale – but subsequent meetings became more productive. This taught me that the best time to start retros is before a team's frustration has gotten to a boiling point.

Retros are a well-knowntool in agile to develop and improve processes. While there are lots of fun variations on how to do a retro, they all include a discussion of what the team should continue doing and what needs to be improved. When done well, retros are a light-hearted and empowering environment where a team can celebrate wins, talk in an open and blame-free way about its challenges and struggles, and define its own destiny. Our end-of-sprint retros have helped us grow as a team and produced some of my favorite moments with my coworkers.

Retros in Reality

I've gone over some abstract benefits of retros, but what does it look like on the ground? Let me give you a walkthrough of how we do retros on my team.

We have a retro every other Friday afternoon, which we hold at 4pm so that people can wind down and reflect on the week without having to get back to work afterward. Meeting notes go into a Confluence page where everyone in the company can easily read our retros and share our learnings. We give each retro a fun name – last quarter, our team's retros were all named after Green Day songs.

Our discussion points are separated into 3 different columns:

• What went well? This is where we talk about things that we did this week that had positive impact on how we work. This is a chance to celebrate the process changes that are helpful to our work, or the accidental happenings that we want to intentionally incorporate into our process.

• What went less well? This is where we talk about the rough stuff and brainstorm how to make it better. Going over this part takes up most of the meeting because there is so much discussion on how to improve the team and make impactful changes. This is action item central: every topic needs at least one actionable improvement!

• What else was noteworthy? This is our fun section, where we can talk about cookie pies and celebrating International Women’s Day. The bullet points here aren’t necessarily to produce learnings or actions toward improvement, but they give us a great opportunity to share some laughs and bond as a team.

Discussion points from last quarter's "Geek Stink Breath" retro

We also keep a summarized list of action items and learnings, so it is easy to follow up on them in future retros or standup meetings.

Action items from last quarter's "Geek Stink Breath" retro

Here are some examples of changes we have made coming directly out of past retros.

• Problem: Too much load on tenured engineers answering new hire questions

  • Solution: A new onboarding curriculum with a 2-month mentorship program.

  • Solution: Each new-hire cohort improves documentation as they onboard.

• Problem: Low priority issues were delayed until the backlog became too big.

  • Solution: Biweekly SLA Day, during which we focus on paying down some of our technical debt and fixing lower-priority issues.

• Problem: Newly inducted on-call engineers don’t know how to diagnose pages.

  • Solution: Lots of runbooks and how-to’s covering everything from diagnosing proxy issues to setting up VS Code to using our internal tools

• Problem: On-call engineers getting cabin fever from feeling tied to their home wifi.

  • Solution: Mobile hotspot for on-the-go ops

Finding your retro

Every team could benefit from retros, but it takes practice to conduct them well. Here is my basic guide for how to set up a retro. Remember that you might need to try a few different things to find what works for you!

1. Schedule them regularly. Don’t just wait until something bad or momentous has happened. Big change can come out of everyday observation.

2. Make retros an enjoyable meeting. I like the “noteworthy” section of our discussion, where people can talk about the nice weather or how much they love the new peanut butter cups. While it isn't related to process improvement, it makes the meeting more fun and lightens the mood.

3. Make retros a safe space. Retros need to be a place where everyone can talk freely and be honest about their feelings and concerns. We treat each other with respect and talk about fixing processes instead of blaming people.

4. Talk about the good and the bad – but don’t whine. The team should keep a productive mindset and feel empowered to change things. Discussion should focus on finding solutions as much as identifying problems.

5. Make action items. Anything that went "less well" should be accompanied by an action item. Assign owners before you leave the meeting, because unassigned action items won't get done. If there are multiple action items for a problem, take the most impactful one(s).

A retro on retros

Retros are themselves a process that deserves scrutiny and improvement. Here's what we've noticed about our own retros so far. (And of course, all improvements come with an action item!)

What has gone well?

• Team members feel safe to admit mistakes and ask hard questions. This is a core part of Plaid's culture and extends into our team's day-to-day interactions as well.

• Meaningful change comes from our retros. It is not a scream into the ether. Managers and individuals are good at making room for working on important action items.

• People actually read and learn from other retros. This is something that is new to me. In the past, my retros were mostly for the team running them, but here at Plaid other teams actually read and learn from our insights. I love that our retros have broader reach beyond a team level.

• Retros at Plaid are for everyone. We’ve done them for engineering projects, sprints, university recruiting season, design campaigns, and our diversity & inclusion efforts for the quarter. Retro all the things!

What has not gone so well?

• We don't have a structured approach for following up on action items. Sometimes they get done promptly, but other times it takes weeks or months, and progress isn't always recorded in a place for everyone to see.

  • Action Item: Include due dates with each retro action item and have a mechanism for following up.Track unfinished items in a spreadsheet.

• We are great at sharing, but we could get more bang for our buck by pulling out distilled "TL;DR" learnings that other teams can consume quickly without sifting through nitty-gritty details.

  • Action Item: Include biggest retro learnings in a quarterly digest for the team to surface the most impactful items to a broader audience.

As we continue to grow, I hope we continue to leverage retros as a tool to adapt our processes mindfully and intelligently. Retros are one of my favorite parts of working with the team here in Salt Lake City, and they've had such a positive impact at work that I even do them in my personal life – which occasionally confuses my family! Through our retros, my team has shared profound learnings and shaped a culture that leaves me feeling energized at the end of the work day. I feel privileged to call these driven and creative people my peers because I know by brainstorming through the tough times together, we will continue to accomplish greater and greater things.

Think you have some great learnings of your own to bring to our culture of continuous improvement? Join us in San Francisco, Salt Lake City, or New York City.