Support Pods

Support Pods is a flexible framework which any group of team members can use to set up self-organizing interest-based groups to work on any set of problems people wish to take on.

GitLab’s product feature set and our customer’s use-cases are getting large and complex enough that it makes sense to introduce some elements of specialization, but our team size is not yet large enough that it makes sense to restructure our work and team around specialization.

Support Pods introduces some form of specialization now, while being flexible enough to adapt to the current operational challenges that the Support team faces as we scale to meet GitLab’s increasingly complex business and customer needs.

For information on how you can integrate Support Pods into your workflows, visit the Working with Support Pods workflow page.

Naming

Support Pods is the formal name of this initiative and should be referred to as such in formal written or verbal communication. This is to avoid confusion and ambiguity as there are many different uses of the word pod in the GitLab context.

Directory

Starting a Support Pod

Before starting

• Decide what activities your Support Pod will cover.
• Have at least three team members commit to participate in Support Pod activities.
• Determine the Support Pod leads.

Starting it up

1. Duplicate the Example Pod template page.
2. Rename your newly-created page to the name of your Support Pod.
3. Modify your Support Pod’s page to include content relevant to your Support Pod.
4. Add yourself (and other leads) to the ^[support-pods] section in the CODEOWNERS file.

After starting

1. Have a read of the Running a Support Pod section for guidelines and recommendations on running a Support Pod.
2. Announce the creation of your Support Pod in the Support Week In Review.

Running a Support Pod

Responsibilities of Support Pod leads

Each Support Pod should have at least one lead, who will be responsible for defining its purpose, and driving progress towards achieving that purpose.

Support Pod leads are different from Support Stable Counterparts (SSC). SSCs focus on working with engineering product groups; Support Pod leads focus on working with the support team. Often, it makes sense for an SSC to also serve as a lead for a corresponding pod, if one exists.

The Support Pod leads are responsible for:

• Recruiting team members who can and are willing to help with Support Pod activities.
• Organizing collaboration within the Support Pod, and with team members in the wider GitLab organization.
• Getting any resources or tools needed for Support Pod activities.
• Disbanding the Support Pod if its purpose has been met or is no longer needed.

As each Support Pod is self-organizing, leaders are free to decide how each Support Pod should make decisions. While doing so, please keep in mind the GitLab Values and the following principles:

• GitLab Handbook: Directly Responsible Individuals.
• Working on tickets Support workflow: Key Principles and Priorities & Impact.

Collaboration mediums

Here’s a list of different options you can use to collaborate with members of your Support Pod.

Zendesk

You may choose to create a personal view and share this configuration with Support Pod members so that you can see the same view of tickets. Unfortunately, the best way to do this now is through manual means, such as taking and sharing a screenshot.

An alternative approach of using Zendesk shared views is being explored in Support Team Meta Issue #6187.

GitLab.com issues

You may choose to create a label and issue board to filter and show all GitLab.com issues in the gitlab-org and gitlab-com groups relevant to your Support Pod.

Support Pods project

You may choose to store any relevant files or documentation in your Support Pods directory in the Support Pods project.

Google Doc

You may choose to create a Google Doc to store and collaborate in text before final transfer to a more permanent medium, such as a GitLab.com issue or Zendesk ticket. Make sure to set permissions such that everyone in GitLab can view or edit.

Slack

If you choose to use Slack to collaborate, consider using an existing channel:

• If customer-focused, an customer account internal channel (#a_XYZ-internal) may be appropriate.
• If GitLab product-focused, a stage (#s_), group (#g_) or feature channel (#f_) may be appropriate.

If creating a dedicated channel, prefix your channel name with #spt-pod_.

If you will be conducting pod specific pairing sessions in the channel, Pairify support can be added to the new channel by requesting it in #pairify-app.

Improving Support Pods by identifying and actioning on gaps

To address issues, it will be necessary to identify areas of concern within a Support Pod or distribution of expertise.

There are many ways to identify possible gaps or issues. Though the most important part of the process is to decide how to take action on them.

This is a non-exhaustive list that leads have completed with success:

1. SWOT analysis
   • Action: Create issues for “Threats” and “Weaknesses”. Assign DRIs to resolve.
2. Analysis of expertise. Example for Auth.
   • Action: May vary, such as invite a base number to join the Support Pod, or targeted number open traning modules.
3. Collect list of pain points from Support team members through a chosen method, such as a survey.
   • Action: Analyze the list for actionable points. Create issues for each, and assign DRIs to resolve.

Historical context

Iteration 1

Iteration 1 was rolled out in August 2021 in APAC and September 2021 globally. It was focused on enabling learning and collaboration. It was designed to complement the Working on Tickets workflow, so Support Pod views were worked on after all other Zendesk views.

Participants of the initial phase of Iteration 1 reported that there was not enough time to get to the Support Pod views due to heavy workload in other views. To alleviate this problem, we trialed prioritising Support Pod views ahead of other Zendesk views in February 2022.

Retrospective

What went well:

• Increases productivity when working on tickets and facilitates hands-on learning when training as Support Pod views are focused on one topic area.
• Easy to find and collaborate on tickets which might need a helping hand as tickets from all assignees and regions are visible

What didn’t go well:

• Confusion around ticket handling priorities as fitting Support Pods into ticket workflows resulted in guidance conflicting with global and regional work priorities.
• Conflicting guidance also caused some Pilot participants to feel like they were doing something bad by deviating from global workflows.

What can be improved:

• Identify how members of a Support Pod can collaborate with each other  —  most collaboration was with those working the ticket rather than within a Support Pod.
• Make Support Pod content more focused  — some views, e.g. Instance Management, contained a set of problem types that were too broad to facilitate focus.

Iteration 2

Iteration 2 was rolled out in March 2022, against the backdrop of Support Global Groups (SGGs) being rolled out as the primary to organize work on tickets. It was evolved into a flexible framework which any group of team members can use to set up self-organizing interest-based groups to work on any set of problems the group chooses to take on. This allowed it to co-exist and complement SGGs.

View page source - Edit this page - please contribute.