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)
• 12 Cross-Functional Initiatives
  • Cross-Functional Initiative DRIs
  • Information Access

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
• Architecture Kickoff
• Category Leadership
• Continuous Scanning
• Contribution Efficiency
• Database Scalability
• Demo & Test Data
• Ecommerce Motion
• Event Stream
• Expense Management
• FedRAMP Execution
• Frontend Observability
• GitLab.com Disaster Recovery
• Issue Prioritization Framework
• Learning Experience
• Maintainership
• Merge Request Report Widgets
• MLOps
• Multi-Large
• Next Prioritization
• Object Storage
• Pipeline Validation Service Operations
• Product Career Development Framework
• Purchasing Reliability
• Rate Limit Architecture
• SOX PMO
• Talent Acquisition SSOT
• Webpack (Frontend build tooling)

Past Working Groups (alphabetic order)

• China Service
• CI Queue Time Stabilization
• Commercial & Licensing
• Development Metrics
• Dogfood Plan
• Engineering Career Matrices
• 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
• Minorities in Tech (MIT) Mentoring Program
• Performance Indicators
• Product Analytics
• Product Development Flow
• Product Engagement Actions (FY21)
• Real-Time
• Secure Offline Environment Working Group
• Self-Managed Scalability
• Sharding
• Simplify Groups & Projects
• Single Codebase
• Tiering
• Transient Bugs
• Upstream Diversity

12 Cross-Functional Initiatives

In FY22-Q4, we identified 12 top cross-functional initiatives that are key to GitLab's success in FY23 and beyond. While there are other important business initiatives and priorities that exist within functions or require engagement across the business, we elevated 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.

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.

Initiative	DRI / Sponsor	Description	Links
Usage Data	@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
Cloud Licensing	@ofernandez2 / @sytses	Provide automated licensing functionality to customers to improve their experience while reducing the chances of sales and support escalations.	Epic
FedRAMP	@JohnathanHunt / @edjdev	Achieve FedRAMP Moderate Certification.	Working group page, Epic
Project Horse	@marin / @edjdev	Internally confidential	Epic
SaaS Reliability	@sloyd / @edjdev	Achieve enterprise grade security and reliability for our SaaS.	Epic
SaaS Free User Efficiency	@kencjohnston / @ashleykramer	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 / @ashleykramer	Create a developer brand through generating awareness among various communities that become advocates of GitLab and influence purchase decisions.	Epic
Project Matterhorn	@keithchung / @sytses	Limited access	Epic
First Order	@christinelee / @ashleykramer	Grow our new logo and SAO counts across all segments to meet the business plan and set ourselves up for long-term growth.	Epic
Category Leadership	@melsmo / @ashleykramer	Become the overall leader of The DevOps Platform through defining and owning the category.	Working group page, 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

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 are responsible for the following deliverables in advance of Key Reviews:

1. The iniaitive 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.