Today we have a guest editorial from Kendra Little as Steve is away on his sabbatical.
Years ago, I worked on a fabulous team of eight database administrators. We supported more than a hundred developers who worked in an agile fashion. When I first joined the DBA team, we had a shared on-call rotation, but each DBA specialized in a certain area of the environment and regularly met with the development teams working on that area. DBA specializations rarely shifted.
Over time, this created significant stressors. Covering on-call for some areas became quite difficult in times of rapid change. It became impossible for someone to be out of the office for an extended period without delaying releases. And when we got to the point that we had to decide whether or not to escalate a critical issue to someone who was attending a funeral, it was clearly time for a change.
To gain flexibility, the DBA team decided to regularly rotate positions. Not everyone was thrilled. We each felt attached to the environment we supported: like a garden we had faithfully tended for years, it was hard to let it go! This made the transition a bit tough, especially at first.
Over time, we found that regularly rotating specializations had many benefits for our group. The most wonderful improvement was that it made it possible for team members to fully disconnect while they were off work, as other team members not only had deep technical familiarity with an area, but also our developers were used to partnering with more of us and everyone could adapt more easily.
Fast forward to today: now I work at Redgate. When I joined Redgate I was intrigued to learn that our Product Development teams run a self-selective reteaming process across the entire division. Reteaming just took place at Redgate in January 2020 for the second year in a row. Because it is at a larger scale than eight people, Redgate’s reteaming model gives people the option to have a say on whether it is time for a change or not (rather than only enforcing rotation).
Self-selecting reteaming is used at Redgate for multiple reasons, which I’ve shamelessly stolen from an internal post written by Redgate’s own Chris Smith to share with you. Reteaming….
- Realigns team size and purpose to reflect the larger organizational strategy for the year
- Gives engineers autonomy based on the principle that people will be most engaged and motivated if they have agency regarding what they work on
- Spreads knowledge, best practices, and innovation throughout teams, as people bring techniques, skills, and insights along with them from their prior work
- Enables personal development
- Reflects the recommendations of thought leaders, who champion this collaborative approach as an increasingly common characteristic of high-performing software development organizations.
Although change can be tough, I believe that we’ll increasingly find reteaming practices popping up in development and engineering teams everywhere – and in my experience, it’s a wonderful thing.
If you’d like to learn more about Redgate’s use of self-selecting reteaming, check out the “Dynamic Reteaming (with Heidi Helfand)” episode of the Ingeniously Simple Podcast.
