They said this model would help us thrive.
To foster trust, familiarity, and drive,
We would work side-by-side, knitting our workflows
And supporting one another in our highs and lows.
Before we embarked on our journey, I fretted and fussed.
With a furrowed brow, I felt a careful trust
In my leadership who often discussed
The need to readjust lest we combust.
We shipped and scaled and detailed
Our results.
Seamlessly soaring towards Two and Twenty,
Our managers said, “In their progress, that
team exults.”
We collaborate, update, and accelerate with flair.
And now I must declare:
I have drawn the ace of hearts
With my team of stable counterparts!
At GitLab, we adopted a stable counterparts model to facilitate cross-functional connections in the hope that working with the same people would increase the speed of communication, build trust, and encourage iteration. In a stable counterparts model, every team works with the same team members, including frontend engineers, UX designers, and test automation engineers, for each release, creating a smaller team within GitLab.
The benefits of stable counterparts
The ability to build long-term relationships is the foundational benefit of having stable counterparts. Repeated interactions helps us understand personal workflows and communication styles, so we know how to most effectively work with our counterparts. Knowing how to best communicate with someone is a great benefit when working in high pressure situations or resolving conflict. Consistent collaboration means faster results and more efficient processes.
In addition to building long-term relationships, we’ve noticed a few other interesting benefits to having stable counterparts.
- Enabling a faster workflow: There are some product areas that are easy to understand because every team member engages with them, but there are some that are challenging, such as CI, security, or Kubernetes, that require domain knowledge that can be harder for a team member to quickly fathom without a certain amount of pre-knowledge. When a stable counterpart has developed deeper understanding in complex areas, others know who to quickly consult when confronted with a specific technical challenge, an insight that drives velocity since team members are no longer blocked trying to determine who can offer assistance.
- Promoting long-term brainstorming: In traditional workflow models, product managers often have individual meetings with engineering managers, UX designers, and frontend managers in which brainstorming through ideas and talking about long-term goals happens in silos. With stable counterparts, discussion benefits from cross-functional perspective, enhancing ideas, and igniting creativity, which can take place over several milestones.
- Increasing familiarity and comfort with problems: Working with a rotating set of team members can result in a lack of comprehensive historical knowledge on an issue, causing delays while team members digest information and become acquainted with the state of a solution. By working with the same people over several releases, we’re able to provide context early and implement learnings to solve problems in the right way.
Let’s talk about workflow impact
Working with stable counterparts has helped the team develop a faster and more iterative workflow. We’re more focused in that we can pick up on discussions and items that we tinkered with in previous releases. We now approach problems with a deeper understanding, since we have long-term insight into why changes are important. Taking context from release to release and retaining that knowledge ensures that we develop thoughtful solutions, especially since we feel a higher sense of ownership of projects because we’ve been involved throughout every stage.
This model has also resulted in better dependency management. We spend a lot of time doing upfront investment into project planning and prioritization, so teams have visibility into collaboration with backend and frontend. This makes it easier to see whether we need more backend or frontend resources in certain areas and to allocate engineers as needed.
Sounds great, but what are the drawbacks?
This model could lead to engineers feeling like they’re feature factories, so leadership must actively work to keep their team on an edge so that there’s a healthy balance between product features and other tasks that are more complex or exciting.
When working with stable counterparts, there’s a potential for conflict and personality issues. If personal communication styles or workflows don’t align, interactions can become tense and handoffs can be fraught with friction. When pairing stable counterparts, leadership should consider personalities, communication styles, and workflows to ensure that a team, at baseline, can work well together.
Working with the same people for too long means that we’re not exposed to a broader audience and may not have fresh ideas come into conversations. It’s possible that teams become comfortable with the way things are and ideas are no longer questioned. We haven’t encountered this problem at GitLab yet, since we’re growing so quickly that every team frequently has a change or new addition, which is accompanied by a variety of new questions and unique feedback. For teams that don’t have as much growth, it can be useful to invite other team members to provide perspective and question long-held beliefs.
Advice for other teams
If your team is interested in adopting a similar model, we suggest starting small and breaking teams into smaller components. For teams that are unaccustomed to an interdisciplinary model with agile teams, it can be a difficult adjustment, so it’s important that teams are structured around either a specific initiative or area of the product. To determine whether this is a model that could benefit your organization, consider selecting a problem and pairing the same 4-5 team members, including a product manager, a UX designer, and a few engineers, for several releases until the problem is solved. Working together for several releases helps team members nurture a strong, stable relationship, so it’s important that they’re given enough time to learn about and from each other.
Although stable counterparts has worked well for GitLab’s workflow, it’s important to be sure that this is the model that fits your company’s needs. Developing a workflow depends on strategy, targets, and the maturity level of an organization. These are all variables that need to be considered when building or changing a process. This setup wouldn’t have worked for GitLab 12 months ago, but it works now, so continue to experiment and examine options as your team and organization develop. Whether you pursue a stable counterparts model or some other setup, remember to select an approach that complements your organization and the product you’re building.
The writer is grateful to Jeremy Watson, Liam McAndrew, John Jeremiah, and Tim Zallman for sharing their experiences as stable counterparts.
