Support Stable Counterparts

1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Stable Counterparts

On this page

• Overview
• Expected outcomes of the Support Stable Counterpart (SSC) Initiative
• How do we align Support Team Members to the Product?
• Expectations from an SSC
  • Establish and maintain a relationship with your product group(s)
  • Be alert and engaged on what's happening with the group
  • Enable Support with periodic communication relevant to the group
  • Enable Product with periodic communication relevant to the group
  • Be available to support and mentor newly onboarded SSCs
  • Raise concerns with your manager if unable to set aside required time to be an SSC
• Expectations from Managers
• Expectations from the Product Teams
• How can I enroll and be a counterpart
• Non-group specific SSCs

Overview

As a result of our direct interactions with customers, the Support Team occupies a unique position in GitLab that gives us the opportunity to connect product managers with customer feedback, and influence changes. To take advantage of this opportunity, we've adopted a model that is known within GitLab as "Stable Counterparts." In brief, a "stable counterpart" is an assigned, permanent contact for a GitLab Team Member within another function in the company. See the Stable counterparts item on the Leadership page, and An ode to stable counterparts for more information.

Expected outcomes of the Support Stable Counterpart (SSC) Initiative

• SSCs act as a bridge between the wider Support team and the Product groups to share information both ways.
• SSCs become the voice of the customer in product forums, and can influence product decisions.
• SSCs are enabled to develop vertical subject matter expertise in certain product areas.
• Product teams have a simple way to understand and explore various customer use cases and gather feedback.

How do we align Support Team Members to the Product?

• Development of the product is broken down into sections, stages and groups; that page is the single source of truth about who is performing this role.
• Each group can have one or more individual contributor counterparts.
• Each section can have a Support manager counterpart.

Expectations from an SSC

Establish and maintain a relationship with your product group(s)

Just like us, the product teams are spread across the globe. Due to this, it might not always be possible to sync with your counterparts.

• If time zones permit, have an introductory coffee chat with your Product Manager.
  • Talk about your interest in the group, and why you chose to become an SSC in it. Ask about the team and their day-to-day.
  • Ask them about their expectations of the SSC. Manage them and align.
• If you are in non-overlapping time zones, do a handshake via Slack.
• Establish a regular cadence for communication with them.
  • Using a living Google document helps, especially for maintaining a regular async communication model. You can make use of this template for it.
• In the initial sync/async introduction,
  • Get yourself added to their team sync - you can read the agenda doc if you're unable to join the sync call!
  • Join their Slack channel if not done already.
• If the group you chose already has an SSC, schedule a coffee chat with them to learn more!

Be alert and engaged on what's happening with the group

• Subscribe to the pertinent trackers and labels to be aware of new issues in that group.
• Be especially aware of severity::1 and severity::2 issues in the product area, including workarounds.
• Be aware of the tickets raised by customers pertinent to their category, surfacing and advocating for them.
• Be aware of major changes related to the group in upcoming releases.
• Be aware of the priorities and challenges of the product group.
• Strive to become a subject matter expert in the use of the features they cover.

Enable Support with periodic communication relevant to the group

• A monthly communication cadence is recommended. Since your group might not have a lot of updates to share with Support every month, set a cadence that is appropriate for the situation.
• Share announcements through the SWIR and in relevant Support Slack channels.
• Group related updates and announcements can be:
  • New features added in an upcoming release
  • Bug fixes in an upcoming release
  • Issues likely to generate tickets
  • Major documentation changes
  • Discovered bugs and applicable workarounds
  • Any special processes or troubleshooting workflows that might pertain to the features in your group
• Catalyze training materials and sessions as needed.
• [Optional] Consider doing quarterly office hours to chat about your group and share your experiences as an SSC with newer team members.

Enable Product with periodic communication relevant to the group

• Share customer feedback from tickets with the Product team.
  • Loop them in to relevant issues, tickets and Slack threads.
• Be the customers' voice and an influencing agent on product related decisions and future roadmap.
• [Optional] Help with questions from non product groups in the Product team's Slack channels if possible.

Be available to support and mentor newly onboarded SSCs

• Being an SSC is a different experience based on group. However, you will have certain tried and tested best practices that will help newly onboarded SSCs. Consider sharing them with the other SSCs in the team.
  • Use the @gitlab-com/support/support-stable-counterparts GitLab group, and the @support-stable-counterparts Slack user group to share best practices with other SSCs, and to gather input and feedback on process changes, improvements and other discussions.
• Iterate on this page and other templates used in this initiative based on what works and what doesn't in the real world. Support Engineers looking to become SSCs will benefit from these.

Raise concerns with your manager if unable to set aside required time to be an SSC

• The success of this initiative depends heavily on the ability of the SSC to build and maintain a relationship with the Product team. You will need to dedicate time to it regularly.
• If you find yourself unable to do justice to the expectations, have a chat with your manager and let them help you with time management and prioritization.
• It is perfectly alright to step aside for a few weeks and get back into it again once you have the bandwidth to do so.

Expectations from Managers

• If you are managing a Support Engineer who is also an SSC, it should be a topic of conversation in your 1:1 with them at least once a month.
  • Enable them in prioritizing and setting aside time for this activity.
  • Work on resolving concerns if any.
• If a Support Engineer you manage is interested in becoming an SSC, point them to the following section on How can I enroll and be a counterpart?.
• If the SSC is going to be unavailable for a prolonged period of time, or, during an important event related to their group, act as their backfill.

Expectations from the Product Teams

• Please be aware of time zone constraints and flex to accommodate the SSC.
  • Introduce new SSCs to your team and add them to the relevant channels, documents and meetings.
  • Engage async via a doc or discuss other modes of communication with the SSC.
• Share all relevant updates with the SSC, either sync or async.
• Each SSC-PM relationship is going to be different, work on finding out what works best for you and them!
• Share feedback with Support on what is working and what isn't.
• Set and manage expectations to get the most out of this!

How can I enroll and be a counterpart

If you're interested in becoming a stable counterpart for a group,

• Discuss with your manager.
• Open an issue with the SSC Onboarding template in the Support Training project.
  • This is a very very short module that walks you through expectations and best practices, and will take less than half a day to complete!
• Once done, create an MR to add your name under 'Support' for the relevant team on data/stages.yml and add your name to the list on the source/includes/product/_categories-names.erb file, then assign to your manager.

Note: We encourage having more than 1 SSC for a group - so if the group you are interested in already has an SSC, don't let that deter your interest!

Non-group specific SSCs

A couple of roles are not product group specific, but involve all the same expections and responsibilities with some overlap of the Support Liaison role. Non-group specific counterparts typically also step in when the related group has questions where there is no SSC currently.