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.
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:
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.
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.
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.
#wg_
prefix) that is public to the companyWe 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.
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 |
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:
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.