BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Lessons Learned from Self-Selection Reteaming at Redgate

Lessons Learned from Self-Selection Reteaming at Redgate

Bookmarks

Key Takeaways

  • Redgate Software runs a deliberate reteaming process to respond to new and changing needs of their business each year. Their approach has been to allow people to strongly influence where in the new team structure they will work, encouraging them to move towards the work they find most engaging.
  • Aiming to maintain very stable teams might be an unrealistic and harmful goal for software development organizations. Teams naturally change all the time and very stable teams can stagnate and become silos of knowledge, harming the overall organization. 
  • Deliberately changingnup teams and giving people the opportunity to move towards the work they find most engaging has driven personal growth, staff engagement and cross-team collaboration at Redgate. It has also provided the organization with a responsive and popular process to decide team assignments.
  • Redgate has been able to meet the team preferences for 97% of their engineering staff during their three years of reteaming. Each time around, a third of people have decided to move teams. This has had no detrimental effect on software delivery performance or customer satisfaction.
  • As with any reorganization process, self-selection reteaming can generate anxiety for participant team members and managers. It’s paramount that leaders have a deep empathy for their people throughout and apply a process that reduces worry and uncertainty as much as possible.

Reteaming at Redgate

At Redgate Software, for each of the last three years we’ve run a deliberate reteaming process across our engineering organisation to alter how we invest the efforts of our teams and encourage our people to move towards the work they find most engaging. You might be wondering: why on earth would we do that?

Well, firstly, we have a business need to reteam every year - that is, change the composition and assignments of our development teams. Each year Redgate takes a step back to consider its strategy for its portfolio of products and solutions. That review is a catalyst for change, as the business often decides it wants to start-up new initiatives, reduce investment in some areas and increase in others. And they expect us to be agile and responsive to these changing needs. As a result, we need to reconfigure how our teams are assigned, which causes some change for people but also creates opportunities.

We’d also spotted that our longer-lived development teams were not talking to each other as much as we’d like. When teams did not need to change due to the strategy in their area persisting, they had a tendency towards siloization. Those teams had a strong mission and were self-sufficient, so they did not really need to collaborate with people outside the team very often. This meant that connections weren’t built between teams naturally. 

Not only did that silozation limit our efforts to collaborate between teams, it also reduced the spread of good practice and expertise between teams and reduced personal development opportunities.

A self-selection approach

So, there were several drivers to deliberately reteam, but why apply a self-selection process? Broadly speaking, it’s because we believe that it aligns with our principles and helps provide fulfilling work for our people, which improves engagement and the organisation’s performance.

At Redgate we believe the best way to make software products is by engaging small teams empowered with clear purpose, freedom to act and a drive to learn. We believe this because we’ve seen it; teams who have had laser-like focus on an aim, decision-making authority and the space to get better at what they do, were the most engaged and effective.

If you have read Dan Pink’s seminal book Drive: The Surprising Truth About What Motivates Us, you might recognise that our beliefs echo what the author demonstrates are key to an engaged and motivated workforce — autonomy, mastery and purpose. 

To remain true to our beliefs, Redgate needs to ensure that the goals and expectations of our teams are crystal clear, that we push authority to teams as much as we can, and we encourage people to grow. We also recognise that different people have different ambitions, preferences for work and views on what counts as personal development. We have a large portfolio of products, written in a variety of languages, structured in a variety of ways and that exist at various stages of the product life cycle. That’s a lot of variety, and people are going to favour some combinations over others. They may also see a change of combinations, moving to work on something they have never worked on before, as an opportunity for personal growth.

As we believe that paying attention to people’s drive to learn is important, we knew we should allow people to take on work that they are drawn towards, either because they feel it will suit them better, they want to gather new experience, or they like things just as they are.

In the past we’ve always allowed people to move teams — everyone could proactively talk to their line manager at any point to kick-off a process that would result in a team move - but that wasn’t enough. We needed to do more than just allow people to move. Team bonds are strong and it’s difficult to break the inertia of working in a team you are comfortable in. Instead, we need to make it really easy for people to move, by creating opportunities for a change, making it a truly reasonable thing to do, being clear on the options available and helping people move towards the work they find most motivational. 

Hence, we decided to embark on our first self-selection reteaming process in December, 2018.

How we reteam

Our reteaming process has six stages: we share our plans for teams, we confirm leadership assignments, we encourage everyone to explore the team options that will be available to them, we ask those people to share their team preferences, we decide team assignments based on those preferences and, finally, we deliberately kick-off our new teams.

Sharing plans

First, we share the context for the teams for the upcoming year with everyone in development, as soon as we can. This “big picture” is our newly-minted portfolio strategy and plans for the workstreams the company feels it needs. We also explain the overall reteaming process. As you might imagine, the process of setting the strategy for a product portfolio of over 20 products can take some time to set in stone. We aim to share plans as early as possible, when enough is certain to begin depending on it, but not all the questions are answered (we’ll need team leaders and teams to help us do that).

Confirming team leaders

Then we engage with the key leadership roles that support our teams - technical team leads, product designers and product managers - aiming to establish where they would prefer to work in service of the new strategy. Many team leaders decide to stay with their current teams, but some choose to move (or have to move if their team’s mission is no longer one the company wants to pursue). We get those team leadership roles settled first, looking to meet as many people’s preferences as possible. We do this first, not because they are the most important people to please, but because we need those folks to help us shape the details of the plan for the next year and support the rest of the engineering organisation in reteaming.

Defining what teams will be like

Next we aim to light-up the options people in our engineering teams have to consider for the next year. Our leadership teams, now confirmed in their areas for the coming year, provide the details on what life would be like in their team; what is their mission, what impact will they aim to have, what will they own, how will the team work, and so on. This information is of paramount importance for people who are deciding where they would like to play their part, and where they will feel most fulfilled.

Exploring team preferences

We run an open session for everyone to explore what life will be like on the teams and ask people to consider whether they would prefer to stay with their current team or move to another team. We say “prefer” rather than “choose” or “select,” because while we endeavour to meet as many people’s preferences as possible, we can’t guarantee that we can meet everyone’s selection. 

Deciding team assignments, based on preferences

Next, we support everyone in confirming their team preferences. We have a coaching conversation with everyone one-on-one to help them explore and confirm their preferences. This is a big investment, a one-to-one conversation with everyone in the department, but it’s worth it. We ask people to tell us their 1st, 2nd and 3rd preferences for their team for the coming year and the reasoning behind those preferences. The department’s leadership team then takes a step back to see how people’s preferences line-up with the big picture we needed to create. We assemble a team structure that meets as many people’s preferences as possible while ensuring we have teams that can meet the needs of product strategies. We talk to everyone who has not been assigned to their first team preference (around 20% of people, as ~80% get their first preference) to ensure they understand why they are being asked to move their 2nd or 3rd preference team and confirm they are comfortable with that. Typically everyone is ok with that - getting your 2nd or even 3rd preference is not bad news.

Kicking-off the teams

Finally, we share the news on team assignments widely and kick-off the new teams. To form teams quickly, our team leaders have become well practiced at running workshops to share product histories, light-up plans and start to build trust in new groups. 

The results

The first year went so well that we repeated it for the next two years. Now, reteaming is an annual event and I can’t imagine us taking an approach that does not give people a strong say on where they work.

Each year we have been able to assemble effective teams that have a clear purpose, are populated with people pleased to be there and are able to quickly get up-to-speed & deliver. We’ve proven to the business that we can respond with agility to the needs of the company and give people a stronger say over what they work on.

People ask me how much movement there actually has been across teams and enquire suspiciously as to whether Redgaters really do influence the process. I think the stats show that people have a really strong steer over team assignments. In the three years we’ve been trying this approach, 77%-83% of people have been placed into the team that was their first preference. Even more reassuringly, 97%-98% of people have been placed into a team that was one of their preferences (1st, 2nd or 3rd). 

In the end, each time around a third of our team members move teams. Yep, that means two thirds stay in their teams, and that’s fine. It shows that our teams are, in general, good places to work and people feel happy and motivated where they are. That third of people moving across teams is hugely valuable too. That movement helps break down silos, building connections across the development organisation. It spreads knowledge and best practice, and it normalizes the process of moving teams. Each move represents someone choosing to take up a new challenge. Here’s an animation I like that illustrates just how much cross-pollination you get in a development organization if a third of people move teams each year.

Furthermore, each time we have done reteaming, software delivery performance has not been impacted materially. At Redgate we measure the Four Key Metrics of software delivery performance as described in the book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. They are: delivery lead time, deployment frequency, mean time to restore service and change fail rate. Those measures are stable during reteaming, registering only a slight dip in deployment frequency and lead time as team members move. This recovers within weeks and has no impact on the service we provide to our customers.

Improving through feedback

After each Annual Reteaming, we asked our development team members for their feedback. What they’ve told us has been broadly positive each time, but has also highlighted areas for improvement that we’ve been able to focus on in subsequent years. We’ve fine-tuned the process to make it as smooth and timely as possible for the organization, but also as comfortable as possible for our people. For instance, our first reteaming happened during December, which many people found difficult because they had holiday booked during that month, so they missed some of the context for decision-making and felt a bit rushed. Each year since, reteaming has taken place in January when virtually everyone is back at work and can fully engage in the activity.

What is absolutely clear from feedback each year is that people far prefer being consulted and involved in these kinds of team reorganizations than being moved around by arbitrary people moving a machine (we literally got that feedback on a sticky note after our first reteaming)!

We’ve learnt that there was a pent-up desire for people to move teams and that many do see changing teams as a personal development opportunity. We’ve gone from an organisation where people barely ever moved teams, to one where it’s an annual, regular activity.

But the main takeaway for me is that this approach works! It’s possible to give people a strong say over what team they are in and assemble an effective development organisation. We can do this repeatedly and in the open, staying true to our principle of providing people autonomy, mastery and purpose.

And in the last year we’ve also learned that we can do all this while everyone is working fully remote!

Obstacles to reteaming

As a software development community, we’ve been conditioned to believe that very stable teams are best. It’s wisdom to know 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 criticise 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 organisations. 

So we need to get over that conventional wisdom, accept that teams do change (whether we like it or not), explain the benefits to the wider organisation and take the decision to harness reteaming to create opportunities for individuals and for teams to refresh themselves.

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 without the skills required to successful.

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. 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 our customers 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 does the same.

In those kinds 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 who are neurodiverse. They may not have the confidence or the tools to get assigned to the team they 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 can 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.

Benefits and drawbacks

I’ve found that stable teams are not the norm. More often than not, people leave and join teams, they leave and join companies and businesses decide to change what they spend their people’s time on. All that changes team composition, effectively meaning you have a new team to form.

However, let’s say we did have a genuine long-lived stable team; then I think the drawbacks are that they can easily become siloed and stagnant. Unless we are very mindful, they can become stuck in a rut as a team, unable to see those issues or bring in new ideas. This can mean a lack of opportunity to learn other systems in the organization and/or other technologies – leading to disengagement. It can lead to people being stuck as experts, unable to ever move teams because there is just too much important knowledge in their heads. And silozation can lead to a lack of alignment and connectedness between other teams in the organisation.

Changing your teams up regularly can ameliorate those problems. However, there are drawbacks too. It obviously takes effort and time to create and run a process to do this, supporting teams and individuals along the way. For instance, a lot of thought goes into creating team charters, with leaders having to back brief strategy through them and think deeply about what they’d like their team to be like in the coming year. But, to be honest, I’ve found this to be a very useful thinking tool for leaders to deliberately work through.

Changing teams, or the prospect of having to change teams, can also cause anxiety. We learnt that via feedback from participants. In our post-activity survey, a significant proportion of people (39%) felt anxious about the reteaming process at some point. That’s even though we have always been very mindful of the stress that can be caused by organisational changes and why we offer things like 1–2–1 coaching conversation for every single person who is part of the reteaming process.

A sympathetic solution to the anxiety reported to some might be to say, “Ok, we’ll stop annual reteaming then”, but that wouldn’t be in service of a central principle we hold dear at Redgate — the ambition to give people autonomy, mastery and purpose. It also would not reflect the reality that reteaming, the changing and forming of teams, will always be necessary. Cancelling deliberate reteaming would also not help break down team silos, create personal development opportunities or spread good practice. No, self-selection reteaming is here to stay, but we should minimize the level of unnecessary anxiety (or dis-stress) caused by a reorganization process like reteaming.

In response to the aforementioned survey result, we’re going to set clearer expectations from the start of next year’s reteaming process that if someone’s preference is to stay in their current team (and that team is continuing on its current mission), then we’ll do our utmost to ensure they can stay in that team. In fact, this is what happened at our last reteaming - everyone who wanted to stay where they were stayed in their team. Our theory is that this important caveat will lessen the anxiety felt by those people who are very keen to stay. Again, we’ll ask for feedback following reteaming to see if that is borne out by the data.

The key point here is that, as with any reorganization process, self-selection reteaming can still generate anxiety for participants. It’s therefore paramount that leaders have a deep empathy for their people throughout, and are considerate of the uncertainty and worry that may be being created for some.

A self-selection reteaming process is not an easier way to change teams. It’s a tricky thing to convince an organisation to do; it takes effort to nurture the environment to support it and coach individuals to help them explore options. But we do think it’s a better way, as opposed to a traditional top-down approach.

How to start

For planning and running self-selection, I’d recommend reading Heidi Helfand’s book Dynamic Reteaming, to get a grounding on the subject and the full story of how and why we should embrace changing teams. We’ve also shared many more details of Redgate’s approach to reteaming on our blog – so I’d check out Reteaming at Redgate.

Your first reteaming process might sound like quite a risky venture for the organisation and management can fear losing control or catastrophize (I know I did). So, be mindful of that. Explain the longer-term benefits to the leadership of the organisation, highlighting if you are seeing some of the drawbacks of stagnant or siloed teams, but build in some safety to your proposed process. For instance, Redgate has those one-on-one coaching sessions and an explicit sanity check that the resulting organisation is fit for purpose before moving ahead with team moves. That way everyone is more comfortable and ready to engage with the idea.

I wouldn’t recommend copying Redgate’s process in its entirety though - it was built by us, for us, and is unlikely to fit the context or needs of your organisation. Rather, perhaps what we do will provide some inspiration and you can keep in mind our key principle - to give our people a strong influence over what team they are in and the work they do.

Conclusion

Three years down the line, Redgate has found that annual self-selection reteaming is an effective and empowering method of aligning with new company goals. The engineering organisation has proven to the business that it can respond with agility to the needs of the company, while giving people a stronger say over what they work on. 

From an organization where people hardly ever moved, reteaming has now normalized the idea of people moving between teams for personal development and a renewed sense of purpose. The organisation has come to re-evaluate the traditional wisdom of aiming for very stable teams and recognises the virtues of deliberately and thoughtfully changing-up teams. This approach has helped Redgate nurture a development culture of engagement, resilience and opportunity.

References

  • Drive: The Surprising Truth About What Motivates Us by Dan Pink
  • Dynamic Reteaming: The Art and Wisdom of Changing Teams by Heidi Helfand
  • Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble and Gene Kim
  • Reteaming at Redgate” articles by Chris Smith

About the Author

Chris Smith is head of product delivery at Redgate. His job is to lead the software development teams that work on Redgate's ingeniously simple database software, building teams with clarity of purpose, freedom to act and a drive to learn. For the last three years Smith has lead Redgate's annual reteaming process which gives people a strong influence over which team they are part of, encouraging them to move towards the work they find most engaging


 

Rate this Article

Adoption
Style

BT