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.
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:
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.
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.
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.
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.
The DRI should identify key folks who will be members of the Working Group. They could do this in a few ways:
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.
The DRI should establish how the Working Group will work, including:
#wg_ prefix.The Working Group should follow the GitLab norms for meetings including:
Working Groups should follow the guidance outlined in Building High Performing Teams.
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.
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 handbook to keep the content SAFE.
Items to cover on your handbook page should include:
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.
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.
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.
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.
Once the Working Group has served it's intended purpose, it's time to disband the Working Group.
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:
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.
Please see the handbook page on Top Cross-Functional Initiatives