TMxG – Team Member Resource and Advocacy Group Guide

This page explains what Team Member Resource Groups (TMRGs) and Team Member Advocacy Groups (TMAGs) are at GitLab, how they work, and how you can get involved.

We use TMxG to refer to both TMRGs and TMAGs.

If you’re new to TMxGs, start here

You don’t need to be an expert in Diversity, Inclusion & Belonging or already a Team Member at GitLab to understand this section.

What are TMxGs?

• Team Member Resource Groups (TMRGs) are identity‑based communities organised around shared characteristics or life experiences (for example, race, ethnicity, gender, LGBTQ+, disability, caregiving, or global location).
• Team Member Advocacy Groups (TMAGs) are cause‑based communities organised around inclusion topics that benefit everyone (for example, mental health, generational understanding).

Both are:

• Voluntary, team member‑led communities.
• Supported by GitLab’s Diversity, Inclusion & Belonging (DIB) team and Executive Sponsors.
• Part of how we live our DIB value.

Who can join?

• Members: People who personally identify with the community or topic.
• Allies: Anyone who wants to learn, show up, and support the group’s mission.

Unless an event is clearly marked as “members‑only”, TMxG activities are open to both members and allies.

You can belong to more than one TMxG; many GitLab team members do.

How to get involved

As a current or future GitLab team member, you can:

• Join the relevant Slack channel (listed on this page and on each TMxG’s own page).
• Join the TMxG’s Google Group or follow their Loop site (for GitLab team members).
• Attend events listed on the GitLab team calendar or in TMxG announcements.
• Participate in async discussions and campaigns, not just live calls.
• If you’re interested in helping to lead or organise a TMxG, see TMxG Leadership Resources.

Finding TMxGs

TMxG Slack channels use consistent naming so they’re easier to find:

• Parent TMxGs: #group-name-tmrg / #group-name-tmag (for example, #women-tmrg)
• Pods: #pod-name-parent-tmrg (for example, #wsa-women-tmrg)

Current TMxGs

Ordered alphabetically to avoid the perception that any TMRG or TMAG is more important than any other.

Intersectionality and multiple identities

Many people live at the intersection of multiple identities and experiences (for example, Black and disabled; LGBTQ+ and a caregiver; a non‑US team member and a parent).

At GitLab:

• You are encouraged to join multiple TMxGs that reflect your lived experience and interests.
• TMxGs regularly collaborate on intersectional programming (for example, Disability & Neurodivergence × Mental Health, Gente × Black × Women).
• Joint events are designed so that both communities and allies can engage and learn together.

When TMxGs co‑host an event, it counts for each group’s impact tracking. Leaders can see more detail on the Definitions: What Counts? page.

Pods (sub‑communities within TMxGs)

As TMxGs grow, some develop more focused sub‑communities – for example, based on role/function or region. At GitLab, we call these sub‑communities pods.

What is a pod?

A pod is a sub‑community within a parent TMxG that:

• Focuses on a specific function or role (for example, women in a particular profession), or a specific region (for example, AMER members of a global TMxG).
• Uses the same colour branding and visual identity as the parent TMxG.
• Follows the same governance wrapper as the parent TMxG.

A pod is a pod — whether function‑based or region‑based. Same governance, same budget process, same reporting. Only the “slice” of the community is different.

Relationship to the parent TMxG

Pods:

• Do not replace the parent TMxG – pod members are still members of the parent group.
• Do not have a separate budget line – they collaborate with the parent TMxG leads on budget requests using the existing TMxG allocation.
• Report their activity through the parent TMxG (for example, in the shared activity tracker and quarterly reports).
• Use a consistent Slack naming convention: #pod-name-parent-tmrg (for example, #wsa-women-tmrg for a Women in Solutions Architecture pod within the Women TMxG).

For most GitLab team members, it is enough to know that pods are additional doors into the same community, not separate organisations. You are welcome to participate in both a pod and its parent TMxG.

Details of how pods are proposed and run are documented in the TMxG Leadership Resources and in the internal TMxG Leaders Resource Hub.

Benefits of TMxGs

TMxGs are a proven way to build cultural competency, improve retention, provide marketplace insights, and attract diverse talent. They give team members a way to find common interests, build connections, and advocate for change.

For GitLab, TMxGs help grow the business by strengthening our DIB brand, support GitLab values and business goals, foster communication between GitLab and its team members, and provide mentoring and professional development opportunities.

For team members, TMxGs introduce you to GitLab’s culture, build a sense of belonging, and offer opportunities to develop leadership skills, build relationships across the company, and raise awareness for underrepresented groups.

Members and allies

Members are active participants who identify with the community’s focus. Membership is open to full‑time and part‑time team members, interns, and contractors.

Allies support, empower, and stand up for another person or group. All TMxG activities are open to allies unless explicitly marked as members‑only. Allies are encouraged to listen, learn, and engage with an open mind, while respecting the boundaries of their role – they are not expected to have ready‑made answers or to act as trained counsellors.

How to propose a new TMxG

Most inclusion needs at GitLab can be met by joining existing TMxGs, creating pods within them, or running joint programming. New TMxGs should be rare and intentional, created when there is a clear, long‑term need that can’t be met in other ways.

1. Start with a conversation

Before writing anything down, talk with your DIB partner (or the DIB team via #diversity_inclusion_and_belonging) and leaders of any existing TMxGs adjacent to the community or topic. Together, you’ll explore whether the need could be met by expanding an existing TMxG, creating a pod, or running a series of intersectional events first.

2. Draft a short proposal

If DIB agrees a new TMxG is worth exploring, prepare a short written proposal (2–3 pages max) covering:

• Community and purpose – who the group is for and why it needs its own space.
• Initial leadership and structure – proposed leads and rough time commitment.
• Size and sustainability – approximate member base and evidence of interest.
• Programming vision – example activities for the first 2–3 quarters across the three pillars (Career Development, Community Engagement, Allyship).
• Partnership and risk – any known overlaps with existing TMxGs or external brands.

DIB can provide a template.

3. DIB and People Team review

DIB and the People Team will review for strategic fit, overlap or duplication, and sustainability. They may suggest starting with a pod or a time‑boxed pilot before granting full TMxG status.

4. Executive Sponsor and leadership alignment

If the proposal moves forward, DIB will work with you to identify a potential Executive Sponsor. Only after alignment on mission, fit, and expectations will the group be confirmed as a new TMxG.

5. Naming, channels, and launch

Work with DIB (and Brand, if needed) on a name and visual identity that is clear, inclusive, and does not conflict with external partners or brands. Create Slack channels following the naming conventions (#group-name-tmrg / #group-name-tmag), set up Google Groups using the same pattern, and plan a thoughtful launch tied to your early programming.

6. Review and adjust

New TMxGs will be reviewed with DIB after their first few quarters to ensure the structure is working, the workload is sustainable, and there is a clear ongoing role alongside existing TMxGs and pods. Adjustments – including renaming, merging, or restructuring into pods – are always possible.

Executive Sponsorship

Every GitLab‑recognised TMxG has an Executive Sponsor – an E‑Group, Functional Leader, or VP who provides strategic support, advocacy, and visibility. An Executive Sponsor does not have to be a member of the community but must have the capacity and commitment to act as an ally to the group.

Key sponsor commitments include a minimum of 1–2 hours per quarter, co‑creating an engagement plan with TMxG leads, participating in quarterly touchpoints, attending key events, and championing TMxG work in leadership forums.

Research consistently shows that Executive Sponsorship has a direct impact on business performance. It also drives team member belonging – and the gap between how sponsors and ERG leaders perceive that impact is something we actively work to close at GitLab.

For full details on how to work effectively with your Executive Sponsor – including how to structure asks, use data, and manage the relationship – see the Executive Sponsorship for TMxGs page.

TMxG leadership

TMxG leads are volunteer team members responsible for the strategic direction and day‑to‑day operations of their group. Selection criteria include at least 6 months’ tenure at GitLab, active membership in the TMxG, manager approval, and a minimum one‑year commitment.

For everything you need to lead a TMxG effectively – planning, events, budgets, impact tracking, and onboarding – see TMxG Leadership Resources.

View page source - Edit this page - please contribute.