--- title: "An ode to stable counterparts" author: Suri Patel author_gitlab: suripatel author_twitter: gitlab categories: insights image_title: '/images/stablecounterparts.jpg' description: "Our workflow model streamlines decision making, cultivates trust, and promotes cross-functional collaboration." tags: workflow, inside GitLab, collaboration postType: content marketing --- _They said [this model](/handbook/leadership/#stable-counterparts) 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](/handbook/engineering/development/dev/create-source-code-be/#stable-counterparts), 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. <%= partial "includes/blog/content-newsletter-cta", locals: { variant: "b" } %> 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](https://docs.gitlab.com/ee/ci/), [security](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports), or [Kubernetes](https://docs.gitlab.com/ee/user/project/clusters/index.html), 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](/jobs) 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](/company/team/#d3arWatson), [Liam McAndrew](/company/team/#lmcandrew), [John Jeremiah](/company/team/#j_jeremiah), and [Tim Zallman](/company/team/#tpmtim) for sharing their experiences as stable counterparts._ ---- [Cover image](https://unsplash.com/photos/f81VZFRDPCc) by [Markus Spiske](https://unsplash.com/@markusspiske), licensed under [CC X](https://unsplash.com/license). {: .note}