Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Working Groups

On this page

What's a Working Group?

Like all groups at GitLab, a working group is an arrangement of people from different functions. What makes a working group unique is that it has defined roles and responsibilities, and is tasked with achieving a high-impact business goal. A working group disbands when the goal is achieved (defined by exit criteria) so that GitLab doesn't accrue bureaucracy.

CEO Handbook Learning Discussion on Working Groups

GitLab's CEO, Sid, and Chief of Staff, Stella, and the Learning & Development team discuss Working Groups in detail during a CEO handbook learning session.

Topics covered include:

  1. What is a working group
  2. When to start a working group
  3. Difference between project managers and working groups.
    1. Note: GitLab does not internally have project managers. Individual team members should have agency and accountability. We don't want someone who just tracks the status of work and makes updates. We want people to do this directly, and we want the DRI to own the process and outcome. This supports accountability. We sometimes have project managers when interacting with external organizations, because accountability is harder when working with external parties.
  4. Lessons learned from previous working groups
  5. Why and how working groups support cross-functional projects

Roles and Responsibilities

Required Roles


Assembles the working group, runs the meeting, assigns action items to Functional Leads, and communicates results

Executive Stakeholder

An Executive or Senior Leader interested in the results, or responsible for the outcome

Functional Lead

Someone who represents their entire function to the working group, regularly monitors the Working Group Slack Channel, creates issues for action items, serves as DRI for issues created, actively participates in meetings, volunteers for opportunities to further the Working Groups goals, regularly attends meetings either synchronously or asynchronously, shares information learned from the Working Group with their Functional teams, volunteers to take on action items , gathers feedback from Functional teams and brings that feedback back to the Working Group

Optional Roles


Any subject matter expert, attends meetings synchronously or asynchronously on a regular basis, regularly monitors the Working Group Slack Channel, shares information learned from the Working Group with their peers, and gathers feedback from their peers and brings that feedback back to the Working Group



Modifications to Process for Limited Access Communications

We make things public by default because transparency is one of our values. Some things can't be made public and are either internal to the company or have limited access even within the company. If something isn't on our Not Public list, we should make it available externally. If a working group is working on something on the Not Public List, working group team members should take precautions to limit access to information until it is determined that information can be shared more broadly. To highlight a few modifications to the process above:

  1. Preparation
    1. Determine an appropriate project name using limited access naming conventions.
    2. Create an overview page and add the link to Active Working Groups. You can share limited information, but capture key team members, including the facilitator, executive stakeholder, and functional lead.
    3. If working in the handbook, evaluate whether the page should be confidential or be housed in a new project with limited access. Consider working in the staging handbook. We use this when information may need to be iterated on or MR branches may need to be created in staging before it is made public. Outside of E-Group, temporary access may be granted on a project-specific basis.
    4. Maintain a list of working group members and other folks who are participating in or informed of the project. This list should be available to all participating team members. Folks should not be added to this list until it is confirmed that they understand what can be communicated.
    5. Ensure that each working group team member understands what can be communicated externally and internally.
    6. Have private Slack channels that include folks who are directly working on the project.
    7. Limit the agenda to a specific set of folks.
  2. Communicate the results
    1. Communicate results and progress to the direct working group or other key stakeholders to ensure that folks are aligned and have context on key happenings. Do not share sensitive information outside of private channels.
  3. Proactively share information if the project is no longer limited access
    1. Notify widely of progress or exit outcomes when information can be shared more broadly.
    2. Evaluate which artifacts and communication material can be made internally available or public.
      1. If you were working in the staging handbook, follow instructions to make a merge request against the public repo.
      2. Transition members to public Slack channels and archive private channels.
      3. Deprecate private agendas. Link this to a new agenda document.
      4. Consider making GitLab Groups and Projects public or avialable to a broader audience.

Participating in a Working Group

If you are interested in participating in an active working group, it is generally recommended that you first communicate with your manager and the facilitator and/or lead of the working group. After that, you can add yourself to the working group member list by creating a MR against the specific working group handbook page.

Active Working Groups (alphabetic order)

Past Working Groups (alphabetic order)

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license