Step 4: Define the Teams to Select

Once you’ve defined your readiness, gotten permission, and evaluated whether you should run a trial, it’s time to define the squads that people will select into. It’s possible to give people a roadmap and product strategy to determine which squads are required, but for us this proved to be too complex. Not only did staff members not know where to start, but they also didn’t know how best to meet the needs of the organization.

The squads to establish can reflect your current structure or, if you’re not yet working in teams, you’ll need to make a decision about which squads are needed. For us this was a complex proposition that required company-wide reflection about our mid- to long-term goals and priorities. We wanted to make sure that our squads would have a purpose that went beyond the current project so that we could reap the performance gains that come with stable squads.

At first the company-wide prioritization involved only the executive team and was heavily tied to our strategy. But when the employees heard about the plan to establish stable squads, they understandably wanted to get this right. We kept a strong eye on our company strategy but also established a simple process to submit a request for a new squad: if you wanted a squad that could support a feature stream, a product, or an area of the business, the executives would consider it for inclusion. In the end, the executives simply voted on the squads they wanted to create.

It wasn’t easy to establish exactly how many squads we needed, and we knew that the number of people in a squad would vary (between three and seven), but we also knew that gaps could be filled by future hiring, so we focused on business needs and erred on the side of slightly too many squads rather than not enough.

We planned to create a total of twenty-two new squads across three locations (Auckland, Wellington, and Christchurch in New Zealand). Similar to Spotify’s structure we already had co-located tribes in place in each city. With property and motors being in Auckland, for example, marketplace and dating in Wellington, and jobs in Christchurch, we were never in doubt about in which location we would need to create a squad.

Having prioritized and planned for the squads, we next needed to paint a clear picture of their purpose so that participants could choose what they wanted to work on and the kind of problems they would solve.

For our Squadification Day we wanted each squad to have the following:

• A squad name

• A clear vision and mission for what it would do

• A product owner

We did this because we didn’t want anyone walking out of the self-selection event feeling like they weren’t sure what they had selected into, or worse, thinking farther down the line that “this is not what I signed up for.”

Establish Squad Names and Missions

We prefer squads to have a clear mission rather than to be general purpose. In his 2002 book, Leading Teams: Setting the Stage for Great Performances [Hac02], J. Richard Hackman cites research showing how teams need to have a clear, challenging, and consequential purpose to engage members’ motivation and to orient them in a common direction. Without purpose, collaboration will suffer and the squad will never reach a high-performing stage.

Defining the purpose of a squad is a task best suited to the product owner. The product owner is, after all, the person in the best position and able to give examples of the kind of things members could work on in a particular squad. This was something of a balancing act because we didn’t want to promise certain projects or a specific roadmap that might change and lead team members to question whether they had signed up for something that didn’t turn out to be true.

The better the product owners can explain their squad, its mission, and how they themselves work, the better chance they have of attracting a great squad and, just as important, the right squad to match them and their working styles.

Here are examples of the names and missions for some of our squads:

• The Buyer Squad: Make our buyers’ lives easier.

• The Fashion Squad: Create an awesome experience for buying and selling clothes.

• The iPad Squad: Create a great user experience on the iPad.

• The Business Operations Squad: Make the lives of our operations and customer service squads nice and easy.

Most of these squads supported a specific group of end users or a platform. We tried to avoid component squads because we strongly believed that having an end-to-end view and a customer-centric purpose would give us the best results.

We’re also strong advocates of allowing squads to choose their own name. The names we initially chose for self-selection were preliminary names to reflect the purpose, but we had no issue with squads changing their names after they had kicked off. Even if that decision was to keep the suggested name, it was important that they had the decision in their own hands, thus hopefully creating a greater sense of ownership.

Preselect Certain Roles

The Lancaster bomber squads described in Self-Selection Has a Good (and Interesting) Track Record self-selected with an engineer and second gunner already in place. The engineer needed to undergo specialized training, and the second gunner would join at a later stage. The pilot, bomb aimer, first gunner, wireless operator, and navigator then self-selected into squads with those two roles preassigned.

Since our product owners were quite specialized, often with years of industry experience in one area of the business, we opted for preselecting the product owner for each squad. We deemed it too risky to encourage, for example, a product owner with years of experience in trading cars to move to one of our real-estate squads.

Another reason we chose to preselect the product owners is that they’re the people who give the squads direction. This turned out to be beneficial because it meant that we had a relevant and competent person to explain about the squad at the event itself.

Andy Kelk, technology lead for digital mailbox at Australian Post, made a different choice, where he chose to pair a product owner with a scrum master before letting the teams self-select:

I think what was a really big benefit was having those iteration managers (scrum masters) and product owners tied up from the start and having them as the real kernel of the team. Giving that team an identity was really, really important. We actually spent quite a bit of time trying to pair up those iteration managers and product owners. That in itself was a whole exercise, which required a lot of bravery from those people because they had to put themselves out there and choose each other and do a bit of a “speed date.” That was a fairly confronting experience for them, but it really cemented those relationships, which meant that those teams had a kernel.

It’s entirely up to you which roles, if any, you choose to preassign. We recommend to choose as few as possible to honor the spirit of self-selection.

Decide if You Will Start from Scratch

It’s also important to decide whether your self-selection event will be starting from scratch (empty squads) or if you already have some people who will have to work in a specific area, perhaps for experience reasons or a rare specialist skill. If you do have preselected people, it’s important to reflect this openly, because otherwise any done deals would make employees see the process as rigged and put your event at risk.

The advantages of starting completely from scratch are that it can be simpler and easier to throw out any current constraints and starting from a blank sheet can be easier for everyone. It can reduce the complexity of the problem and allow people to consider options they may not have otherwise realized would be possible.

On the other hand, starting from the status quo—reflecting a current team structure as the starting point—makes the process real, and it helps those who want to stay exactly where they are to do so and not feel like they’re being bumped.