Insights in Design: Team Retreats

Earlier this week we ran a two day team retreat for one of our largest distributed teams. Attending the retreat was both the technical and admin staff, as well as HQ and outposted staff. That was objective 1 - giving people a sense of interconnectedness in a non-intact team, and at the same time explore the team's diversity.

The retreat also needed to bring up and sensitively deal with issues of growth and managing a larger team. In the last few years, due to their successes, the size of the group has more than doubled, with little turnover. As a result, some of the team practices (communication, decisionmaking, trust building, everyone doing everything him/herself) that worked before with a small, tightly knit team, are no longer as effective with a larger, more functionally diversified group. That was objective 2 - air some growth and management challenges in a way that everyone can feel heard and then make some decisions about how to change them.

Finally, the group needed to think together about what's next. So they needed to tap back into their goals, and also explore together what they needed to add or significantly strengthen in their current practice. This was more programmatic, however, they needed to bring the admin side of the team along so that any decisions made were completely operational. That was objective 3 - consider how to add some functionality to the group, but do so in a way that was realistic and feasible, and fit within the operational system they had and were building (or change it to fit).

With a mandate like that, and two days to work with, we had our work cut out for us. However, we did it, and the team was very happy with the results. Here are a few things we learned that worked:

• We used systems thinking tools to help to guide and structure the discussions. People were delighted to use these new tools, which when applied to the operational aspects of the team's work, were able to integrate and value the inputs of everyone there, from both the technical and administrative parts of the team.
• The systems tools created a safe space. The diagrams helped to externalise the conversations, so that people were able to focus on an object, diagram, that depersonalised issues. People discussed trends and cause and effect: pointing their finger at the flipchart diagram and not each other.
• The tools are iterative, so they break down what seems like a process about everything into a set of logical steps and bitesize pieces. Also because of this structure, there was no anxiety from what might otherwise be a messy process. The tools gave clear boundaries to the discussion.
• Finally, the format of working in parallel on a number of different operational issues allowed people to focus on the ones for which they had the most passion, yet still contribute through the summaries and sharing to the work of other groups.

The report that resulted from the event included the diagrams and captured the creativity of the process for next steps. It was actually a good read, a quality that all workshop reports should have. And it has spawned a number of processes around the outcomes that is making this team one of the leaders of change in our institution.