Support Stable Counterparts - retrospect, recollect and renew
6 months or so ago we rolled out [Support Stable Counterparts](https://about.gitlab.com/handbook/support/#support-stable-counterparts) with the vision of having a 2-way door between product and support.
We had an initial set of meetings for counterparts, but until now we've let things take their own course.
I think there's been a lot of different experiences out there, some good, some confusing and some non-existent. I think it's time to revisit this and make sure we're filling a need and that we're clarifying things that are unclear.
From conversations I've had:
- Expectations surrounding the role aren't clear on the support side
- PMs don't always know what to do with the role: some see it as "free labor", others don't see the need, and others are somewhere in between
@sahbabou has been coordinating some meetings with Support and PMs to gather feedback as we figure out what more we need to do make this role more useful on either end. This issue is to:
- track that work
- provide a venue for feedback about the support stable counterparts role
#### Definitions of Done
This issue can be closed when:
- [ ] Feedback about the first iteration of the Support Stable Counterpart has been received received from each SSC
- [ ] Factors that contribute into measuring success in the role have been identified
- [ ] MR to update the Support Stable Counterpart section of the Handbook has is merged
#### Past Work
Past issues:
- https://gitlab.com/gitlab-com/support/support-team-meta/issues/1607
- https://gitlab.com/gitlab-com/support/support-team-meta/issues/1602
- https://gitlab.com/gitlab-com/support/support-team-meta/issues/1533
#### Notes from SSC calls:
- https://docs.google.com/document/d/1xqotMhGPU-qzOcW620_5eBPBuMF2GF7jUPBDksbV7m0/edit?usp=sharing
- https://docs.google.com/document/d/13u8dcUkpHR5S6uH2f2uiZSVzhobY8HG1U7fVIZXYN_s/edit
issue