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.
Roles and Responsibilities
Required Roles
Facilitator
Assembles the working group, runs the meeting, assigns action items to Functional Leads, and communicates results
Meeting agendas should be organized to stay on topic. Follow up on goals from the previous meeting, and align back to the exit criteria in each meeting.
After a long discussion about a topic, try to summarize it and result in an action item - Determine if this topic should be pursued further, or if it changes the exit criteria.
Assign any actions, initiatives, or outstanding questions to a DRI to investigate further. This ensures accountability and prevents overwhelming any single member.
Consider using an Issue Board to track working group tasks by using the ~"WorkingGroup::" scoped label on each issue. This can be done separately from any other development related issues that the working group needs to track.
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
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
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
Generally, a person should not be a part of more than two concurrent working groups in any role
It is highly recommended that anyone in the working group with OKRs aligns them to the effort
Process
Preparation
Create a working group page
Assemble a team from required functions
Share in appropriate Slack channel(s) to encourage a diverse group of participants
Create an agenda doc public to the company
Create a Slack channel (with #wg_ prefix) that is public to the company
Schedule a recurring Zoom meeting
Define a goal and exit criteria
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
Consider regular updates to the #whats-happening-at-gitlab slack channel as progress is made towards goal.
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
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.
