Reteaming FAQ and an offer to help
Questions we’re commonly asked about self-selection reteaming at Redgate and an offer to help you plan your own process
In January we completed our 3rd annual reteaming process at Redgate. I’ve written a couple of posts about how that went on this site and shared a tour through a key event in our approach — the team charter expo.
In response to that video I’ve had several people from different organizations make contact with me to ask about reteaming. They were curious about similar aspects of the process, so I thought I’d share my answers here, in case it’s useful for anyone else.
If you like videos for this kind of thing, I cover some of the questions in the recording below on a walk around my local countryside (while I self-consciously wrestle with a selfie stick):
But if you like you blog posts to actually have words and sentences and stuff, please read on:
Reteaming Frequently Asked Questions
Q: What prompted you to start deliberately reteaming at Redgate?
Firstly, some context: At Redgate we have called out a central principle of our approach to software development that “we believe the best way to make software is by engaging teams empowered with a clear purpose, freedom to act and a drive to learn”. We have that Guiding Star because we’ve seen teams that have those things succeed and be special places to work, but we were also inspired by Dan Pink’s book Drive: The surprising truth about what motivates us (read more about what we took from the book here).
Three years ago we decided we wanted to make a significant change to how we organize and direct our development teams. You can read more detail about that here, but to summarize the changes we were making; we wanted to change what some teams worked on, create one new team, explicitly explore some new product areas and group teams by life cycle stage. A complex change to undertake, but one that would correspondingly create many new personal development opportunities for our people to take on.
Around that time we’d been inspired by Heidi Helfand’s popular conference keynotes about “dynamic reteaming” and drawn to the idea of giving our people more freedom and influence over the work the do. After all, if we were really serious about that central principle of giving people autonomy, mastery and purpose — then surely when faced with such a change and the variety of work available across our product portfolio, we had to give people a say over which team they would like to be part of!?
Furthermore, we’d seen some drawbacks of having long-lived, very stable teams with fewer internal moves between groups. Teams became naturally siloed; common tasks were often duplicated, knowledge was tacit rather than explicit, team approaches were prone to ossification and experts became deeply entrenched in their teams, unable to move for fear of leaving a team unable to operate without them.
All that together lead to our first attempt at deliberate, self-selection reteaming. Fortunately, Redgate is a progressive and people-first organization who trusted my team and I to go for it!
Q: Why (on earth) do you do this every year?
Well, we refresh our portfolio and product strategies at the end of each year at Redgate, and that can prompt a change of mission for some teams or create entirely new areas of work where we need to build a team to undertake. So we follow-up that strategy process with reteaming to give our people an opportunity to get involved in the upcoming work they are most motivated by or interested in.
Worth noting that while we’ve always been open for people to move between teams at Redgate — but people seldom asked for one before we started deliberately reteaming. Making the process regular (if infrequent) occurrence has normalized team moves, helped reduce team silos and driven us to get better at forming new teams quickly.
Q: Do you end up with no one wanting to be on certain teams?
Prior to our first attempt at the process I was certainly concerned that some teams, perhaps those doing less glamourous work supporting legacy products or alike, would be unpopular destinations for people and so left with no team members following reteaming! But we have not found that to be the case. We’ve reteamed 3 times, and while we’ve had oversubscribed teams and undersubscribed teams, we’ve always been able to create a full roster of functional teams. That happened predominately because people’s preferences allowed for it naturally, with folks favoring a range of types of work — from early stage, lean product exploration to on-going maintenance and scaling of our most popular, established products. It seems you really do need different strokes for different folks.
We take care to highlight the mission of a team when providing people with information on what each team will be like. People don’t just join a team for the whizzy programming language or the market stage of the product, they care if they can have an impact on users’ lives and the success of the business. So while a product team might be dealing with gnarly code or an unfashionable tech stack, their product might be crucial to a cohort of users’ working lives. That speaks to the purpose that people need to be engaged and motivated in their work, as called out in Drive.
Q: Does everyone move teams during reteaming?
No. Many people have chosen not to move during each iteration of our reteaming process. In fact, each reteaming has seen ‘only’ around a third of our software development staff join new teams. The majority of people were happy in their current team, still committed to their mission, comfortable building skills on a familiar technology or simply did not have the appetite for a significant change at the moment. And that is absolutely fine.
Annual reteaming is not about disbanding all our stable teams and starting again from scratch. It’s about giving everyone the opportunity to move towards the work that best speaks to their aspirations and motivations. Those needs can often be served by staying put.
Q: What happens when you need to change things mid-year?
Despite having a predicable, regular cadence for reteaming, we are still able to create new teams or have people move between teams throughout the year. After all, we need to be a responsive, agile organization no matter the time of year — so we must be able to spin-up work at short notice to take advantage of an opportunity or tackle an emerging challenge. Similarly, there is no point making someone stay in a team until the next reteaming event if their work no longer motivates them or they can see an internal personal opportunity elsewhere.
When we change mid-year, we apply the same principles as we do during reteaming . We give people a strong influence over where they work, make new team opportunities visible & open and work with people to smoothly manage their transition into a new role.
Having said all that, it is fair to say that the vast majority of team changes do happen during our reteaming process (which happens in response to our annual product strategy review). So things do tend to be fairly stable during the rest of the year.
Can we help you try self-selection reteaming?
Giving people more autonomy over their work, the space to gain mastery and a motivating purpose is something we are really passionate about at Redgate. We see self-selection reteaming to be in direct service of that principle and we’d love to help other organizations try it too. So, if you have any other questions about reteaming, would like to know more about how to run a process (remote or physical) or how we build great teams at Redgate following reteaming, let us know in the comments, on twitter at @cj_smithy or by emailing chris.smith@red-gate.com.
This post was originally posted on Leading Agile Teams.
