Counterpart Arrangements - What does good look like?
Background
We have counterpart arrangements with the Development teams where we provide SRE expertise to deliver and support product features. This model exists because we have chosen to not embed SREs into the Development teams. Scalability and Delivery were the first teams to have BE and SRE experience in the same team, and this model has expanded to include Gitaly and the Database teams. However, all of these teams are in Infrastructure. I'm setting this out because changing the model of the Development teams is beyond the scope of the discussion I would like to have.
The other piece of information that is important is that some of the counterpart arrangements we have today exist because the Development team gave us their headcount in order to be able to have SRE support for their feature.
With that in mind, I'd like to discuss the counterpart arrangements set up and see what we can do to improve how it works.
Challenges with the existing model
- There are too many instances where we are involved too late and by the time the request reaches us, it has become urgent. We have to context switch to provide what is needed and we introduce delays to other important projects.
- Counterpart requests are not prioritized alongside other work required in the team.
- Requests are often unclear and it takes time to develop a plan, all while the urgency is high.
- We land up siloing engineers. One engineer becomes an expert in that product feature and we struggle when that person is unavailable.
- Because the requests are reactive, we get stuck in a cycle of not having time to make operational improvements for the features we need to support.
Despite these challenges, the SREs who act as counterparts do a great job of providing excellent support to these teams. Yet I can't help but feel they must go through periods of stress that we can alleviate with some changes.
What can we do about this?
We know why we want something about this to change. But I'm noticing that we are having trouble articulating what that something is. So let's try looking at this from the perspective of the goal - what does good look like for this process? What does objectively better look like? Is there anything we can measure to know we're doing well?
I'd also like us to consider this from the many perspectives of the stakeholders in this process. From the Development side and from our side, from the IC's to the EMs and Directors.
Once we have some idea about what we would like to achieve, we can then consider how we will get there. So let's start the conversation by focusing on what good looks like.
/cc @kwanyangu @swiskow