Large Scale Self-Selection - the Trade Me Case Study

Organisations get the best results when people can choose what they work on and who they work with. In that spirit we decided to let people self-organise into small, cross-functional teams called squads.

Up until last week we had six established squads within two tribes the rollout had been purposefully slow and controlled. Now we felt there was enough knowledge within the organisation to speed up the process.

I wrote in more detail about our motivation for self-organisation and experiences with a smaller scale trial in my previous post “The self-organising organisation” and if you haven’t read it yet I recommend you have a quick read.

Squadification day

We thought the fastest and most efficient way to let people choose which squad they wanted to be in was to organise a facilitated event that would allow people to self-organise in real time. So we booked almost the entire tech department of around 100 people for a day of “squadification”.

The objective of the day was to form as many of the 16 squads we needed as we could.

Visualisation

One of the things we had learned from our trial was how important it was to visualise our squads and their status. We knew from experience that it would be a lot easier to gain shared understanding of where squads were at and to communicate needs, wishes and gaps if we could manage to visualise information about who was in which squad and what the status of each squad was.

We did this by representing people with their photos from the employee directory and then had them attach their skills to their photos with coloured sticky notes.

We also visualised status by using big checks and crosses to signal whether a squad was fully skilled and skill checklists to visualise any gaps.

For example the squad below has all the skills needed and has a big tick as a fully skilled squad.

Here’s how we ran the day

-- 8.45am - Good Morning (Registration)

In an unconference-like fashion we welcomed people at a table and asked them to take their own photo and write their name on it.

We made a conscious choice to use one photo per person to reflect that each individual should only be on one squad. We didn’t mandate this but explained that our experience so far told us that one squad per person was best as it allowed people to commit to their team mates and work. Anyone who felt the need to be on more than one squad had to deliberately tear their photo apart.

The only exception were database people where, based on our experience, working with one squad and supporting a second one works well. The database people got a colour photo for their main squad and a black-and-white one for their secondary squad.

Observation: Only one person tore themselves apart in the beginning but was later convinced by their squad to put his halves together again.

-- 9.00am - Welcome

We briefly restated the purpose of the day, explained the rules and mentioned the FAQ sheet everyone had found on their seat.

In particular we wanted people to know that:

• They weren’t signing away their lives: We were going to have a review after 3-6 months and if someone wanted to switch we’d try to make it happen.


• They shouldn’t think of their current projects when making their choice: Although this was important we didn’t want people to worry about it during the selection process. We made people aware that we were defining the end goal and there would be a transition period where we would take current work into account.


• If they couldn’t make it on the day then people could either nominate a proxy to act on their behalf or ask one of the facilitators to represent them.

-- 9.10am - Product Owner Presentations

Next we asked each Product Owner to briefly (2-3 minutes) introduce their squad with a squad name and mission and the next two most likely projects or things people would be involved in.

Product Owners were the only pre-selected people in a squad.

Observation: If I were to to this again I’d support the Product Owner pitches with a printed piece of paper with a paragraph or two about each squad. We had a lot of new people who didn’t know about all the areas of technology and remembering the purpose and type of work for 11 squads proved to be difficult for them. Also, I think we could have been better at communicating the importance to our Product Owners of needing to ‘sell’ their squads to potential “squadders”

-- 9.45 - Establish the starting point

We established the starting point by asking people to put their photo where they thought they were now. For anyone without a squad or who was unsure we had a “Not yet in a squad” section.

We also asked people to add a coloured sticky note with their main skill to their picture to visualise how they were able to contribute to a squad.

During our trial we started with a number of blank squad posters. We chose not to do this at the big event as we are partially through our Agile push and some people work in squads already. The idea was to reflect the status quo while giving people the opportunity to switch if they wanted to.

-- 10am - 12pm Choosing rounds 1 - 4

We then ran four choosing rounds which each followed this process:

1. Set a 10 minute time box to self-select and have people put their photo into the squad where they would like to be.


2. At the end of the 10 minutes the squads fill out the skills checklist and stick it on the wall under their squad image. The squad also fill out their current issues (e.g. no tester, too many devs, no DB etc) and display this on the wall as well.


3. One person from the squad reads out the current status to the room. (E.g. “We don’t have a full squad because…” or “We do have a fully skilled squad.”)

Squadification discussions

Constraints

We had learned from our trial that having only a few constraints for how to select a squad worked really well. Again we only had three rules around the formation of a squad.

A squad could be considered a valid squad if it …

• had all the skills needed to deliver end to end


• was between 3-7 people (think skills not roles!)


• was co-located

The overarching rule was “Do what’s best for Trade Me” which we placed in the form of a big banner on the walls.

Although we displayed a squad blueprint in the room we didn’t expect people to follow the blueprint to the letter. We didn’t advise on the number or ratio of testers, developers, BAs or designers as the exact requirements will always vary based on the work. Some squads might have no design requirements for example, whereas others will be doing significant design and front end work.

We were strict on a 7 person limit though as, in our experience, bigger squads find it very hard to communicate and are less effective than smaller ones. To keep squads small we encouraged people to “think hats not people” and to be aware that one person can wear more than one hat. (We have BA/test, squad master/developer and BA/dev combinations for example.)

Time boxes

Another thing we had learned from our trial was that it was really important to be strict on timings for each round to avoid conversations dragging out. At the end of each choosing round everyone who wasn’t in a squad when it ended simply put their photo into the “Not yet in a squad” section.

If any squad in the following round was short of a person or skill we encouraged them to talk to the people in the not in a squad yet section to fill their gaps.

Observation: The “Not in a squad area” worked well. People in this section were contacted by others to join squads with skills gaps.

Reporting back

At the end of each self-selection round people filled in index cards with their issues and reported back to the room. Although it sometimes felt like the Eurovision song contest (“And can we hear from the Category squad please …”) it worked really well for communicating gaps and “over-subscriptions”.

The output from the reporting round always fed into the next selection round.

How the 4 rounds went

It was interesting to observe the process of incremental improvement in each selection iteration:

• Round 1: After round 1 we only had 1 fully skilled squad and some very over-subscribed ones - the tech squad for example had 6 developers. In general, there was a lot of movement between tribes.


• Round 2: Things started to get a bit more balanced. This time we had 3 ticks and some over- and some under-subscribed squads.


• Round 3: People started to lobby, organise and speak up. Some Product Owners re-read their pitches to help people decide and it felt like things were really starting to move. After this round we had 6 fully formed squads out of the desired 11.


• Round 4: We managed to create another squad which put the number of fully skilled squads up to 7. During this round there was basically no movement of people anymore.

Based on our trial we weren’t surprised to see this pattern. The first round is crazy, the second round is starting to improve and by the third one people get the hang of it and solve the puzzle as a group. It was interesting to see though that the same pattern held true for 70 people as it did for 20 in our trial group

-- 12pm Lunch

-- 1pm - Sending people home, working with the rest

As there had been barely any movement in the last round we realised that more iterations and selection rounds would not get us closer to a solution. The seven squads we had defined during the morning felt stable, most people hadn’t moved for at least two rounds and the squads had been “signed-off” by themselves and their product owners. People in those squads had started to disengage and we therefore decided to send them back to the office with the instruction to be available if needed.

We kept everyone who wasn’t in one of the stable squads in the room and played another round of self-selection. As there wasn’t much movement we then took all the photos off the wall and started with a blank slate. This gave us two more full squads, getting the number up to nine.

For the remaining two squads we started talking about solutions as a group. One of the obvious measures we could take was to hire people. We introduced so called hire-cards to represent new hires and people could choose for their squads like imaginary friends. With this we managed to get to 10 out of 11 squads.

Observations and learnings

People

It was interesting to observe what people based their selection on. The most important thing was definitely personal relations - both who people wanted to work with and who they didn’t want to work with. Interestingly, people seem to find this hard to admit.

As an organisation we learned a lot about what people actually want to do and some of this information will be very useful for our future hiring. For example, after the first selection round almost all developers had moved themselves into the tech tribe, leaving the more frontend and design centric squads.

For management it was really good feedback to have some areas of the company highlighted that are less appealing or where people are not as happy.

Selecting a squad was quite difficult for new people who didn’t have much knowledge of the nature of work in some business areas and didn’t know a lot of other people at Trade Me. I found it surprising how little people knew about what else was going on at Trade Me and this day has shown that we need to make sure that new people are exposed to as many corners of the organisation as possible.

Even though most people appreciated the opportunity to be able to select their squad they either seemed to love or hate the idea. Our surveys tell us that the vast majority of people enjoyed the day and were happy with the outcome. A few though had a hard time and found it difficult to enjoy the responsibility and freedom of choice.

Squadification day process

We spent several weeks designing a process for self-organisation at this scale. We included a 20-people trial, many one-on-one conversations with people about their ideas and concerns, a company-wide presentation and several emails communicating the intentions and plans to everyone involved.

We also spent a full day cutting out materials (photos, ticks, skills lists), printing things (FAQs) and setting up the room with empty squad pictures, corners for each tribe, banners, example squads and product owner role checklists. I’m very happy that we spent all this time making sure everything was in place for the day to give people the best possible experience. Without the amount of work we had put into it the experience and outcome wouldn’t have been as good.

We had four full-time facilitators and one backup facilitator on the day. This worked really well as we could help people ask the right questions, reassure them that this really is self-selection and intervene when people broke the spirit of self-selection by telling others what to do.

We had the CTO in the room who through his presence publicly demonstrated support for the process and, to his full credit, didn’t intervene or show any preference for people’s choices.

Conclusion

We managed to create 15 fully formed squads and have firm plans for two additional squads - which is more than we had expected.

We learned a lot about what people really want to do and many people’s choices took us by surprise: Squads that we had thought were happy and stable chose to make major changes and others that we had thought were less appealing attracted a number of very good people. It proved that our assumption that “management doesn’t know best” is true.

In retrospect it was a great idea to include all tribes and invite everyone in the tech department. By being inclusive we respected that everyone should have a choice and learned that some people wanted to move squad or even tribe.

According to a survey of tech people involved, everyone was happy with the outcome and we are confident we could not have achieved this result without empowering people and using self-selection. Because we have allowed people to self-select we expect that this will give us more stability and happiness which will result in more productive squads (we will of course measure this).

Although David and I were nervous about the number of people involved the day went way better and easier than expected. It turned out that the process scales without problems and having been a part of this social experiment I feel comfortable to run a self-selection process with 250 people.

So, would I use self-selection again? Absolutely! It is low risk (worst case we learn something new) and, if successful, provides a fast, efficient and inclusive way of organising a company. I see a model for selecting teams with great potential for future use.

Next steps

Immediately during the two days following squadification day we held a Lean coffee meeting with each squad to discuss their start days, squad kick-off meetings and to create a backlog of things that need to happen in order to turn a flip chart with photos into a real squad.

The plan is to kick-off each of the 11 new squads during the next two months allowing for people to return from their Christmas holidays,for new hires to have started and for existing work streams to be wrapped up.

Our big squadification day was only two weeks ago and there’s still a lot to process for me so I will blog about more observations and reflections later.

---

WHERE TO FIND OUT MORE

We explain in a lot more detail just how the process works and use real-life examples from companies who have used this with 200+ people at a time. If you would like to read more, our book "Creating Great Teams: How Self-Selection Lets People Excel " is available from the Pragmatic Bookshelf and from Amazon.