What holds us back from self-selection reteaming?

Organization leaders and development team members can find the notion of self-selection reteaming troubling. Why is that? What is holding us back from giving software engineering folks a greater influence over the work they do and the people they work with?

I think, as a software development community, we’ve been conditioned to believe that very stable teams are best. It’s received wisdom that teams with stable membership perform better, that we should keep people together for predictability and that we don’t want to have to needlessly repeat our progress through the Tuckman model of ‘forming, storming, norming & performing’ for each project. No one is going to criticize the notion of keeping teams the same – it’s a safe option for leaders! But there is a significant burden of proof for the leader who suggests deliberately changing teams as it’s counter-intuitive for most organizations.

So we need to get over that traditional wisdom, accept teams do change (whether we like it or not), explain the benefits to the wider organization and take the decision to harness reteaming to create opportunities for individuals and for teams to refresh themselves. To read more about some of the benefits we’ve found of a self-selection style reteaming, check out this post.

I think fear holds us back too. For those in leadership positions, this approach can be really concerning – I know it was for me before we tried it – as it feels like we are losing control of the composition of our teams. We can catastrophize when faced with the notion of asking people to decide where they want to work, surmising that the process will be chaotic and that the result will be unfit for purpose, having been built without the wider context of the needs of the business or input from stakeholders. We’ll suppose that some of our teams will be totally abandoned, some will be oversubscribed and some will end up people without the skills to be a success.

Some of our concerns might be well founded, who is looking out for the needs of the org? The needs of the work, the product or the business could get lost. Everyone might look after themselves and the overall goals will be missed. Effectively, we’ll assemble a jigsaw without looking at the picture on the box.

However, after three years we’ve found that our worst fears do not come to pass. Firstly, not everyone wants to change team during reteaming, so a core cohort of people remain in any given team. Secondly, if leaders are clear in specifying the minimal constraints on the composition of their team – for example, that the team needs two engineers who are proficient with React JavaScript library or experienced in leading usability interviews with customers – then people take this into consideration when considering their preferences. And finally, as we have a group of leaders who look to assemble preferences into a team structure that is fit for purpose, we are able to help shape the final outcome so that the needs of the business and the teams are also accommodated.

Self-selection reteaming can create anxiety in team members too. If we were to go to an extreme with this approach, people would have complete freedom to decide what team to join and when to join it, without the need to share intent or coordinate with anyone responsible for the overall organisation. This kind of approach can be characterized by a big self-selection ceremony, where you go along to a single event and sign up for a team on the spot, and everyone else will do the same.

In those kind of sessions, a significant cohort of people may not feel able to put themselves forward for the team they really want – perhaps those of us naturally a little more introverted or people grappling with imposter syndrome or those that are neurodiverse. They may not have the confidence or the tools to get assigned to the team they would prefer. Also, the pressure of attending that session and deciding during it where they will spend their working lives for the foreseeable future could be quite crippling for some. I think it might have been for me when I was a software developer.

Those folks might not get a choice and end up with whatever is left over. In my opinion, that kind of process, although aligning with principles of self-determination (autonomy, mastery and purpose), heavily disadvantages a significant cohort of people in software development.

But we find a balance. Applying an approach that meets the principles of self-determination, while ensuring the needs of the organisation and minimizing the anxiety of everyone involved. So ours is a curated process. We mindfully gather the preferences of people in the teams, providing support and space for them to consider the options, and assemble the teams considering wider context and utilizing the experience and insights from our software development leaders.

To find out more about how Redgate does this, check out this post.