Asking for solutions first is bad management advice. ‘Don’t bring me problems — bring me solutions!’ teaches your team not to speak up if they cannot solve it themselves. That’s not how to work as a team and it certainly doesn’t leverage the collective intelligence of the people you’ve hired.

Encouraging your team to talk about their job in a non-judgemental environment is key to building trust. According to Google’s Aristotle project, in which they studied 180 teams[1] over the course of a year,

…Google’s data indicated that psychological safety, more than anything else, was critical to making a team work.

In February, our leadership team[2] identified the need for us to run a retrospective. Our team has grown 400% in size within a year and when you have that many new hires maintaining a strong working culture can be difficult.

Ensuring that we’re always aware of what impacts our Designers is our top priority. While we do 1:1s, group chats, and eat lunch with our team, sometimes it isn’t enough time.

Running a Retrospective

What is it?

A retrospective is an exercise designed to help a team identify opportunities for growth or celebrate wins. They can be complex but I like to use a fairly simple model for the sake of logistics.

You can run one after a project launches (to focus on process) or anytime you feel like there are things to discuss (this is the stage we were in). It’s a great time to pause and reflect on things we often forget about when we get lost in everyday work.

The goals of a retrospective:

• To celebrate and identify what the team is doing well
• To bring problems to the group you’ve experienced in the past
• To discuss things in an honest and transparent way
• To encourage newer team members to participate honestly by setting a good example

Preparing for it

Finding the time to run an exercise like this with everyone in the room is a bit difficult. We are cognizant of the amount of time this takes away from this many people so the leadership team narrowed down our target areas to five. There are many more spectrums that affect a team but we had to start somewhere:

• Product — How do you feel about what we launch? Are you proud of what we ship? How are the processes we use doing? Are we missing anything?
• Culture — Are you supported at work? Are the activities that you do on a weekly basis sufficient and/or meet the goals of the exercise? Do you think the Design team works collaboratively with each other?
• Growth — Are you placed on the right projects for your growth? How do you feel as the company is scaling? Are you able to do your best in the position you’re in? Have you made progress in the past six months?
• Communication — What is it like working within your project team, within the Toronto office, or with the company? Do you get the information you need in order to do your job? Is your position clear to you?
• Leadership — Do you feel like you’re well-represented by the leadership team? Is the team transparent? Do you understand why decisions are being made around the office? Are your self-assessments are fair? Does the leadership team cares about you?

This list was sent out before the retrospective to give our Designers some time to think about it beforehand.

The exercise

Before the team arrived, we wrote the themes down on stickies and cordoned off walls for each theme. We split each wall into two sides labelling one “happy” and one “sad” and everyone brainstormed what is working and what isn’t.

Everyone was encouraged to put up their stickies as soon as they wrote it and to walk around and read as other team members put theirs up. If they agreed with anything, they could simply write a “+1” sticky note and add it beside the original. We gave ourselves 30 minutes to do the exercise.

As the Designers brainstormed, the leadership team would read through every theme and group like post-it notes together if the notes were related. This is to help guide the discussions afterwards and understand the urgency of the topic.

Afterwards, the team gathered around each theme and read every post-it note together. We asked questions for clarification and encouraged each other to give examples if they were comfortable doing so.

The notes were documented where the most popular topics (the ones with the most amount of notes) were ranked first. We posted the doc to the team on Slack and opened it up for modification if they wanted to add in anymore after having the retrospective.

What happens after a Retrospective?

Coming up with ideas

Certainly, there are things that you can do as a lead to address part of what your team has identified but you may not always know the right answer… and you aren’t always the right person to execute, either.

We planned an all-day offsite after:

• To encourage team members to become involved with the solutions
• To use our collective brain-power to come up with better solutions
• To give our Designers an opportunity to practice applying Design Thinking to organizational or team process change

Before we started, we reviewed everything again as a group and volun-told a Designer to facilitate conversations around each theme. The rest of the team split themselves up based on what they were most passionate about and we gave ourselves an hour or so to work through the initial thoughts.

Then we took a break and ate pizza and drank optional mimosas for a bit.

After lunch, the teams were tasked with brainstorming possible solutions for how to fix the problems identified and/or continue doing better on the things we were already getting right. The goal was to come up with not only a solution but an implementation plan answering what, how, and who?

At the end of the day, the teams presented and discussed the solutions they came up with. We used this time to ask each other unanswerable questions and think about the blockers that could come up during implementation.

The goal of an exercise like this is not necessarily to come up with one solution or the right solution. Offsites like this are great for generating new ideas or building the foundation for more creative thinking in the future.

Execution

Ideas mean nothing unless executed well. During our next Product Round-table (our weekly meeting) we broke out into groups and turned all of our proposed solutions into projects. We used Github, a tool everyone already knows and uses for project tracking, to hold most of the information.

Each group was asked to write briefs similar to what we use for our Product projects and create implementation plans on how we would approach it. Lastly, owners were assigned to each step to ensure it got done.

Final Thoughts

One big thing which was identified through this process, was that our Designers felt guilty for working on these sorts of projects instead of their “work.” While we considered this part of their work too, once they’re in the weeds it feels a lot different.

We’d like our individual Designer workloads to be at 80% capacity. As a result of this retrospective and to help us achieve balance, I myself have resourced a good chunk of my next few weeks (and weeks since then) to increasing recruiting efforts.

We are still working through this and expect to follow up soon on our results through another retrospective to keep us all accountable for making the team better. I’m incredibly excited for the future of this team.

P.S. If you’re looking for a team who is impressive on many levels and has no shortage of hard problems to solve (project or team) send us your portfolio. Play a game and pick one of three: Darrin, Helen, or Ilia.

Originally published at helentran.com on March 27th, 2017. Join the mailing list to get access to content first.

If you liked this, please click the ❤ below to let me know. I use this number to better gauge what my audience on Medium is like. Your feedback and support via replies or shares of this article on Twitter are also appreciated.