Support Stable Counterparts

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

On this page

• 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
    • Examples of SSC activities
  • 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
• Feedback on the current initiative
• Support Customer Impact Dashboard
• Current SSC Vacancies
• How can I enroll and be a counterpart
• Non-group specific SSCs
• Product counterparts

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 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 the group you chose already has an SSC, schedule a coffee chat with the existing counterpart to learn more!
• [Section SSC] Schedule a coffee chat with the Support counterparts in the groups within the section.

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 aware of major issues (especially severity::1) in the product area, including workarounds.
• Be aware of the tickets raised by customers pertinent to the category, surfacing and advocating for them.
• Be aware of major changes related to the group in upcoming releases. At the section level, awareness of major changes will be 6+ months away instead.
• 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. At the section level, focus on becoming knowledgeable on feature usage and effect on customers.
• [Section SSC] Provide insight into relevant product KPIs and their potential impact on customers and Support.

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.
• [Section SSC] Ensure a regular cadence of communication with the group level SSCs to ensure alignment and balance of prioritization of issues.
• Share announcements through the SWIR and in relevant Support Slack channels.
  • Use the prefix [SSC Update: Group_Name: GitLab(Major).(Minor).(Patch)] for your updates in both SWIR and in relevant slack channels. Having consistency in this will help us measure the success and usefulness of this initiative.
• 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
  • Issues that may be good contribution opportunities
  • Major documentation changes
  • Discovered bugs and applicable workarounds
  • Any special processes or troubleshooting workflows that might pertain to the features in your group
  • Any changes in Support's workflows as a result of changes from your group
• If you have not had any updates to share in a long time, consider sending out a quick "Nothing major you have to watch out for with this release, all is well!" or "Here is an awesome new unfiltered video on this topic" etc.
• 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.
• [Optional] Be the DRI or ensure to find a DRI on any Support Readiness issue from your product group to ensure major changes are widely communicated.

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 in the Product team's Slack channels.

Examples of SSC activities

There's many different groups, and no one approach to being a SSC will be the perfect fit for all. Finding out how to best work with your group can take a while (one Senior Support Engineer said it took them more than two years to feel they really figured it out), and as everything at GitLab it is an iterative and – hopefully – transparent process. The expectations listed in the section above are a good starting point, but they are neither compulsory nor can they be complete.

Here's some things that other SSCs are doing that might serve as additional inspiration:

• Helping with UX research: As a Support Engineer, you're uniquely qualified to help defining good "real life" test scenarios and creating environments for them (example from Pipeline Authoring)
• Helping with Product design: When product designers plan upcoming features, you can look at those plans from the perspective of what kind of problems customers are likely to run into and how to avoid it (example for Authentication and Authorization)
• On a cadence, identify and tag or list relevant Support tickets you've worked on or seen (examples for Pipeline Authoring, Pipeline Execution)
• Contacting customers on behalf of the product group: Normally this is something the CMOC does, but in non-urgent cases you might be better equipped with domain-specific knowledge for a specific conversation with a customer (example from Pipeline Execution)
• Provide reviews of customer enablement campaigns: The Customer Success Programs Team creates campaigns to inform and educate our customers to help expand their usage of GitLab. As an SSC you're uniquely positioned as a Subject Matter Expert to review the communication that will go to customers with an eye for technical accuracy and ticket deflection. See SME Review Guidelines for more information.

Be available to support and mentor newly onboarded SSCs

• Being an SSC is a different experience based on the 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 #support-stable-counterparts Slack channel to share best practices with other SSCs, and to gather input and feedback on process changes, improvements and other discussions.
    • This Slack channel has both Slackbot's reminder app and Geekbot enabled to encourage channel participants to share periodic updates.
• 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!

If your group doesn't have an SSC assigned and you'd like to request one, please create an issue in the support-stable-counterpart project and share in #support_team-chat and #spt_stable-counterparts.

Feedback on the current initiative

During Q3-FY23 the SSC create and document process to ensure alignment of Support and Product issue prioritization and track results OKR focused on reaching out to Product and Engineering Managers, and their SSC/s to gather feedback. A common theme highlighted an interest from Product Managers having inputs from Support that may be able to provide insights for product planning and prioritization meetings with Product Managers.

SSCs that are regularly engaging with their product group are informing Support with knowledge they have picked up and the Product and Engineering Managers have built a steady relationship in these particular groups. There are still a few groups who are yet to build these foundational relationships, however, the feedback issues created an opportunity to encourage these discussions to start and a path forward for these groups to be carved out.

Support Customer Impact Dashboard

Based on feedback from SSCs regarding how to better inform product groups of the impact that issues have on customers, I have begun work on a Support-centric dashboard that will enable Support to identify trending issues and produce data to assist in prioritization. For more details, refer to Customer Support Linked Issues Dashboard.

Current SSC Vacancies

The tables below lists all groups and stages that currently do not have an SSC assigned. You can view a list of groups where a Product and/or Engineering Manager has reached out to support requesting an SSC in the support-stable-counterpart project.

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 a handbook merge request:
  • Add your name to the list on the /sites/handbook/source/includes/product/_categories-names.erb file.
  • Add your name under 'Support' for the relevant team on /data/stages.yml
  • Assign the MR 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 expectations 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.

Section	Group	Group Contact	Support Liaison	Frequency
UX	Tech Writing	Susan Tacker	Cynthia Ng & Mike Lockhart	weekly team meeting
UX	UX	Christie Lenneville	Cynthia Ng	weekly team meeting

Product counterparts

Section	Support Counterpart
Dev	Shaun McCann
Sec	TBD
Data Science	TBD
Growth	Shaun McCann
Fulfillment	John Lyttle
Enablement	TBD
SaaS Platforms	TBD

Group	Support Counterpart
Manage : Authentication and Authorization	Cynthia Ng
Manage : Import and Integrate	Olivier Némoz Saint-Dizier, Anton Smith
Manage : Foundations	TBD
Plan : Project Management	Ben Prescott
Plan : Product Planning	TBD
Plan : Optimize	Gabriel Yoachum
Create : Source Code	TBD
Create : Code Review	Ben King
Create : IDE	Brad Sevy
Verify : Pipeline Execution	Manuel Grabowski
Verify : Pipeline Authoring	Manuel Grabowski
Verify : Runner	Chris Day
Verify : Runner SaaS	Chris Day
Verify : Pipeline Security	Brie Carranza
Package : Package Registry	TBD
Package : Container Registry	TBD
Secure : Static Analysis	David Coy, Christopher Mutua
Secure : Dynamic Analysis	Kate Grechishkina
Secure : Composition Analysis	Katrin Leinweber
Secure : Vulnerability Research	Mario Mora
Anti-Abuse : Anti-Abuse	Michael Gibson
Deploy : Environments	Lewis Brown
Monitor : Respond	Cody West
Govern : Threat Insights	Gerardo Gutierrez
Govern : Compliance	TBD
Analytics : Analytics Instrumentation	TBD
Analytics : Product Analytics	TBD
Fulfillment : Purchase	Sokunrotanak Srey
Fulfillment : Provision	Keven Hughes
Fulfillment : Utilization	Shem Gyll
Fulfillment : Billing and Subscription Management	Firdaws Farukh
Growth : Acquisition	TBD
Growth : Activation	TBD
Systems : Distribution::Build	Diana Stanley, Nathan Black, Chris Kaburu
Systems : Distribution::Deploy	Diana Stanley, Nathan Black, Chris Kaburu
Systems : Gitaly::Cluster	Gerardo Gutierrez, David Wainaina
Systems : Gitaly::Git	Gerardo Gutierrez
Systems : Geo	Bo Carbonell, Łukasz Korbasiewicz
Data Stores : Application Performance	Gabriel Yoachum
Data Stores : Global Search	Vlad Stoianovici, Cleveland Bledsoe Jr
Data Stores : Database	Ben Prescott
Data Stores : Tenant Scale	Ben Prescott, Asmaa Hassan, Bruno Freitas
SaaS Platforms : GitLab Dedicated	TBD
SaaS Platforms : Switchboard	TBD
SaaS Platforms : US Public Sector Services	TBD