How we’ve adapted our approach to team change to be more dynamic and efficient, and retained the good, people-focused, stuff.
Our journey so far with reteaming…
Since 2018, Redgate has applied a process we call “reteaming” to shape our groups and teams, responding to Redgate’s strategic aims and investment decisions for the coming year. The fundamental idea behind reteaming is that we should change our team structure in collaboration with the folks that work in those teams, enabling them to have influence over which team they work in. The process has enabled responsiveness to business needs while providing individuals with the opportunity to change teams to work in areas that align with their interests or support their professional development.
Why do we give people a strong influence over which team they work in? After all, it’s significantly more effort for us to create the environment, share the information, and manage the process that allows people to guide which team they work in. However, we gladly invest that time and effort because we believe doing so aligns with our principle that people will be most engaged and motivated in their work if they have autonomy, mastery and purpose. In the case of reteaming, that means autonomy over what work they do, the space to gain mastery or develop their skills, and to work in service of a clear purpose they understand and believe in.
We’ve also found that deliberately encouraging some movement between teams spreads knowledge, best practice, and innovation, as people joining a new team bring experience from their previous teams with them. Reteaming also helps spread social connections throughout the organisation and break down team silos.
You can read more about our journey with reteaming here.
What prompted us to evolve our approach this year?
As we moved towards our latest attempt at reteaming, aimed at reconfiguring our teams to support Redgate’s 2025 product and technology strategies, we realised that the needs of our now larger organisation, and the improved processes of the business, meant that we needed to evolve our approach to reteaming. It was time to inspect and adapt.
Firstly, we’re a much larger organisation than we were in 2018, making some of the reteaming processes we were using inefficient and time-consuming. For example, ever since our first attempt at the process the majority (around 2 in 3) of engineers have preferred to stay in their current team, and therefore did not move during reteaming. Collecting these common choices manually from everyone was becoming an increasing burden.
Secondly, our product groups had a greater range of strategies, users, and technology stacks — causing movement between teams in the same group to become more popular than movement into another group. We also recognised that novel technology choices for specific products could increase the impact of experts in that technology moving out of the team.
Thirdly, and perhaps most importantly, (Ed: so, why do you mention it third then?!) Redgate have been gradually moving to a more iterative (or evergreen) strategy process, rather that a having a bigger-bang re-plan at the end of each year. This might also mean the business wants to make more significant changes, such as creating a new team, throughout the year, when market or product opportunities occur, rather than saving most significant changes to the next January.
In summary, reteaming needed to become more agile, more efficient, and support varying needs of our product groups.
What we changed this year
The key changes we made for 2025’s reteaming were:
- Using an new internal opportunities board to share open and new roles throughout the year. If an engineer wanted to move teams during this reteaming, they did that by interacting with this internal job board and registering interest in a specific team. This streamlined the process of asking for a team move and will allow us to be more transparent about open roles in our teams throughout the year.
- Creating an “evergreen” Information Hub for team information and insights. Previously this information has been captured in ephemeral “team charters” prepared specifically for the reteaming process. In addition to avoiding one-off costs of building these canvases, the Hub is useful for Redgaters inside and outside of Engineering to explore the purpose, aims, responsibilities, and objective progress of each of our teams throughout the year.
- By default we now assume people want to stay in the team they are in. In previous years, most team members opted to stay in their current teams. Nonetheless, we encouraged everyone to also express their interests in other teams, both for personal development and to provide leadership with more options when forming new teams. For some, this created additional anxiety about reteaming due to uncertainty about possibly leaving a preferred team. This year, we decided to relax that requirement and assume that if individuals did not indicate an interest in another team, they wished to remain in their current team. However, to support this change and be transparent with participants, we called out that we may approach Engineers to suggest a team move if we believe their skills and experience could significantly benefit another team’s success. Interestingly, when we did that in a handful of cases, engineers were generally very open to moving towards work that had been identified as a great fit for them.
On reflection, these changes may have moved our approach closer to something what would meet the needs of other tech organisations — rather than the, perhaps idiosyncratic, requirements of our fairly rigid annual strategy process. I’ll leave that to you to decide.
This year our intention was to observe how these modifications would affect an already effective process for the Engineering organization. There was a concern that not requiring everyone to share team interests might limit leadership’s ability to create appropriate teams, due to having fewer team preferences to consider. However, it was anticipated that this year there would be fewer changes in product strategy and team investments compared to previous Januarys (for example, at the beginning of 2024, four new teams were created within the engineering organization) due to our more iterative strategy process.
So, what was the outcome?
The headline is that the evolved reteaming process allowed us to create a roster of teams aligned with the aims and investments of our product and system strategies 🎉. In terms of the outcomes for engineers, 95% of folks are in a team they sought to be in, and we were able to support team moves for 11 engineers (most of those moving teams within a product group).
The below graph shows that 11 engineers moving teams represents the lowest team movement percentage since we started applying a reteaming approach. Given that there were relatively few changes in product strategy and team investments that is not surprising. Nevertheless, this may still feel like a retrograde step in terms of supporting personal development aims and breaking down team silos. However, it’s worth noting that only around 10% of engineers registered an interest in moving teams, so there was not a great deal of demand for changes. This year also returned the highest ever percentage of folks that have ended up in their preferred team, which indicates we are still supporting the self-determination principle central to our approach to reteaming.
2025 Redgate reteaming by the numbers
- 9.1% engineers moved team
- 94.5% engineers are in a team they sought to be in
- 91% of engineers are in their 1st preference team (the vast majority of these preferring to stay in their current team)
- 4 hours was the approximate time individual engineers spent on reteaming activities over the month the process was playing out
What did participants think of the process this year?
As we do with every reteaming, we surveyed participants to see how it worked for them and identify where we could improve next time. On this occasion, we also wanted to see how the changes we had made felt for those involved. Here are the highlights of what participants told us:
- 89% of respondents felt comfortable with the outcome of the reteaming process. This is an increase of 7.5% on last year’s process
- 92% of respondents were happy with their personal outcome from reteaming, 1.7 % of respondents were unhappy. This is the same as last year’s process
- 93% of respondents felt their team gelled quickly or continued unaffected following reteaming. This is the same as last year’s process
- 92% of respondents were satisfied with the shape of their team following reteaming (5% increase on last year)
- 13.5% of respondents felt anxious at some point during reteaming (a reduction of 6% over last year)
- 0% (!) of respondents do not support Redgate’s approach to reteaming
From these measures it seems that reteaming was a positive experience for the majority of those involved. Respondents apprieciated the default assumption that people wanted to stay in their team, the new Engineering Hub and the communication & smooth process as highlights of this year’s process.
However, there were areas to improve. Respondents lamented the reduction in people deliberately thinking about possible team moves, and called out the uncertainty over how team moves might work at other times of the year. We’ll look to address these issues.
We mentioned supporting team moves throughout the year, how might that work?
With the changes to reteaming this year, we had aimed to put the mechanisms in place to support team moves at other times of the year. Those changes might be in service of mid-year strategy and investment changes, or personal development opportunities, where in-year promotions or leavers in engineering teams are of interest to folks in other teams.
To support this aim, we’ll be using the new Engineering team opportunities board to share open role in our teams and, if the need arises, any new teams that Redgate decides to spin up mid-year. We also have the new Engineering Hub, which we will keep up to date with the latest goals, team roster, working approach, objectives, and progress throughout the year — so engineers will easily be able to find out more about a team they might be interested in.
We are also considering running a mid-year “transfer window” where we ask Engineers to share any speculative interest they have in other teams. For a two-week period we’ll be on the lookout for people sharing interest in moves for personal development and seeing which of those we can support immediately or arrange for the future.
Thank you! 💐
Finally, I’d like to thank all the Redgaters involved in reteaming during December 2024 and January 2025 for engaging with, shaping, and delivering the activity. It was a team effort: Engineering Managers handled change management, team leaders invested their time in their information pages, engineers gave their options some deep thought, folks interested in moves made requests backed with clear rationale, and everyone supported the process of kicking off the new year and welcome new teammates. Thank you, all!
This post was first published in Redgate’s engineering blog, Ingeniously Simple.
Leading Agile Teams 
Leave a comment