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:
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
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
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:
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.
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.
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.
Ensure that each working group team member understands what can be communicated externally and internally.
Have private Slack channels that include folks who are directly working on the project.
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
Notify widely of progress or exit outcomes when information can be shared more broadly.
Evaluate which artifacts and communication material can be made internally available or public.
If you were working in the staging handbook, follow instructions to make a merge request against the public repo.
Transition members to public Slack channels and archive private channels.
Deprecate private agendas. Link this to a new agenda document.
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.
