Working Groups

Like all groups at GitLab, a working group is an arrangement of people from different functions. Learn more!

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 fast. A working group disbands when the goal is achieved (defined by exit criteria) so that GitLab doesn’t accrue bureaucracy.

Working groups are for important work that needs to be done quickly, when asynchronous work would be too slow.

CEO Handbook Learning Discussion on Working Groups

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

Topics covered include:

What is a working group
When to start a working group
Difference between project managers and working groups.
- 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.
Lessons learned from previous working groups
Why and how working groups support cross-functional projects

Roles and Responsibilities

Required Roles

Working Group Directly Responsible Individual

This is the person ultimately responsible for the success of the Working Group, and also plays the facilitator role. A facilitator is responsible for running meetings and supporting the operational efficiency and success of a working group.

Please see the process below for details on the responsibilities of this role.

The E-Group member who is responsible for staying plugged into the project, supporting the Working Group DRI (if necessary), and supporting escalations (if required). This is the E-Group member most interested in the results or responsible for the outcome. It will usually be the E-Group Member who owns the function that the Working Group DRI belongs to. E-Group Sponsors should be kept in the loop–especially when there are changes to timeline/scope, interdependencies that require alignment, or input needed. They will usually attend Working Group Meetings.

The E-Group Sponsor is responsible for helping the Working Group DRI to obtain funding needed for Working Group success. This is important as the E-Group is the level at which budget dollars are owned.

The E-Group sponsor also plays a key role in being a bridge to the rest of E-Group. This person should help to flag when related topics or updates should be brought to E-Group as an update or ask.

Functional Lead

One or more people who represent 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

Member

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. A member may serve as a DRI for a specific workstream or activity.

Guidelines

An executive sponsor is required, in part, to prevent proliferation of working groups.
A person should not facilitate more than one concurrent working group.
Participation in some Working Groups requires a significant time commitment. Participants should be clear on their role and expectations for what they are expected to deliver. They should manage their time and capacity and quickly escalate if they feel unable to serve in or deliver in their role.
It is highly recommended that anyone in the working group with OKRs aligns them to the effort.

Process

Map out the Working Group

The first step is to carefully map out what type of activities are required for the Working Groups success. The DRI can get recommendations on who to involve, but they should first have a view of the jobs to be done.

Creating the Working Group

The DRI should identify key folks who will be members of the Working Group. They could do this in a few ways:

Reach out to the exec sponsor to help identify leads/contacts throughout the organization who could provide support
Reach out to functional leads from the stages identified as needing to provide support to this effort
Include the folks who the DRI has already been working with on this effort, and ask them if they’d like to continue or have someone they’d recommend taking over
- If cross functional data pulls/analysis will be required, please identify Data DRIs that can help. As an example, please see what was done for the Storage Limits Initiative
Solicit help on the respective stage’s/team’s Slack channel. The Features by Group page may provide some guidance

For example, if you know that this Working Group will eventually involve customer communications, you should ensure that the team has appropriate representation from the Customer Success department and that the representative is clear on the asks for both the team and the individual within the coming weeks and quarters.

Establishing team norms for the Working Group

The DRI should establish how the Working Group will work, including:

Frequency of meetings
Inclusivity of team members across the globe
Frequency of status updates for use in status tracker
Designating DRI for overall project management, including scheduling meetings and tracking project status
Create a Slack channel for collaboration. The Slack channel name should start with the #wg_ prefix.
Gather metrics that will tell you when the goal is met
Organize activities that should provide incremental progress
Ship iterations and track the metrics
Communicate the results

The Working Group should follow the GitLab norms for meetings including:

Have an agenda
Document everything
Save time at the end of the meeting to take action items
Turn action items into merge requests or issues

Working Groups should follow the guidance outlined in Building High Performing Teams.

Working Group meetings

The DRI should stand up meetings at the cadence appropriate for the Working Group, depending on the urgency/importance and timelines associated. The cadence of meetings should map to how quickly you are moving and the amount of synchronously touch points needed for alignment and decision making input.

For example, you may have a high priority project in which decisions have been signed off on and change is not anticipated. Folks are clear on their roles and are staying on top of their activities as tracked in issues and epics. You may not need to meet more than once every two weeks to ensure alignment. Alternatively, you may be part of a project in which new deliverables are being reviewed daily and fast decisions have to be made. In this instance, it is appropriate to meet more than once a week.

All meetings should have an agenda. Live Doc Meetings have Google Docs as the preferred tool for taking meeting notes in an agenda. Please use the GitLab Live Doc Meeting Agenda Template as a starting point. If there’s no agenda for an upcoming session, cancel the meeting.

Create a page in the handbook

Working Groups should have a page in the handbook in the current working-groups folder and added to the list of active working groups below. If you inherited an existing Working Group, make sure that the page is up-to-date. This ensures that other team members have a place to go if they are looking to learn about what you are working on. At GitLab, we’re public handbook first, but if your work is not public, please use the internal working groups folder to keep the content SAFE.

Items to cover on your handbook page should include:

Name of initiative
Overview: what is this and why are we doing it?
Desired business outcomes, including exit criteria
Clearly outline risks and interdependencies. Flag mitigations and ensure that interdependencies are known and being addressed as part of the plan.
Key milestones and their delivery timeline
Who is involved. This should include who the DRI and Exec Sponsor (if there is one) are. Ensure that responsibilities for all participants are clearly documented and understood.

When possible, we work handbook first and start with a Merge Request. Google Docs can be used for drafting a proposal in which multiple folks need to collaborate in real-time. It may also be something that you’d consider when material is limited access. Once the confidentiality concerns are addressed and real-time editing is less crucial, the content should be moved to a Merge Request and the Google Doc should be marked deprecated with a link to the Merge Request.

Create issues and epics

Use issues to lay out the work defined, including the work defined in the handbook page. Use labels to denote progress (blocked, in progress, not started) and also highlight phases of work. The issues should be clear on what needs to be done, who the DRIs are from impacted teams, and the outcome expected. This applies to already ongoing work and work which is being newly scoped. If the team decides through an issue to make changes or implement new ways of doing things, document the change in the handbook.

You may also want to use an issue board as an overview of progress.

As work is being fleshed out and sub-projects are identified, some issues should be promoted to epics to group other issues that are part of the same sub-project. It’s best practice to have an issue or sub-epic for each sub-project associated with the Working Group. Group sub-epics under one parent epic to track progress over time. As items are completed, close out the issues and epics and document progress in the handbook.

Like the handbook, issues and epics should be public by default. If an issue or epic contains material that needs to remain internal, they should be made confidential or be in a project which is private. If an issue or epic can remain public, but a comment needs to be added that is internal only, you can use internal notes to allow the issue to remain public while having a confidential conversation.

Working Groups should leverage issues and epics in the projects, groups, and sub-groups that drive maximum efficiency. For Working Groups operating within the GitLab.com group on GitLab company related projects, the following resources are available:

Per Working Group scoped labels
- WorkingGroup::<NewWorkingGroupName>
Working Group status labels for tracking status of issues and epics
- wg-status::Not Started
- wg-status::Ready
- wg-status::In Progress
- wg-status::Blocked
- wg-status::Complete
working-groups subgroup for organizing per Working Group issues, epics, and projects

Communicating status, updates, and changes

Communicate outcomes using multimodal communication. For example, you can use a primary epic to communicate current status and updates. The description of the epic should be kept up to date with the latest status, and a running log of updates should be left as comments to the epic. In the comment tag the respective E-Group sponsor (if applicable) as well as the relevant DRIs with @ mentions. Additionally, ping the link to the current status comment to the Slack channel created in establishing team norms @ mentioning the relevant folks.

Any material changes to the direction or plan for the Working Group should be put into the handbook page created, but general status and updates can be kept in the epic.

Changes to the timeline or schedule can have rippling downstream impacts. It is important to communicate these changes as early as possible to all relevant stakeholders. Shifting dates have the potential to negatively impact team members who may be tasked with communicating/guiding users/customers through these changes.

Trust Building

When a Working Group forms, it is important to build trust amongst the team members. This will help the Working Group function better, build credibility, and allow team members to be vulnerable with each other, if needed. Just as it’s important to do the work itself, it’s also important to take time for coffee-chats, activities, games, etc. that allow Working Group members to build a personal connection.

Disband the working group

Once the Working Group has served it’s intended purpose, it’s time to disband the Working Group.

Celebrate. Being able to close a working group is a thing to be celebrated!
Move the working group to the Past Working Groups section on this page.
Update the working group’s page with the close date and any relevant artifacts for prosperity.
Archive the slack channel.
Delete the recurring calendar meeting.

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:

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.
Communicate the results
- 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.
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.

If you are unable to attend the existing working group meeting due to time differences, you may approach the facilitator to arrange an alternative meeting.

Active Working Groups (alphabetic order)

Past Working Groups (alphabetic order)

What were Top Cross-Functional Initiatives?

Top Cross-Functional Initiatives were Working Groups that were key to GitLab’s success in the fiscal year and beyond. While there were other important business initiatives and priorities that existed within functions or required engagement across the business, we elevated these initiatives to address cross-functional dependencies, align on goals, and ensure ongoing reporting and monitoring.

We retired this concept in FY24-Q3, because we had layered these initiatives under Yearlies as sub-objectives. This list was duplicative and confusing to team members who were trying to manage these and other priorities. Top Cross-Functional Initiatives were moved to this page. The Top Cross-Functional Initiative concept was deprecated.

Last modified December 3, 2024: Added feature testing wg to list (73337bab)

View page source - Edit this page - please contribute.