After a few major changes at our company, we tried running a facilitated event to have our developers choose their team they would be working with. As we had developers in both South Africa and Taiwan, this report is about our journey with self-selection and how the event was run to cater for the distributed team.
1. INTRODUCTION
In 2018 I was the internal Agile Coach at Travelstart. In April of that year, the company radically changed strategy and the subsequent development priorities. This resulted in the IT management team needing to change the current team structure.
When it came to team design, like most companies, the IT management team had this responsibility. The team consisted of the CIO, CTO, Development Manager and me. We would invite the Head of Product to team design discussions to make sure that the skill sets of team members matched the requirements of the product goals.
I proposed having team members select their teams themselves based on previous experience and this was accepted. As some of our team members were in a distributed office in another country, this report will be about our experience with self-selection and how we catered for this team’s inclusion. I wanted to share our experience as I did not find other stories or techniques to apply self-selection with remote team members and/or distributed teams (in another time zone).
2. BACKGROUND
I started my career as a software engineer over 10 years ago. Over the next few years, I was part of a few different teams at different companies. I was fortunate to experience being part of an amazing team, and a few that weren’t that great as well. These experiences led me to the Scrum Master role and, eventually, a manager position in charge of a team.
During my years as a manager of smart, motivated individuals I spent a large amount of time trying to understand what made a team “feel amazing” (from my own experience thereof), and to be considered high-performing. I was strongly inspired by the work of Daniel Pink’s book, Drive: The Surprising Truth About What Motivates Us (Daniel Pink 2009) to guide my understanding of individual motivation, i.e. Autonomy, Mastery, and Purpose. Additionally, I found the research done by Google (see Project Aristotle) provided clarity into the top 5 traits of high-performing teams in Psychological Safety; Dependability; Structure & Clarity; Meaning; and Impact.
I experimented with some activities to foster psychological safety and autonomy like regular brainstorm sessions, learning hours and even a hackathon that resulted in some really fun product ideas. This intra-team hackathon led to me facilitating a department-wide hackathon across our Cape Town and Taipei development offices. This was our first experience with some form of distributed self-selection in that teams were created without direct management intervention. In the time leading up to the dates selected for the hackathon, team members would share their ideas and potential technical skill requirements in a Google Sheets page. Team members could lobby each other to join their team to complete their idea.
The success of this led to a further step suggested by the CIO: a 2-week Sprint in which developers not only chose their team members but also chose items to work on from any backlog!
The research and these activities all seemed to confirm my own experience of what it felt to work on a high-performing team. It highlighted a set of target traits that I could attempt to foster in team environments as a manager. This worked reasonably well with these one-off events and up to this point, we had barely considered expanding this concept further.
By October 2017, the company had grown and, with a change in quarterly goals the IT management team – consisting of the CIO, CTO, IT & Dev Managers – along with the Head of Product decided to experiment in creating multiple, smaller cross-functional teams. During this change, I moved into the role of Agile Coach.
The first iteration of this resulted in some cross-functional teams consisting of developers from both of our development offices – Cape Town and Taipei. Up to this point, my experience of team design had been that “management” just selected where people were most needed based on their insights. In our case, team members were given a 1st, 2nd and 3rd team preference before the management team decided on the final selection. This method of team design seemed to be quite standard in creating teams of knowledge workers, in fact, I hadn’t even considered another option for stable team design at this point.
With a new role and new team structure, my continued learning into high-performing teams led me to the work of J. Richard Hackman and his book Leading Teams – Setting the Stage for Great Performance (JR Hackman 2002). I came across the book while reading articles about self-managed teams. In the book, he presents an Authority Matrix showing four levels of team self-management. This included a definition for “self-designing” teams, specifically the definition that these teams have the power to decide on the design of their team, working norms, resources and tools needed to complete their tasks. This was the first time I considered that self-selected team design could be an important trait of those successful hackathon teams.
3. ON TO SELF-SELECTION?
In April 2018, just 5 months after the formation of the initial cross-functional teams, another change in company strategy meant that certain teams would be changing their objectives. It also meant new teams needed to be created. One team’s product was also due to be shelved so those team members needed to be reassigned as well.
In the management team meeting, we were discussing how we would deal with all of these team changes. As we had already had some success with team members selecting their preferences, I suggested that we approach selection as we had for the “hackathon” type events we had run previously. The management team agreed that this was a viable approach – I would need to come up with a plan on how to do this as well as a backup plan to fall back on. With the one product team ending soon, I also had a time constraint to form the new teams as well. Time to get preparing…
4. OUR PROBLEM
For our previous hackathon type events, teams were self-chosen using a shared Google Sheet. Individuals would share their ideas and what expertise would be needed. Team members were encouraged to “lobby” each other to have their ideas worked on. From the feedback received after these events, team members, as well as the management team, felt there needed to be a bit more structure to these events. From this feedback, I set to find what others had done to facilitate a more structured approach to team self-selection. I reached out to my network and I was recommended to take a look at Sandy Mamoli and David Mole’s book: Creating Great Teams – How Self-Selection Lets People Excel (Mamoli and Mole 2015).
This book provided many of the answers to questions I had on how self-selection could be facilitated in a single event with a well-defined structure. This book also raised interesting points on what needed to be prepared beforehand as well as some great lessons from their experience. I read through any article I could find on this online and felt comfortable that this was indeed the format that would work for us.
The problem I found, however, was that in all the examples, team members would be in a single location for the self-selection event itself. This was a problem for us, as I’m sure it is for many others. Nine of our 30 team members were based in Taiwan and we only had the budget to bring them to Cape Town once. We decided that it would be more beneficial having them come over after teams had been selected so we could have dedicated, in-person time for team lift-off (see Nies & Larson, 2011). This meant modifying the process, so well laid out in the book, to be remote-friendly.
5. PREPARING FOR THE EVENT
To help us facilitate self-selection remotely we relied on five core tools.
- Google Sheets – our central point of truth for the lead up to the event. All questions, answers, suggestions, feedback, and information were added to a single document with different sheets. This was to make it easy for everyone to find information.
- Slack – As our textual collaboration tool of choice, we relied quite a bit on sharing information with all team members on this platform. It allowed instant feedback and having discussions around a topic in a specific channel and/or in specific threads.
- Zoom – Without the option for always having face to face communication, good video conferencing software is critical for distributed teams. We found Zoom to be incredibly powerful, easy to use and the breakaway room functionality proved essential in the facilitation of the event. From a cost perspective, we also only needed a single paid account to run our session effectively.
- Google Drawings – We used this as our digital whiteboard during the session. It was used as the visual representation of how our self-selection event was progressing and what teams looked like during the session.
- Google Slides – We used Google slides as our facilitation guide. Through it, we could display the overall steps transparently with a reminder of the actions for each step to team members present, as well as remote.
Leveraging the wisdom of Sandy and David, we knew that for the event itself to be a success, the team members would need a clear idea of the vision or mission of each team. This would also mean knowing what kind of work the team would need to complete, the outcomes upon which they would be measured, and what expertise they would need to achieve that. The management team, with the Head of Product, started mapping which teams would be needed. As Product and Development were separate departments in the organisation, Product Owners were selected by the Head of Product based on their experience and passion for the team purpose or business problem to solve.
We had learned from the previous company and team changes that in the absence of open communication, assumptions based on fear prevail leading to extra anxiety. We wanted the process to be as transparent as possible to prevent this so we made sure to share the idea with everyone as soon as possible.
At the next department alignment meeting, the management team announced the company changes and how this would affect teams going forward. I shared with the team the research done into self-selecting teams and announced that we would be running an event on 16 May in which the selection process would happen. While we had not yet finalised the facilitation process, we did share a high-level overview and let the team know that all information would be placed on a single Google Sheet. Any questions or feedback could be raised for discussion in a dedicated Slack channel, in-person or via email. As per Sandy and David’s suggestion, I wanted to make myself as available for discussion as possible.
As I was preparing for the event and creating a facilitation plan, I experimented with a couple of tools to display team information and changes during the event eventually settling on Google Drive. Once I had a template for a single team, including Product Owner, mission statement, required skills and constraints, I created a virtual space in Drawings for all of the teams.
Google Drawings – Left: An example of a team board. Right: The virtual space
Using this virtual space, I ran a brief workshop with the management team to have them visualise what the teams could potentially look like. The purpose of this workshop was to find out whether team and skill constraints made sense, the template was clear and easy to use, and also to allay any deeply held concerns by creating a “Plan B” backup. This backup became quite useful after the event to identify the differences between management-selection and self-selection.
It’s important to note that we had to make provision for the 6 hour time difference between South Africa and Taiwan. We were fortunate that this time difference allowed a decent overlap of working hours. This meant that any event or meeting held with participants from both offices would be scheduled from 9am-12pm in South Africa which would be 3pm-6pm in Taiwan. The event was planned to run initially for those 3 hours, with provision made the following day at the same if needed. This was done as all of the examples of this event I had read about seemed to take a full day and sometimes longer. Our event would consist of significantly fewer people (30 versus 100+) so we thought that a 3-hour long session would be sufficient.
The final preparation needed before the event was to elicit the help of the Product Owners to assist in facilitating the event. As discussions would need to be held between each round of self-selection, I would need to rely on the Product Owners to drive discussions around what was missing or at risk within the team. As all the Product Owners resided in Cape Town, I would also need those that had remote team members join their team during the event to dial in the team members from their laptop.
6. RUNNING THE EVENT
In the book, Sandy and David provide an extremely simple and easy to follow step-by-step process for running the event. It consists of the following stages:
- Preparing the materials and setting up the room, reflecting current team status’ visibly
- Having Product Owners share team missions, constraints, and needed skills
- Iterating through the stages of team selection, assessment and raising of risks/concerns
- Stopping when teams are full or exhausted and closing off the session
6.1 Preparing the materials and setting up the room, reflecting current team status’ visibly
As we would have a remote office in Taiwan with the bulk of participants in our head office in Cape Town, we needed to essentially set up 3 spaces. One for each location, and one virtual space that both offices could reference and update as teams changed.
Virtual Setup: We set up a clean Google Drawings template, as prepared earlier, as our digital whiteboard to visually show team selection. In a deviation from the book, we wanted to start with a “clean slate” and had all team members start in a waiting room space. We didn’t want to seed the decision-making process so we thought this would be easier for people to make their decisions. We also thought it would be a great equaliser for those team members whose teams were being made defunct due to change in objectives and would be isolated in the waiting room.
Taiwan Setup: As this team did not have a Product Owner present in their office, the team decided to use the virtual setup only. All team members would sit in a single room, then, as they chose their teams, they would move to another space in the office to have their respective (remote) discussions with their Cape Town team members.
Cape Town Setup: Not much setup was required for the main office other than making sure we had enough space to move around, a large screen to present the facilitation slides, the video stream of the remote team office and an overview of the team selection overview in Drawings.
6.2 Having Product Owners share team missions, constraints, and needed skills
By the time the event was run, the Product Owners (POs) had created and iterated over their mission statement, skills requirements and constraints multiple times in collaboration with the management team. We still did a refresher of this by having each PO say a few words about the team mission, skills, and constraints. As this all took place in Cape Town, the presentations were streamed via Zoom to the remote participants. Once presentations were completed, the POs took their laptops and a flip chart paper with their team name to a spot in the large open space. Participants in Cape Town could take advantage of the collocation to walk to a Product Owner to “join” that team during the iterations.
6.3 Iterating through the stages of team selection, assessment and raising of risks/concerns
For this section, I relied on Google Slides (shared on Zoom) to present an overview of how the bulk of the event would work regarding selection. I explained that we would have 5 minutes to select teams, i.e. either walk to a Product Owner (local) or drag your name into the desired team space on Google Drawings (remote).
After the 5 minutes had expired, each team (as they were constructed at that time) had 10 minutes to discuss their structure and team makeup. The goal was to raise any concerns or risks to the team mission based on who was present and the needed skills and constraints of the team then document these on the Flipchart. This part required the facilitation assistance of the Product Owners and some key functionality in Zoom, i.e. breakaway rooms. First, the POs made sure to update the Google Drawing of the team overview to make sure it accurately reflected both local and remote team members. If a newly created team consisted of any remote team members, then a breakaway room was assigned to that PO, with the specified members added individually as well. This meant that remote workers could find a space in the office in Taiwan to have a discussion with their Cape Town colleagues using the PO’s laptop.
Once this time box expired, we all came back to the central area (Zoom breakaway rooms were shut down and participants returned to the main call). Each team was given a chance to highlight any risks or concerns raised during their discussion. To keep this part flowing, the instruction was given to not comment during a team’s time to share – comments and questions for other teams could be left for the next round of selection. After all risks and concerns were raised, I reiterated the mission statement – “Do what is best for Travelstart” – to remind everyone that we were not done yet.
We repeated this process 3 more times. After the 3rd round, only two teams had serious concerns. One team was missing a senior person in a specific language, the other was a little more complicated. For this team, it became clear that some people were wary of working with a specific team member. As this person moved into a team, others moved out, and vice versa. After the 4th round of this happening again, we decided to stop where we were. 8 out of 10 teams formed seemed like a successful event so far.
6.4 Stopping when teams are full or exhausted and closing off the session
Before ending the event entirely, we discussed the outstanding major and minor concerns in a Lean Coffee format (slightly modified to remove voting as we needed to discuss outstanding issues). There were two team-critical issues where criteria could not be met. The one item was that a team was missing a person with a specific skill set needed for the team. This resulted in an action for the management team to hire someone to fulfil this role, and an action for the team to invest in more knowledge sharing until then. The other issue was a bit tougher and related to the hesitancy of some individuals wanting to work with a specific person. After some discussion to get a sense of comfort levels and find a resolution it became clear that the team members did not feel they could solve this issue. This seemed like a good time to stop, we had formed 8 of the 10 teams, with two underlying problems now clearly brought to the surface for the management team to help resolve.
I closed off the event and congratulated the teams for their first self-selection event. We spoke about our next steps with regards to team lift-off sessions and first sprints.
7. FOLLOWING UP
7.1 Looking at the feedback
The day after the event I sent out an anonymous feedback survey to gather feedback on the session from the participants. There was a good response and some great feedback given. Overall the feedback seemed very positive about the event and the transparency it created.
There were however some concerns raised around the lack of skills needed for the specific teams, i.e. not enough seniors in a specific language or not enough domain knowledge. It seemed that some were concerned about others seeming to have to “give up” their first choice team selection so that the teams could be balanced. A couple were concerned about the interpersonal issue that was made a lot more transparent by the event. These team members seemed to not be comfortable having this dealt with publicly.
Around one month after the event, I sent out another anonymous feedback survey. I wanted to see, now that the dust had settled, how team members felt about their new teams. To simplify it, only two questions were asked. “On a scale of 1-5, rate how happy you are with the new team?”, and “What was the leading factor that drove your team choice?”.
Graphs generated from the answers to the two form questions
From the first question, it seemed that the majority of team members were satisfied or happy with their new team. Understandably, a couple were not too happy seeing as some members did not end up in their first choice team having to make a personal compromise for the benefit of the company.
When looking at the responses to the second question, it seemed the majority of respondents struggled to choose company first, opting rather for technical skill growth potential, other people, and “other” issues like job security, or long term growth potential. In hindsight, I realised that more emphasis and effort could have been made into clarifying the finality of the team selection. During the preparation stage, one of the FAQ’s did address when teams would be able to come up for re-selection, but this was a guess at best and I believe now that we could and should have done more to highlight that change would be allowed/encouraged after the fact. This may have made it easier for these team members to make this decision.
7.2 Looking at the teams
In the weeks that followed the self-selection event, the excitement and energy levels of most participants were quite high. Within the first week, the first team was formed consisting of one team member from Taiwan and three team members from Cape Town (one worked mostly from home). Once all work and sprints were completed for old teams, those team members would join their new teams. This process was a bit disjointed but seemed to work out quite well.
Around the time that the final team members were falling into place, our Taiwanese colleagues were flown to Cape Town to do some team building activities. I facilitated a series of workshops to establish team safety, align on common values, get to know each other better and to identify team norms, rules, and activities in the form of a working agreement. These exercises are outside the scope of this report, but I would highly recommend the team start-up suggested in Lyssa Adkins’ Coaching Agile Teams (Lyssa Adkins 2010) book.
Six months later, many of the teams looked the same as they had just after the self-selection event. During this period, some people left, new people joined and we also had someone request to move teams. All of these individual actions resulted in team changes. In our case, the changes were not large enough for the management team to feel another event would be needed.
I noted something interesting in the few teams that still consisted of the original people selected at the event. These teams were extremely self-organising, driven and happy in their teams. They exhibited most, if not all, of the traits of a high-performing team according to Google’s research. What stood out for me the most, was that some of these teams looked quite different to the management team structure we did as a “Plan B” before the self-selection event. While there were indeed other factors that influenced the success and challenges of these teams 6 months later, there did indeed seem to be a correlation between self-selected teams and positive team performance.
8. WHAT WE LEARNED
While there were many small lessons learned, the three that stood out most from our experience were:
8.1 Self-selection can work with remote teams and team members
While co-located teams are always ideal, they are not always a reality. Having all team members gather for the self-selection too is also ideal, but again not always possible. For this reason, we made use of specific tools and remote facilitation techniques to run the full self-selection process. From our experience, it should be clear that collocation is not a constraint to having self-selecting teams. In future, I would certainly experiment with different techniques I’ve learned since running the event. Specifically, I would like to see a fully remote session in which all participants join a Zoom call, and we use elements of silent facilitation and engaging visuals to facilitate the session.
8.2 Management selection alone cannot cater for the traits needed to build high-performing teams
Focussing on the work of Daniel Pink’s Drive, Google’s Project Aristotle, and J. Richard Hackman’s Leading Teams, we learned that while managers have a major responsibility in driving high-performing teams, it’s not always possible for them to truly be aware of the interpersonal relationships that affect team performance. This event also highlighted a technical knowledge gap between what was being interviewed for versus what skillset(s) were missing. For these reasons, we found that what the management team assumed would be the ideal team structure, was quite different to the reality of what was chosen. More specifically the “Plan B” created by the management team guessed 21/30 team placements. This means 9 team members may not have gotten their first choice team in contrast with the 2 from self-selection.
8.3 Self-selection is not just an event, it will radically change your team’s culture and how they engage
Since teams were first chosen at the event, every subsequent decision or change was always discussed with self-selection in mind. This rapidly increased the level of ownership teams felt within their roles. Teams wanted to be more involved in hiring, tooling, product and business decisions, etc. This means that as a coach or sponsor, you need to be even more aware of decisions that would affect the autonomy of the team.
9. CONCLUSION
Selecting teams can take different forms. While manager-selected teams are currently most prevalent, there seems to be a shift towards involving team members in this critical decision. If your company is willing to give a self-selection event a try, Sandy Mamoli and David Mole’s book provides clear guidelines for running this event yourself. If you are currently concerned about excluding your remote team members, whether a distributed team in another location or individuals working remotely, the process guidelines can be easily adjusted to cater for these scenarios with a few extra considerations.
10. ACKNOWLEDGEMENTS
I’d firstly like to thank the CIO of Travelstart, Rick Molenaar, for being such a positive and driving force towards greater agility at Travelstart. If not for his trust and confidence in my abilities, the self-selection event may never have happened. I’d also like to thank the rest of the management team for putting their trust into this process even though there may have been reservations. Thank you also to the rest of the Travelstart team in Development and Product for trusting me to take you through a new, exciting and sometimes uncomfortable team design process. I appreciate the honest feedback, the personal concerns raised and the courage and can-do attitude that made you all so amazing to work with.
I’d like to thank Sandy and David for making the facilitation of a self-selection event so accessible and easy to follow with your amazing online guides and extremely well-written book.
Finally, I’d like to give a huge thank you to Jutta Eckstein, my shepherd throughout this report-writing process, for her patience, kind words and clear, concise feedback. This paper would not have come together without her assistance.
REFERENCES
Pink, Daniel H. Drive: The Surprising Truth About What Motivates Us. New York, NY: Riverhead Books, 2009.
Hackman, JR. Leading teams: Setting the stage for great performances. Cambridge, MA: Harvard Business School Press, 2002.
Google’s Project Aristotle, Re:Work Guide: Understand team effectiveness,
https://rework.withgoogle.com/print/guides/5721312655835136/.
Mamoli, Sandy & Mole, David. Creating Great Teams: How Self-Selection Lets People Excel, Pragmatic Programmers, 2015.
Nies, Ainsley & Larson, Diana. Liftoff: Launching Agile Teams & Projects, Pragmatic Programmers, 2011.
Adkins, Lyssa. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition, Addison-Wesley Professional, 2010.
