Add ASE PTO regional coverage pod information

Why is this change being made?

💡 Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

Please add the details saying why, not just what in this section. Example: We have discussed the topic in Slack - (copy of Slack conversation). The current process is not efficient, this MR makes the description of X more clear, and helps move Y forward.

@melroberts We experienced burnout from the inability to enjoy PTO, unclear coverage creating stress, micromanagement of every absence, and a lack of structured processes. These changes attempt to address these issues.

AI Disclosure: AI was utilized in the creation to a) look for gaps in the policy and b) "rubber ducking".

PROPOSED CHANGES:

AMER ASE PTO Coverage Policy

Overview

The 9 AMER ASEs are organized into 3 coverage groups of 3 engineers each. Each group covers for their members during PTO. When a group can't handle coverage (2+ people out, high workload), the fallback system activates and other ASEs volunteer.

Status: Pilot program
Start Date: 2025-11-15
First Review: 2025-12-15

The Problem

We experienced burnout from inability to enjoy PTO, unclear coverage creating stress, micromanagement of every absence, and lack of structured processes. This pilot addresses these issues.

How It Works

PTO Coordination

1 person out: Book in Workday, coordinate with your coverage group
2 people out: Book in Workday, post in #support-amer-ase for visibility
3+ people out: Do NOT book yet. Post in #support-amer-ase (tag manager) before booking. Manager evaluates if coverage is feasible.

Coverage Groups

Each group has 3 people including 1 group lead. Groups rotate membership twice yearly. See the handbook for current assignments.

When Your Group Can't Cover

Post a fallback request in #support-amer-ase. Other ASEs volunteer to take 1-2 accounts. If no volunteers within 48 hours (planned PTO) or 4 hours (emergency), manager assigns coverage.

Everyone contributes approximately 2-4 fallback weeks per year.

Customer Coverage Models

Non-Auto-Assigned (most customers): Global Support handles tickets, backup ASE reviews for priorities and maintains relationships.

Auto-Assigned Model (some customers): Backup ASE handles ALL cases directly. Higher workload.

Key Differences from Global Support

We use a count-based algorithm instead of percentage thresholds. With 9 people, 1 person = 11%, 2 = 22%, 3 = 33%. Counts are simpler.

We book PTO first for 1-2 people out, then coordinate coverage after. For 3+ people out, please check with Lissa before booking.

We manage accounts and relationships, not individual tickets. Coverage focuses on strategic oversight while Global Support will handle ticket volume for most customers.

What You Need to Do

1. Create customer playbooks in GitLab (one issue per account) with account info and coverage details
2. Update playbooks before PTO with current status and next steps
3. Check team calendar before requesting PTO
4. Follow the coordination algorithm above
5. Volunteer for fallback when you have capacity

Resources

• Slack: #support-amer-ase
• Calendar: AMER ASE Team PTO Calendar
• Detailed procedures: See AMER ASE PTO Handbook
• Customer playbooks: GitLab issues

This is a pilot. We'll iterate based on what works and what doesn't.

@klang -ASEs are piloting a new PTO coverage model. I am adding this information to the Handbook for consistency.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Add initial information about PTO regional coverage pilot.
• Update overview language

---