Skip to content
Snippets Groups Projects
Commit 2192b99c authored by Wei-Meng Lee's avatar Wei-Meng Lee Committed by Luminus Alabi
Browse files

Add Support Pods handbook page

parent a02b7fb5
No related branches found
No related tags found
1 merge request!7327Add Support Pods handbook page
......@@ -611,7 +611,7 @@ In GitLab Support, we have two mechanisms to organize support engineers as they
Global groups are organized by managers. Support Pods are engineer-lead. To join or start a Support Pod you can read more below.
*See the [Working with Support Pods page](/handbook/support/workflows/working-with-pods) and [Support Pods project](https://gitlab.com/gitlab-com/support/support-pods).*
*See the [Support Pods handbook page](/handbook/support/support-pods) and the [Working with Support Pods workflow page](/handbook/support/workflows/working-with-pods).*
### Improving our processes - 'Active Now' issue board
......
---
title: Support Pods
description: Flexible interest groups to focus on collaboration within Support and across functions
---
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](/handbook/support/workflows/working-with-pods).
## 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
| Support Pod | Slack | Leads |
|-------------|-------|-------|
| [AI](https://gitlab.com/gitlab-com/support/support-pods/-/blob/main/AI/README.md) | [#spt_pod_ai](https://gitlab.enterprise.slack.com/archives/C06KMDBJT5F) | <ul><li>{{< member-by-name "John Gaughan" >}}</li></ul> |
| [Advanced Search](Advanced%20Search/README.md) | [#spt_pod_advanced-search](https://gitlab.enterprise.slack.com/archives/C05M99TRDHV) | <ul><li>{{< member-by-name "Cleveland Bledsoe Jr" >}}</li></ul> |
| [Authentication and Authorization](Authentication%20and%20Authorization/README.md) | [#spt_pod_auth](https://gitlab.enterprise.slack.com/archives/C01NGKZQ2F2) | <ul><li>{{< member-by-name "Asmaa Hassan Ahmed Ali" >}}</li><li>{{< member-by-name "Gerardo Gutierrez" >}}</li><li>{{< member-by-name "Jio Castillo" >}}</li><li>{{< member-by-name "Alejandro Guerrero de Alba" >}}</li></ul> |
| [CI/CD](CI/CD/Readme.md) | [#spt_pod_cicd](https://gitlab.enterprise.slack.com/archives/C04DHQ91WJE) | <ul><li>{{< member-by-name "Manuel Grabowski" >}}</li></ul> |
| [Code Contributions](Code%20Contributions/README.md) | [#spt_pod_code-contributions](https://gitlab.enterprise.slack.com/archives/C05DUHAG3EY) | |
| [Database](Database/README.md) | [#spt_pod_database](https://gitlab.enterprise.slack.com/archives/C05K0R2830A) | <ul><li>{{< member-by-name "Ben Prescott" >}}</li></ul> |
| [Geo](Geo/README.md) | [#spt_pod_geo](https://app.slack.com/client/T02592416/C03D96JF4LD) | <ul><li>{{< member-by-name "Ronald van Zon" >}}</li><li>{{< member-by-name "Anton Smith" >}}</li></ul> |
| [GET](GET/README.md) | [#spt_pod_get](https://app.slack.com/client/T02592416/C05NL747NMD) | |
| [Git and Gitaly](Git%20and%20Gitaly/README.md) | [#spt_pod_git](https://gitlab.enterprise.slack.com/archives/C04D5FUADAM) | <ul><li>{{< member-by-name "Jessie Lee" >}}</li></ul> |
| [GitLab Dedicated](GitLab%20Dedicated/README.md) | [#spt_pod_dedicated](https://gitlab.enterprise.slack.com/archives/C058LM1RL3V) | <ul><li>{{< member-by-name "Brie Carranza" >}}</li><li>{{< member-by-name "Matthew Badeau" >}}</li><li>{{< member-by-name "Armin Hergenhan" >}}</li><li>{{< member-by-name "Wei-Meng Lee" >}}</li></ul> |
| [Import and Integrate](Import%20and%20Integrate/README.md) | [#spt_pod_import_and_integrate](https://gitlab.enterprise.slack.com/archives/C052K0Z1F8T) | <ul><li>{{< member-by-name "Anton Smith" >}}</li></ul> |
| [Kubernetes](Kubernetes/README.md) | [#spt_pod_kubernetes](https://gitlab.enterprise.slack.com/archives/C03U2N3180K/) | |
| [Performance and Reliability](Performance%20and%20Reliability) | [#spt_pod_performance](https://gitlab.enterprise.slack.com/archives/C04DP058MT2) | <ul><li>{{< member-by-name "Cody West" >}}</li></ul> |
| [Runner](Runner/README.md) | [#spt_pod_runner](https://gitlab.enterprise.slack.com/archives/C05MBS5RZ50) | <ul><li>{{< member-by-name "Justin Farmiloe" >}}</li><li>{{< member-by-name "Tony Marsh" >}}</li></ul> |
| [Secure](Secure/README.md) | [#spt_pod_secure](https://gitlab.enterprise.slack.com/archives/C03FV8G5LV7) | <ul><li>{{< member-by-name "Katrin Leinweber" >}}</li><li>{{< member-by-name "Brie Carranza" >}}</li></ul> |
| [Training](Training/README.md) | [#spt_pod_training](https://gitlab.enterprise.slack.com/archives/C06P0J75H6Y) | <ul><li>{{< member-by-name "Matthew Badeau" >}}</li><li>{{< member-by-name "John Gaughan" >}}</li></ul> |
| [Upgrade](Upgrade/README.md) | [#spt_pod_upgrade](https://gitlab.enterprise.slack.com/archives/C04MEHW7J4W) | |
## 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 who will be leading or co-leading the Support Pod.
### Starting it up
1. Duplicate the [Example Pod](example-pod.md) template page.
1. Rename your newly-created page to the name of your Support Pod.
1. Modify your Support Pod's page to include content relevant to your Support Pod.
### After starting
1. Have a read of the Running a Support Pod section for guidelines and recommendations on running a
Support Pod.
1. 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.
The Support Pod lead or co-leads are responsible for the following, and more:
- 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](/handbook/values/) and the
following principles:
- GitLab Handbook: [Directly Responsible Individuals](/handbook/people-group/directly-responsible-individuals/).
- Working on tickets Support workflow: [Key Principles](/handbook/support/workflows/working-on-tickets.html#key-principles)
and [Priorities & Impact](/handbook/support/workflows/working-on-tickets.html#priorities-and-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](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/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](https://gitlab.com/gitlab-com/support/support-pods).
#### 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 new channel, consider prefixing your channel with `#spt-pod_`.
If you will be conducting pod specific pairing sessions in the channel, [Pairify](/handbook/support/workflows/pairify/)
support can be added to the new channel by requesting this in `[#pairify-app](https://gitlab.enterprise.slack.com/archives/C06LG9NBSUX)`.
## 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](https://en.wikipedia.org/wiki/SWOT_analysis)
- Action: Create issues for "Threats" and "Weaknesses". Assign DRIs to resolve.
1. Analysis of expertise across SGGs. [Example for Auth](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/4920).
- Action: May vary, such as invite a base number per SGG to join the Support Pod, or targeted number open traning modules.
1. 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](https://gitlab.com/groups/gitlab-com/support/-/epics/192) was rolled out in August 2021
[in APAC](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3663) and September 2021
[globally](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3740). It was focused on
enabling learning and collaboration. It was designed to complement the
[Working on Tickets workflow](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/01bdd0b151efc881b13fdb9484669a6f76d0708a/sites/handbook/source/handbook/support/workflows/working-on-tickets.html.md),
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](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/96152)
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 &mdash; most collaboration
was with those working the ticket rather than within a Support Pod.
- Make Support Pod content more focused &mdash; some views, e.g. Instance Management, contained a
set of problem types that were too broad to facilitate focus.
### Iteration 2
[Iteration 2](https://gitlab.com/groups/gitlab-com/support/-/epics/191) was rolled out in March 2022,
against the backdrop of [Support Global Groups (SGGs)](https://gitlab.com/groups/gitlab-com/support/-/epics/210)
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.
---
title: Example Support Pod
description: A template for team members who want to create their own Support Pod.
---
## Purpose
To serve as a template for team members who want to create their own Support Pod.
## Scope
Having a clearly defined scope makes it easier for others to know what topics to bring to the pod.
Try using the existing lines within GitLab to define the scope of a Pod: GitLab product groups as
defined in the [DevOps stages](https://about.gitlab.com/handbook/product/categories/#devops-stages)
are the SSOT for where which [part/feature of the product](https://about.gitlab.com/handbook/product/categories/features/)
is at home.
## Current objectives
- Document how to start, run and shut down a Support Pod.
## Support Pod members
- Lead: {{< member-by-name "Wei-Meng Lee" >}}
- {{< member-by-name "Ronnie Alfaro" >}}
- {{< member-by-name "Tine Sørensen" >}}
## Collaboration channels
- Slack channel: #spt_pods – please follow the `#spt_pod_$name` naming scheme when creating a
dedicated channel for the pod. If `$name` has multiple words, use `-` to separate, e.g.
`#spt_pod_code-contributions`.
- Optionally create a Slack group as well. You'll need to create an [access request](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/new?issuable_template=slack_googlegroup_1Passwordgroupvault)
for IT to do so. As Slack group names can't be identical to existing channel names, please use
`@spt-pod_$name` for the group name (a `-` instead of `_` between `spt` and `pod`). If `$name` has
multiple words, use `-` to separate, e.g. `@spt-pod_code-contributions`.
- Epic - https://gitlab.com/groups/gitlab-com/support/-/epics/145
......@@ -10,25 +10,13 @@ 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](https://gitlab.com/gitlab-com/support/support-pods).
The project is currently private to GitLab team members as some pages may
contain [sensitive information](/handbook/legal/safe-framework/).
the [Support Pods handbook page](/handbook/support/support-pods).
## How do I get involved?
[You can follow the instructions here to start or join a Support Pod](https://gitlab.com/gitlab-com/support/support-pods/-/tree/main/_Handbook)
## 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.
You can follow the [instructions here](/handbook/support/support-pods#starting-a-support-pod) to
start or join a Support Pod.
## Integrating Support Pods in day to day work
......@@ -45,19 +33,3 @@ 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](https://gitlab.com/gitlab-com/support/support-pods).
## 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](https://en.wikipedia.org/wiki/SWOT_analysis)
- Action: Create issues for "Threats" and "Weaknesses". Assign DRIs to resolve.
1. Analysis of expertise across SGGs. [Example for Auth](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/4920).
- Action: May vary, such as invite a base number per SGG to join the Support Pod, or targeted number open traning modules.
1. 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.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment