Office of the CEO

Office of the CEO Overview

GitLab is a functionally organized company in which functions are as mutually exclusive as possible to be efficient. Without a COO or central operating department reporting into the CEO, the CEO gets leverage through an Office of the CEO (OCEO for short) led by the Chief of Staff (CoS) to the CEO. While the Chief of Staff to the CEO is not a part of GitLab’s executive team, this senior person reports directly to the CEO and manages a team that supports the CEO and/or cross-functional projects of importance to GitLab.

Team Mission

Help the CEO be more effective and lead select cross-functional initiatives of importance to GitLab.

Team Composition

The Office to the CEO consists of:

1. The Chief of Staff to the CEO: the person responsible for running this group and supporting the success of the CEO.
2. Strategy and Operations team members: internal consultants and doers who support priority cross-functional projects within GitLab. Roles vary based on business needs, but these folks can be specialists (for example, focused on China or technology) or generalists.

When there are gaps, the Office may expand to include additional roles and responsibilities. For example, at times this Office has included our TeamOps initiative, internal communications, and handbook maintenance. As GitLab is a functionally organized company, the goal in most cases is to own an area until another function is prepared to own and support it.

The size of the team and which positions are present have varied over time depending on CEO priorities and required resources. For a list of current OCEO team members, please refer to the company team page.

Kinds of projects Strategy and Operations team members work on

Given the cross-functional nature of the company goals and given these projects are important to the CEO, the Strategy and Operators team members are often involved in these initiatives.

Project Criteria

The Chief of Staff to the CEO and their team may work on projects that fit any combination of the following:

1. projects which build or improve organizational design, infrastructure, and operations
2. cross-functional projects that need ownership until a maintainer or exit criteria is identified
3. projects that are so broad that they can’t live within a function but are too much work for the CEO or Chief of Staff to the CEO
4. projects that are important to the CEO

This is not an exhaustive list of the types of work the Office of the CEO might do.

Many Functional

GitLab is a functional organization, which means the people are organized by function. When a cross-functional project arises between multiple different Departments, Office of the CEO team members may be included to help with the planning and execution. In many cases, a member of the Office of the CEO will be the directly responsible individual (DRI) for the project. Whether it’s a product feature proposal, a new initiative roll-out, or questions from the board, the Office of the CEO is the group that can be trusted to get things done, get them done quickly, and get them done right.

Examples of a cross-functional project:

• Helping shepherd KPI and/or OKR progress
• Helping to launch a foreign entity
• Supporting pricing and packaging change initiatives
• Efforts to increase customer use case adoption
• Providing guidance around how to use GitLab’s internal handbook

Under-resourced

Projects come up that are both important and under-resourced. The Strategy and Operations team members within the Office of the CEO should be known for its ability to become 80% effective on any subject quickly. They are generalists at their core and, while they bring special skills to the table, they are meant to be able to address important problems as they come up. A member of the Office of the CEO might help source candidates for a strategic hire, fix grammatical errors in the handbook, and build a financial model all in the same day based on what is important or top of mind for the CEO at a given point. The team helps with work that other teams may not have the bandwidth to do but is important to the organization and/or the CEO.

Examples of an under-resourced project:

• Creating materials for a keynote the CEO will deliver in a rushed timeline
• Supporting planning for a global conference
• Supporting launch of a new SKU

No clear leader

There may be projects with no clear leader for a myriad of reasons, including that we’re still hiring the point person or the lead is on leave. Because of the team’s ability to come up to speed quickly, they may be tasked with something totally out of their domain with the expectation that they bring their leadership experience to the table, will do the work to make good decisions, and will lean on team members who are subject-matter experts.

For example, there has historically been no DRI for the handbook or related content sites. As it became clear that this was a GitLab priority, but no function planned to prioritize this within the coming year, the Office of the CEO stepped in to take on handbook ownership until an owner could be identified.

Examples of projects with no clear leader:

• Managing our ongoing relationship with JiHu in China
• Stepping in to fill a senior level role in another function in a temporary capacity

Broad

Some projects or initiatives are very broad and cross-functional and make sense to belong to the CEO but would be inefficient uses of the CEO’s time if fully owned by the CEO. The Office of the CEO is the shepherd for these sorts of projects and collaborates with all team members at GitLab to achieve success on such initiatives.

Examples of broad projects:

• E-group offsite prep
• Board meeting prep
• OKR shepherding
• Planning activities on behalf of the CEO

Important to the CEO

The CEO will have other projects that come up that they will task the Office of the CEO with, such as following up on something or carrying on a conversation on their behalf.

Examples of tasks or initiatives that are important to the CEO:

• Handbook MRs
• Values updates
• Preparing for calls
• Special projects. These have included:
  • Operationalizing charitable donations
  • Supporting updates to GitLab’s expense policy
  • Quantifying the value of transparency
  • Auditing training resources and creating an accessible source of truth
  • Calculating GitLab’s carbon emissions and leading a first iteration of a carbon reduction initiative
  • Identifying the underlying reasons for why we didn’t meet targets for a core GTM KPI and identifying optimizations
  • Supporting an initiative to increase customer CI adoption
  • Serving as the DRI for the SaaS free user initiative

How to Work

Many of the tasks are quick asks: handbook MRs, formatting changes, or questions to be answered. Small asks should be handled as quickly as possible. Other asks, such as OKR-related planning or an initiative that requires alignment with multiple stakeholders, require forethought and more appropriate timing. Some amount of time each week needs to be spent moving these sorts of tasks forward.

As a rule, everything in the doc is a TODO for the Office of the CEO. When tasks are DONE, they should be labeled as such. The CEO will review and delete the item once it’s been assessed as completed.

Prioritization

Since the team has limited capacity to lean into everything that it may want or be asked to, it is thoughtful about team and individual capacity. Members of the Office of the CEO will be expected to manage both directed and leadership (largely self-directed) work. You can find definitions and examples of directed and leadership work on the CoS to the CEO handbook page.

When newly initiated, self-directed, leadership work entails a significant time commitment (>20% capacity for more than a week), the work being done should be flagged to the CEO in a 1:1 or team meeting. This work should stay on the 1:1 agenda between the CoS to the CEO and the team member for the duration of the activity. If needed, activities may be reprioritized based on top demands and priorities.

More senior roles within the Office of the CEO can expect to have more leadership than directed work, but all roles should have a mix within a fiscal year.

Office of the CEO members should monitor the mix of directed and leadership work that they are doing and provide as appropriate in Office of the CEO Meetings, so the CoS to the CEO and CEO are aware of the current balance and can make adjustments, if needed.

Collaborating on Cross-Functional Initiatives

While there are rare exceptions, members of the Office of the CEO are not forever owners of initiatives. They plug in to help achieve critical milestones or fill gaps. When a member of the Office of the CEO joins an initiative, there should be agreement from key stakeholders around:

1. The level of support required
2. The Office of the CEO members’ scope and responsibilities
3. The exit criteria for the Office of the CEO
4. If required, the long-term plan for ongoing initiative or project support

Office of the CEO members can be reassigned based on the needs of the business and priorities of the CEO. In most cases, a member of the Office of the CEO will remain with a project until the exit criteria for the Office of the CEO is achieved. If a project extends beyond its anticipated timeframe or priorities change, a member may have to leave a project before the agreed upon exit criteria is achieved.

When a member of the Office of the CEO exits an ongoing initiative they will:

1. Provide as much notice as possible that the Office of the CEO will no longer support the initiative
2. Document their key responsibilities
3. Support a project DRI in identifying new owners
4. When possible, stay engaged in the initiative in a limited capacity during an agreed upon transition period

There may be instances in which the Office of the CEO leaving leads to a project scope being reduced or deprioritized. In these instances, the Office of the CEO member will be responsible for engaging key stakeholders around the keep/expand scope or go/no-go decision. It will be clearly documented and key folks will be involved in the decision and aware of the outcome.

E-Group Offsite

The executives get together every quarter for the e-group offsite. The CoS to the CEO plays an important role. It’s 3 to 4 days long with a Functional Leaders Meeting within the following days. There are recurring discussion topics as well as a discussion on content chosen by the CEO.

In addition, the CoS to the CEO is responsible for preparing the CEO for offsites by:

1. Finalizing the agenda to include CEO input
2. Working with the CEO on what to cover in offsite introductions and closings
3. Helping the CEO to prepare for sessions that the CEO will facilitate

Managing the Functional Leaders

Functional Leaders is a group comprised of all CEO-Skips, select People Business Partners, and a few other folks as nominated by members of E-Group. The CoS to the CEO enables and manages this group.

Program managing JiHu

A member of the Office of the CEO is the DRI within GitLab for the success of GitLab’s partnership with JiHu. Coordination with JiHu requires engagement from multiple functions within GitLab. The Office of the CEO ensures that the appropriate folks are engaged at the right times and that GitLab provides appropriate support to this separate entity.

For example, this member ensures that there is an aligned process among relevant GitLab functions after a customer requests to transit to JiHu:

1. After the Customer’s request of novation from GitLab to JiHu is approved, the member of the Office of the CEO opens a new issue as soon as the contract is issued, and assigns the issue to GitLab Accounting department.
2. This issue triggers the Accounting development to update SFDC, Zuora and NS.
3. If there is no issue raised in the month, it means there is no novation in that month.
4. This process takes effects from 2023-02-01, and replaces the previous process that an issue is created each month regardless whether there is novation in the month or not.

Organizational pulse

Due to its cross-functional scope and access to information, the Office of the CEO is uniquely positioned to see what is happening across the company. Members of the Office of the CEO are encouraged to regularly have coffee chats with folks outside of the team and share key insights and feedback from these conversations.

Measuring results

We are evaluating different ways to measure our success as a team. These include:

1. A company-wide team satisfaction score
2. A pulse survey sent to a few targeted folks who have worked closely with the Office of the CEO team members in the past quarter
3. Score against team quarterly goals
4. Score on success in a few top initiatives within a quarter

Chief of Staff Shadow

The Chief of Staff to the CEO may occasionally have a Chief of Staff Shadow, a GitLab team member who will participate in a specific project or initiative for a fixed time. Depending on the project or initiative, the team member may spend most of their time with an Office of the CEO team member instead.

Shadow responsibilities could include: taking notes, providing feedback, and/or supporting the overall initiative success. This role would be in addition to any existing responsibilities at GitLab. Participants would opt in to experience another function within GitLab and contribute to a different part of the business. Since participation would be in addition to an existing workload, managers must sign off before a CoS to the CEO Shadow can participate. Interested team members can share their interest with the Chief of Staff to the CEO in the #ceo-chief-of-staff-team Slack channel. The CoS to the CEO will follow up with you to understand what you are looking to get out of the experience and review projects that may be a good match. If there is not an existing project, you will be kept in mind for future opportunities.

Once a project or initiative to Shadow has been identified and the team member decides to participate, the team member should open a merge request to add their name to the below table. The MR should be shared through Slack in the #ceo-chief-of-staff-team channel for review and merge. Optionally, the team member can make use of the internship for learning as a framework to guide the Shadow period.

Important things to note

1. This is not a performance evaluation
2. Plan to observe and ask questions.
3. Participating in the shadow program is a privilege where you will be exposed to confidential information. This is underpinned by trust in the shadows to honor the confidentiality of topics being discussed and information shared. The continuation of this program is entirely dependent on shadows past, present, and future honoring this trust placed in them.
4. Give feedback to and receive feedback from the Chief of Staff to the CEO. Participants in the shadow program are encouraged to deliver candid feedback. Shadows maintaining confidentiality during the program is separate from shadows being able to provide candid feedback.

Quick Links

• Chief of Staff to the CEO Job Family
• Strategy & Operations Job Family
• GitLab Team Project
• Team readmes
• Embody Team

Contact Us

• #ceo-chief-of-staff-team on Slack (GitLab Team Members only)

GitLab / Google Groups

The Office of the CEO maintains a GitLab Group and Google Group to ensure the appropriate level of access is granted or removed as team members join and leave the team. The following mapping of permission levels from GitLab Groups to Google Groups is being used:

1. Owner -> Owner
2. Maintainer -> Manager
3. Developer -> Member

There is no automatic syncing between these groups so Office of the CEO team members who have the appropriate permission level in each group should add or remove team members as they join and leave the team.

GitLab Project

The primary project used by the Office of the CEO to track work specific to our team is Office of the CEO. Please file issues here as needed to track work being done.

View page source - Edit this page - please contribute.