The next iteration of Support Pods is to focus on creating a flexible framework which any group of team members can use to set up self-organising interest-based groups to work on any set of problems people wish to take on. The working name for this iteration is Support FlexiPods. ## Benefits ### Leans into the benefits of focus What we learned from [Iteration 1](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3740) is that a Support Pod's main benefit is the increased productivity and visibility of work brought about by having a view focused on one topic area. Let's double down on this and allow a Support Pod to be created for any topic of interest which a group of Support team members are motivated to work on. ### Meets Support's operational needs Our product feature set and customer use-cases are growing large and complex enough that it makes sense to introduce some elements of specialisation, but not large enough that it makes sense to restructure our work and team around specialisation. FlexiPods introduce some form of specialisation now, while being... flexible enough to adapt to the current operational challenges that GitLab Support faces as we scale to meet GitLab's increasingly complex business and customer needs. ### Enhances cross-functional collaboration * Customer Support organises our work around customer geographies and timezones. * Sales & Customer Success organises their work around customer segments and portfolios. * Product & Development organises their work around DevOps Stage and Group. FlexiPods can serve as a structured translation layer through which Support can interface and collaborate with other departments and functions beyond having just a single Support Stable Counterpart. ## Illustrative scenarios To illustrate, here are three scenarios which illustrate how this might work in practice: <details> <summary>Scenario 1: Technical interest Support Pod</summary> > Support engineer Gary has a deep personal interest and knowledge in GitLab's Secure offerings, and has noticed that knowledge of this area is unevenly distributed throughout the team. He gets together with a couple of other support engineers who are interested and new to Secure, and starts a Support Pod focused on Secure tickets to facilitate collaboration and learning. Over time, other support engineers find their way into this Support Pod through the Support Pods directory, and knowledge grows throughout the team. </details> <details> <summary>Scenario 2: Escalated customer Support Pod</summary> > Acme Disaster Management Corp has had significant trouble with their GitLab installation, and different sysadmins have created multiple tickets reporting different problems. Support engineer Linda, who has been working one ticket, decides to take a look at the rest of Acme's tickets and realises that the support cases may actually share the same root cause. She creates a Support Pod focused on tickets from Acme, and invites a support engineer from each region to participate and guide troubleshooting around the clock. Linda also reaches out to Acme's TAM to explain the situation, and keeps Support Managers apprised. Due to Linda's initiative and coordination of efforts through the Support Pod, an escalation is averted. Once the crisis has passed, the Support Pod is disbanded. </details> <details> <summary>Scenario 3: Support readiness Support Pod</summary> > GitLab has just released an integrated Remote IDE feature as part of Omnibus GitLab. It quickly gains traction with customers, but faces many teething problems, causing a flood of support cases which support engineers are ill-equipped to handle. Support Director Ash wants to get ahead of the problem, and they create a Support Pod focused on training up support engineers, and quickly adapting existing Support forms and processes to help manage the volume of tickets. With input from support engineers working in the Support Pod, Ash works together with Support Operations to route and tag Remote IDE tickets. At the same time, Ash works together with the support engineers in the Support Pod to onboard at least two other support engineers per region every month. Soon, the Support team has the necessary processes and knowledge to handle Remote IDE tickets. The Support Pod is disbanded. </details> ## Success criteria As it is known that the primary benefit of Support Pods is its focus on specific topic areas, the success of FlexiPods _should not_ be measured in terms of improvements to KPIs such as FRT achievement or Time to Resolution. What we _should_ measure quantitatively is currently unknown. We should carefully observe the different types of value which different Support Pods bring, and better define this as we go along.