7 Common Hesitations About Self-Selection (And Why You Should Still Persevere)

Whenever I pitch self-selection to someone new, unfailingly, I watch them go through various stages of emotion. First it’s “That’s really cool, this could solve our problem with retention or motivation or [insert other issue here]”, followed quickly by, “but wait, it won’t work because of [insert fear here]”. Below, we’ll address the common “what if” questions and explain what to do or say about them.

1. What about the work that no one wants to do, but HAS to get done?

Every company has key, routine, or dull work that no one wants to do, but that has to get done. This is usually maintenance work, production fixes, or the project for which only one engineer has the vast majority of the knowledge (and she wants to go do something else). In self-selection, there is one rule that permeates the entire process and ensures that this work is not dropped: “Do what’s best for [insert your company name here].”

If some participants are choosing teams based on the “Do what’s best for the company” rule, won’t they feel angry because they had to make sacrifices that others didn’t? It turns out that they won’t! At Opower, 40% of our engineers primarily chose their teams based on what was best for the company, but 100% of them were happy about where they ended up. How can that be?

Team Happiness
Figure 1: Are you happy with the teams you ended up on?
Self-selection choices
Figure 2: What primarily drove your self-selection choices?


The answer is that being part of the decision-making process instead of having a position handed to us actually makes people happier because we had a say in the decision. The golden rule “Do what’s best for the company” is a guideline that resonates with almost everyone. If you introduce the rule early and often (even hanging it on the wall during your self-selection event), you’ll notice people referring to it throughout the event and using it as a reason to make decisions and break stalemates. Key people realize very quickly that they are needed on a specific team. If they want more mobility  in the future, a cross-training plan should be created.

Furthermore, through the self-selection process, people who pick one team, but ultimately move to another one “for the good of the company” are raised to a type of hero status (they’re taking one for the team). You’ll also discover where your key people really want to be, so you can start succession planning and open a dialog about how to get them there. Participants gain respect and appreciation while the business secures fully-skilled teams in the short-term.

2. What if someone is “last picked for the kickball team”?

I was personally very worried about this one. I’d had visions of software engineers stranded on a team by themselves because no one wanted to code with them.

In every self-selection event that I’ve been a part of so far, no one has been stranded on a team by themselves. Is this because we’re all adults who have left the trials of middle school rightfully behind us? I don’t think that’s the only reason. Self-selection is not a process of being picked, it is a process of choosing for yourself where you’d like to go. You won’t leave yourself stranded, you’ll surround yourself with the people you like to work with and work that you love to do.

3. What if I make a mistake? Am I stuck on this team forever?

The answer to this question should always be no. One way to ensure that your newly-selected teams are happy AND that people get on board with trying self-selection is to ensure you check-in with your teams 3-6 months after they’re formed. At this point, ask your engineers whether they are still happy with the teams that they’ve chosen. Make it clear that they’ll have this choice from the beginning. Keep metrics (velocity, burndown, etc) that help you understand whether the teams are operating effectively. Usually, after a quarter or two, teams are quite happy, are relatively efficient, and won’t want to move (this is ideal, since it takes 4-6 sprints for teams to become high performing and for their velocity to stabilize). However, having the option to move gives you a lot of leverage up-front and a reason to survey your teams to discover their happiness levels in the future.

4. What if I don’t have enough people to fill out my teams?

It’s normal to end self-selection with some open positions on each team. Use hiring reqs, if possible, to fill in the open positions. If you have no openings, reduce the amount of work the smaller teams are doing. If that work is absolutely necessary, remind people to do what’s best for the company, point out teams whose work can be reduced, and start another round.

5. What happens if there’s a stalemate before the teams are filled?

It’s very likely that you’ll reach a stalemate at some point in the self-selection process. In fact, according to David Mole, co-author of Creating Great Teams, most companies see a stalemate in round 2 or 3. To break the stalemate, have a moderator encourage individuals to discuss their motivations for joining the teams that they’ve chosen. Look for ways to satisfy their needs elsewhere, either by moving work between teams, allowing them to try new skills on another team, or pointing out the merits of working with others in the room.

Some stalemates may not be entirely broken. If this happens, evaluate the option to keep teams the way they are and fill other open spaces with open hiring positions.

6. What about my current work/projects?

This is a concern both for employees and employers. You’ll need to build time into your schedule after self-selection for cross-training. Remember that cross-training is not time wasted! It’s an insurance policy for both retention and against attrition. Every time someone switches jobs, another employee has to learn what they did. The good news is that you’ve now got a back-up for when one person goes on vacation or leaves the company. You can either set aside an entire sprint for the transition or spread the transition out over a couple of sprints. Pair programming works particularly well in this situation and has the wonderful side effect of producing code that is more robust (and possibly a new friendship or two). 

7. What if someone else picks the project I want to be on?

This may happen. If a participant feels strongly about that project, they should pick it too and be ready to explain why they believe they’d be the best candidate in this situation. Their arguments may include: time already in the position, their relationships with the other team members, new skills they believe they’ll help the organization gain, mentoring opportunities, etc.  The other participants and moderator will help the team work through who the best person for the job should be. In the end, make sure everyone follows the golden rule: do what’s best for the company. Worst case, they’ll have the opportunity to switch teams in 3-6 months.