Working Groups

1. You are here:
2. Meet the GitLab team
3. Organizational Structure
4. Working Groups

On this page

• What's a Working Group?
  • CEO Handbook Learning Discussion on Working Groups
• Roles and Responsibilities
  • Required Roles
  • Optional Roles
• Guidelines
• Process
• Modifications to Process for Limited Access Communications
• Participating in a Working Group
• Active Working Groups (alphabetic order)
• Past Working Groups (alphabetic order)
• Top Cross-Functional Initiatives
  • Current Top Cross-Functional Initiatives
  • Managing, Adding and Removing Top Cross-Functional Initiatives
  • Cross-Functional Initiative DRIs
  • Information Access
• Retired Top Cross-Functional Initiatives

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 to the CEO, 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

Working Group Directly Responsible Individual

This is the person ultimately responsible for the success of the Working Group. Assembles the working group, identifies interdependencies, manages supporting individuals toward project success, and ensures that results and escalations are appropriately communicated. This person also plays the facilitator role. A facilitator is responsible for running meetings and supporting the operational efficiency and success of a working group.

• Makes sure that team objectives and success measurement is known and understood by team members and key stakeholders.
• Identifies interdependencies and risks to then ensure that team members are proactively aligning with others and prioritizing necessary risk mitigations.
• Clearly manages different project workstreams and proactively communicates expectations for specific working group team members. For example, if you know that an initiative will eventually involve customer communications, the Working Group DRI should ensure that the group has appropriate representation from the Customer Success Team and that the representative is clear on asks for both the team and the individual within the coming weeks and quarters.
• Assigns any actions, initiatives, or outstanding questions to a workstream DRI to investigate further. This ensures accountability and prevents overwhelming any single member or the Working Group DRI.
• Evaluates opportunities to work in a way that better reflects GitLab values. Examples:
  • Suggests more efficient ways to get to the same outcome
  • Considers how decisions or milestones can be unbundled, so we can work more iteratively
• Escalates when scope is changing, the project is at risk, or greatership engagement is required.
• Owns meeting agendas, so that they are organized to stay on topic. Follows up on goals from the previous meeting, and align back to the exit criteria in each meeting.
• After a long discussion about a topic, tries to summarize it and result in an action item - Determines if this topic should be pursued further, or if it changes the exit criteria. If it does, clearly flags to the DRI and other Working Group members.
• Creates a single source of truth for collaboration and coordination and is clear on communication expectations. 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 Sponsor

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

• 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
  • Clearly outline risks and interdependencies. Flag mitigations and ensure that interdependencies are know and being addressed as part of the plan
  • Ensure that responsibilities for all participants are clearly documented and understood
• 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.
  • Communicate outcomes using multi modal communication.
  • Notify widely of exit outcomes via channels such as the engineering week in review.
• 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:

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)

• API Vision
• Category Leadership
• Cross Functional Prioritization
• Demo & Test Data
• Engineering Internship
• Event Stream
• Expense Management
• FedRAMP Execution
• Frontend Observability
• GitLab.com Disaster Recovery
• GitLab.com SAAS Data Pipeline
• Revenue Globalization
• Issue Prioritization Framework
• Learning Experience
• Maintainership
• MLOps
• Modern Applications Go-To-Market
• Multi-Large
• Next Architecture Workflow
• Product Career Development Framework
• Rate Limit Architecture
• SOX PMO
• Talent Acquisition SSOT
• Token Management
• Webpack (Frontend build tooling)

Past Working Groups (alphabetic order)

• Architecture Kickoff
• China Service
• CI Queue Time Stabilization
• Commercial & Licensing
• Continuous Scanning
• Contributor Growth
• Database Scalability
• Development Metrics
• Dogfood Plan
• Ecommerce Motion
• Engineering Career Matrices
• Enterprise Market Leadership
• Experimentation
• Githost Migration
• GitLab.com Cost
• GitLab.com Revenue
• gitlab-ui (CSS and Components)
• GTM Product Analytics
• IACV - Delta ARR
• IC Gearing
• Improve Ops Quality
• Internal Feature Flag usage
• Isolation
• Learning Restructure
• Licensing and Transactions Improvements
• Log Aggregation
• Logging
• Merge Request Report Widgets
• Minorities in Tech (MIT) Mentoring Program
• Object Storage
• Pipeline Validation Service Operations
• Performance Indicators
• Product Analytics
• Product Development Flow
• Product Engagement Actions (FY21)
• Purchasing Reliability
• Real-Time
• Secure Offline Environment Working Group
• Self-Managed Scalability
• Sharding
• Simplify Groups & Projects
• Single Codebase
• Tiering
• Transient Bugs
• Upstream Diversity

Top Cross-Functional Initiatives

We identify annual top cross-functional initiatives that are key to GitLab's success in the fiscal year and beyond. While there are other important business initiatives and priorities that exist within functions or require engagement across the business, we elevate these initiatives to address cross-functional dependencies, align on goals, and ensure ongoing reporting and monitoring.

These projects are the most important cross-functional ones, not necessarily the most important projects and initiatives. Other projects may be of great importance throughout the business, for example meeting recruiting targets or category leadership, but these are workstreams led by individual functions and central to their key business responsibilities. When alignment or ongoing reporting is required for an initiative clearly owned by a single function, the responsible E-Group lead should ensure that Key Reviews, E-Group Weeklies, Group Conversations and other existing forums are used for updates.

Please note that a limited set of team members currently have access to the linked Epics. We are exploring ways to make more information available to all team members and the wider-community while keeping sensitive information contained to a smaller group.

Current Top Cross-Functional Initiatives

This is the list of our active Top Cross-Functional Initiatives.

Initiative	DRI / Sponsor	Description	Links
Usage Reporting	@jdbeaumont / @mmcb	Ensure customer product usage and utilization metrics are surfaced to the right teams at the right time to drive improvements in customer adoption and flag high potential user growth/tier-upgrade opportunities.	Operational Data Vision, Epic
Fulfillment Efficiency	@ofernandez2 / @sytses	Rollout new Quote Studio using new Zuora Orders API and Ramps functionality. Move CustomersDot to use Zuora Orders APIs. Align to Zuora Billing Account as a Customer Account. SSO / combine CDot and Gitlab user databases. Link ArrowSphere to CustomersDot.	FY23 Roadmap
FedRAMP	@JohnathanHunt / @akramer	Achieve FedRAMP Moderate Certification.	Working group page, Epic
Project Horse	@marin / @akramer	Internally confidential	Epic
SaaS Reliability	@sloyd / @akramer	Achieve enterprise grade security and reliability for our SaaS.	Epic
SaaS Free User Efficiency	@ipedowitz / @akramer	Adjust free program offerings to increase conversion rate and reduce sales and marketing cost while still giving back to students, startups, educational institutions, open source projects, GitLab contributors, and nonprofits.	Epic
User Engagement	@johncoghlan / @akramer	Create a developer brand through generating awareness among various communities that become advocates of GitLab and influence purchase decisions.	Epic
Project Matterhorn	@keithchung / @david	Limited access	Epic
First Order	@christinelee / @akramer	Grow our new logo and SAO counts across all segments to meet the business plan and set ourselves up for long-term growth.	Epic
AWS/GCP Partnerships	@nbadiey @mmcb	Expand GitLab's access to AWS/GCP LAM via cloud-first sales plays, new products, and lower friction buying.	Epic
E-Commerce	@ronell / @mmcb	Create world-class buyer experience and significant self-serve customer base / ARR.	Epic

Managing, Adding and Removing Top Cross-Functional Initiatives

We assess progress against each initiative in related Key Reviews and Group Conversations. We also have a dedicated quarterly meeting in which initiative DRIs, sponsors, E-Group, and other key participants review initiative health, risks, and blockers.

Top Cross-Functional Initiatives are not intended to last forever. Initiatives can be retired for a few reasons, including:

1. The team has met its exit criteria. There is agreement that the team has achieved its goals.
2. Work is not truly cross-functional. While of importance to all of GitLab, the initiative is at a point where it is best managed within a single function. The E-Group Sponsor will be responsible for ensuring ongoing awareness and progress.
3. Other initiatives take higher priority. While there may be additional work to be done, we maintain a limited set of Top Cross-Functional Initiatives. E-Group may choose to retire an initiative from the list if other initiatives are of higher importance to the success of the business.

Top Cross-Functional Initiatives are discussed in the annual planning process. In the Q3 E-Group Offsite, E-Group will review the list of current Top Cross-Functional Initiatives. It will also discuss priorities for the coming year. In Q4 of the fiscal year, E-Group will designate some initiatives for retirement. While some initiatives may remain on the list, their scope may be revisited as part of this process.

Any addition or retirement of Top Cross-Functional Initiatives should be shared with E-Group in advance of retirement. It is important that there is room for alignment and discussion in advance of removal. This can happen in a designated forum as part of the annual planning process or through a discussion topic in an E-Group Weekly. After the E-Group Sponsor and CEO have agreed to retire the initiative, and E-Group has had a forum for any feedback; the E-Group Sponsor is responsible for ensuring that the initiative is appropriately closed out and any internal and/or external communication is thoughtfully managed.

When an initiative is retired, it should be moved from the current initiative list to the retired initiative list.

Cross-Functional Initiative DRIs

Each of our top cross-functional initiatives has an Executive Sponsor and a directly responsible individual (DRI). DRIs are the folks ultimately held accountable for the success (or failure) of the project. They are the linchpins as these initiatives require deep cross-functional alignment and coordination. DRIs are also responsible for performance tracking and reporting. This includes providing updates in advance of relevant Key Reviews. Updates should map to the Executive Sponsor who is aligned with the initiative. For example, category leadership maps to Sales and Marketing as the Exec Sponsor is the CMO. The DRI is responsible for the following deliverables in advance of Key Reviews:

1. The initiative overview epic
2. Milestone issue status
3. Two initiative slides using the Key Review meeting template

Information Access

We are tracking in epics and issues in a separate namespace to comply with SAFE guidelines. If team members want access to a specific initiative, they should reach out to the appropriate DRI. Links to each initiative and other details are captured in the chart above.

Retired Top Cross-Functional Initiatives

This is a a list of top cross-functional initiatives that have been retired.

Initiative	DRI / Sponsor	Description	Links	Start / Year
Category Leadership	@melsmo / @akramer	Become the overall leader of The DevOps Platform through defining and owning the category. This is still important to GitLab, but it will be managed by the Marketing Team, not as a top cross-functional initiative	Working group page, Epic	FY23-Q1 - FY23-Q2
Cloud Licensing	@ofernandez2 / @david	Provide automated licensing functionality to customers to improve their experience while reducing the chances of sales and support escalations.	Epic	FY23-Q1 - FY23-Q3