Self forming teams at scale
I want to share with you all a strange thing that we do. It’s unorthodox but has been very successful for us.
Teams change. People come. People go. People move around. Reorgs happen. This is a fact of life, particularly in any large organization, and something managers spend a fair amount of time on – recruiting, re-recruiting, managing, developing, etc.
Many years ago (I want to say around 2008), we had a reorg to do. In general, we do them every couple of years, usually associated with some big milestone/inflection, and use them to rebalance, apply talent to the new problems, fund new projects, etc. Well, back in 2008, I had a guy on my team named Chris Shaffer – one of the better people managers/team morale managers I’ve worked with. He came forward with a crazy proposal.
The Crazy Proposal
Chris’s idea was this. Don’t do the reorg. Let people decide what they want to work on. Concretely, he proposed a process where we’d get the whole team in the room. We’d write the list of “feature teams”, investment areas, business priorities or whatever else you want to call it on a whiteboard and give everybody a sticky note to write their name on. In mass everyone would go to the board and put their sticky note next to the job they wanted. This included the manager positions on the teams. Once everyone had nominated themselves for a job we’d facilitate a group discussion until each manager role had one name next to it and each feature team had the right number of members.
That’s crazy, I thought. But he swore he had done it before and had been successful with it. As much as it sounded progressive and fun, I couldn’t bring myself to do it. I could see all the potential downsides – everyone wants to be on the cool new feature team, everyone wants to be the manager, all the strongest people end up on the same feature team, people argue over who gets to be the manager, etc. Real fears or not, I couldn’t get myself to try something quite this crazy.
The slightly less Crazy Idea
I liked the idea enough though that we took it and tweaked it to a new process that we’ve been using ever since.
The revised model works like this:
- It all starts with a planning process to make sure we understand what our goals and rough product investments over the next year or two will be. From that, we decide what feature teams we are going to have, how big they will be, etc.
- Next, we work through who we are going to make the Engineering managers and Program managers for each feature team (that’s 2 people out of 10-12 that will be on each feature team). I’d describe this as a someone traditional org model approach where we evaluate aptitude, interest, past performance, etc. We do this, of course, in concert with the candidates for the roles to make sure each ends up with a role they are happy with.
- We then have a team meeting where each Engineering/Program manager pair present their feature team to the whole team and “sell” it. The goal is to convince people to want to be on their team.
- After people have had a day or two to think about it, discuss with the managers, peers, etc., we get the whole team together again. We give everyone 3 sticky notes (First choice, Second choice, Third choice) and everyone goes to the whiteboard and puts their 3 sticky notes next to the teams they want to be on, in order of preference. The fact that people do this together in a room is important because it allows them to assess not only what they are working on but also who they are working with. In most cases, there are people they very much want to work with. In some cases, there are people they don’t want to work with. One of the inputs into your decision is what preferences other people are expressing.
- After the meeting, the managers get together and discuss forming their teams. Each manager has some say on who is on their team. We want to make sure teams are balanced, have the right skills to be successful, etc. At the same time, we very heavily weigh each individual’s personal preference. We leave this meeting with a first draft of the teams.
- That’s usually followed by some one-on-one’s with various people to make sure they are happy with where they are landing, etc. and the teams are then finalized.
After step 1, this whole process takes 3 or 4 days – so it’s actually pretty darned fast.
Some realities of the slightly less Crazy Idea
There are some realities of this process that are worth discussing.
- Ahead of the process, managers do some private recruiting. They’ll pick a small number of people they really want on their team and do a little selling ahead of time. In my mind this is OK as long as it doesn’t turn into arm twisting. In the end, the individual still gets to make their choice.
- Not everyone gets their first choice. That said, I’ve been shocked how many people get their first choice. The last time we did this, a couple of years ago everyone got their first choice except about 4 people who got their second choice and 1 person who got their third. And, in the exercise we just completed, every single person got their first choice. I’ve never seen that happen and never would have predicted it.
- Sometimes there are special cases. I can think of one time where we had an engineer on a specific feature team and we *really* needed him to stay there. We knew he wasn’t excited about it but he was the core of that team and we didn’t see how the team would succeed without him. We talked to him ahead of time and “begged” him to please stay on that team for one more cycle and promised that the next time he’d be guaranteed first choice. He did and, on the next cycle, he was given his first choice and it all worked out well. I can only think of one example where we’ve done this but I think it is a compromise that you have to consider.
- On occasion, we’ll encourage someone to switch teams. If they’ve been on the same team/technology for a long time and we think it will help their personal development, we might encourage them to consider changing. Again, in the end, it’s their choice but this process doesn’t completely relieve managers of the responsibility of thinking about how individuals best develop in their careers.
My assessment
So this is chaos right? Everybody changes teams all at the same time? No body changes teams and the org stagnates? Again, it’s amazing how organized it is. We’ve found, pretty consistently about 20% of the org decides they want to change what they are doing and work on something else and about 80% decide to keep working on what they are working on. That provides a nice ratio of continuity, fresh perspectives, opportunity to try new things, etc.
After each of the exercises I go around and take an informal poll. I talk to the managers. I talk to engineers who’ve been on the team for years. I talk to people who are new to our team. I talk to people who stayed on their team. I talk to people who switched teams. I ask them all what they think of the experience. I ask them if they are happy with both the process and the outcome. The overwhelming response I get is that people love it. Even people who choose to stay on the same team say they are grateful for having the opportunity to learn about all of the other feature teams and to make a decision about what they want.
It was a crazy idea. Maybe I could have made Chris’s even crazier idea work, but I like the variation we’ve adopted. We’ve done it 3 times now over the past ~7 years and have been happy with the results every time. I can’t promise it will work as well in every org but I can’t think of any reason why it can’t.
This week
As I mentioned above, we just completed our latest round of this exercise this week. We actually didn’t do my whole team this time. We did it in one part of my team which is an org of about 80 people. And, as I mentioned, every person got their first choice. That doesn’t mean every feature team was full. We have some open positions and we filled in gaps with open positions. I don’t believe any team ended up with more than 2 open position but some had 0, some 1 and some 2. So it’s not quite as big of a shocking coincidence as it sounds but still pretty amazing to me.
Here’s a picture of the managers organizing their sticky notes for the post meeting negotiations 🙂
Selling your feature team is certainly an important part of this process. The managers need to figure out how to articulate what they are going to be doing and why their feature team will be a fun place to work. People got really creative in selling their feature teams this time. One of the eng/pm pairs had a gimmick/skit. The PM opened by saying he would do push-ups for as long as the engineer talked. And he did. He slowed down a bit but he managed to keep it up the whole time 🙂
Conclusion
It’s crazy and it works. I love forming orgs this way. It’s a twist on “Self forming teams” that addresses not just allowing teams to decide how they work and how they divide up responsibility but also what they work on and who they work with.
Hopefully you find the story interesting…
Brian
Light
Dark
0 comments