Stable counterparts are an integral aspect of GitLab's leadership strategy by facilitating cross-functional connections in the hope that working with the same people would increase the speed of communication, build trust, and encourage iteration.
As we work towards maturing as a SRE organization, we must engage with Development teams in order to successfully onboard and support services in pursuit of our integrity and availability objectives for GitLab.com. Stable counterparts provide an existing, widely-used framework within GitLab to foster this engagement.
While we use versioning in this document, this is done to provide a sense of our first attempt at implementing stable counterparts and what this new iteration entails. We wont' be using them going forward.
In late 2018, early 2019, we added stable counterparts in Infrastructure. This first iteration was reflected in SRE titles, but, realistically, it yielded no palpable results. We believe this was due to the following issues:
By the end of 2019, we abandoned the stable counterpart model.
As we enter 2020, in order to achieve our integrity and availability goals, we must mature as a SRE organization, and one of the first steps is to define and foster our SRE engagement model, adapting it to our unique context at GitLab. Said context includes, for instance, GitLab as a monolith, which prevents a clear-cut service approach. Still, we need to find a way to start carving a path for proper SRE support for the product beyond our current practices. Additionally, as the company continues to grow, we must work to streamline information distribution, which implies better filtering: it is not only unfeasible but highly innefficient for managers to be the only conduits for information exchange netween Development and Infrastructure.
This new iteration will again be driven organizationally, outlining the logistics and outcomes involved.
A separate blueprint will flesh out our long view on the SRE engagement model as it applies to GitLab.