How teams form and break up when there are no managers

Self-Selecting Teams” and “Dynamic Reteaming” are a big topic in my timeline thanks to the books by Sandy Mamoli & David Mole and the upcoming book by Heidi Helfand respectively.

This made me relize that I’ve written about the composition of our teams over the course of the years but not about how people join and leave teams. Let’s take a look at this now.

Crude self-selection into initial teams

We made the switch to Scrum and cross-functional teams in 2010. Tim (the CEO) asked two designers and me into a meeting room. There was a board with a table in it. Three empty columns headed Team 1 | Team 2 | Team 3. The teams would start with Scrum one after the other with two weeks (= one sprint) in between and we each should pick a column.

The three of us were the first ones who got to choose a column, so I just picked the first one. I was looking forward to getting started with this whole Scrum thing. I still think that many of the people looking forward to Scrum self-selected into that first team. It was certainly fun to be part of that team.

After us, the web developers got to distbribute themselves into the new teams, then the backend developers and so on. After each round choosers had more information to go on and could pick based on the people already in the team.

Surely not perfect, but there was already the seed of self-selection in there. Not too bad for total noobs.

This is how I’d approach it today

Growing pains: First split

These first teams only had a few months together before we had hired so many new people that the teams grew too large. We had to split to take in new members and train them. We knew we had to create 5 teams out of three (plus new hires). No team wanted to split. That’s why we decided that each team had to let go of some of its members. In my team we paired up people who had the same role and drew straws to determine who had to join a new team. It was not a happy time.

Secret transfer market

The resulting teams stayed together for years. Those that worked well together and those that just put on a show of working together alike. When somebody wanted to leave a team it was very hush-hush. Leaving your team was commonly interpreted as not liking the people in it, so nobody openly looked for a new team.

People looking to switch teams often turned to the Scrum masters to facilitate a “transfer”. Scrum masters had a good overview of which team needed someone.

Once we had Yammer we started publishing “open positions” in teams, which made at least this part of transfers easier. Sometimes product owners would recruit entire teams, beginning with a Yammer post (followed by face to face conversations).

Law of two feet

I credit Open Friday with smoothing the “wanting to leave a team” part of the equation. Over time many people internalized the Law of two feet:

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.

It’s applicable to more than Open Space sessions. We use it for team membership now, too. When people feel that the team’s tasks have shifted significantly and long-term and that their skills and what they want to do don’t match anymore, they will tentatively check out other teams.

If you want to leave you still don’t broadcast it, but it’s not as hush-hush as it used to be. And now you often turn to the team you want to join directly instead of using intermediaries.

Fluid pools of people

The latest development is having a pool of people per product instead of two or three teams. For each sprint the people in the pool will divvy themselves up into teams, according to the tasks at hand. This is an on-going experiment. The people in the pool have decided to try this about 2 months ago. We’ll see how it works out in the long run.


Published