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.
