on March 13, 2020
Note: This post is based on an editorial I originally published over at SQL Server Central
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. 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 re-teaming process across the entire division. Re-teaming 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 re-teaming 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.
Re-teaming encourages good documentation habits
This week I realized something obvious: if you’re a developer who has been working on a productivity tool like SQL Prompt and you move to working on a tool related to version control and automation, there are certain things you wouldn’t necessarily know about your customers. For example, most customers in financial services and healthcare can’t or won’t use SQL Authentication. There are many things like this.
However, this isn’t a blocker to re-teaming. Instead, realizing this helped me understand that I can help improve our customer profiles to make these types of requirements and preferences more clear to everyone.
Reteaming helps surface “tribal knowledge” and help make it clearer for everyone.
Although change can be tough, I believe that we’ll increasingly find reteaming practices popping up in engineering teams everywhere
And in my experience, it’s a good 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.