Working with Support Pods

What is 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 they wish to take on.

It provides barebones structure and process intended to bring team members together to work on specific subjects within Zendesk tickets, GitLab.com issues, Slack and other mediums for collaboration.

The full Support Pods handbook and a list of active Support Pods can be found in the Support Pods project. The project is currently private to GitLab team members as some pages may contain sensitive information.

How do I get involved?

You can follow the instructions here to start or join a Support Pod

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.

Integrating Support Pods in day to day work

Support Pods are currently not integrated into our ticket handling workflows. This is intended to allow each Support Pod to determine their own approach to working with tickets and customer issues.

In general, each Support Pod’s approach to work should keep to the Key Principles and Priorities & Impact guidelines for working on tickets, and contribute to the team’s achievement of positive customer outcomes.

Each Support Pod may have specific recommendations on integrating its work into your day-to-day. These recommendations should be documented in the Support Pod’s README in the Support Pods project.

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 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 across SGGs. Example for Auth.
   • Action: May vary, such as invite a base number per SGG 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.