Compliment the CEO through being the cross-functional linchpin for GitLab when it comes to strategy and operations.
The Chief of Staff and their team may work on projects that fit any combination of the following:
This is not an exhaustive list of the types of work the CoS might do.
GitLab is a functional organization, which means the people are organized by function. Usually, when a project arises between two Departments, they can work something out on their own. When a project arises between three or more Departments, the Chief of Staff will be the point person to execute. In many cases, the Chief of Staff will be the directly responsible individual (DRI). Whether it's a product feature proposal, a new CI job for job families, or questions from the board, the CoS is the person who can be trusted to get things done, get them done quickly, and get them done right.
Examples of a cross-functional project:
As GitLab grows, projects will come up that are important but are under resourced. Chiefs of Staff are known for their 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 CoS 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 goal of the CoS is not to do the work of other teams, but help address work that those teams may not have bandwidth to address but are important to the organization and/or the CEO.
There may be projects with no clear leader for a myriad of reasons, including we're still hiring the point person or the lead is on leave. Because of the CoS's ability to come up to speed quickly, they may be tasked 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 SMEs.
Examples of projects with no clear leader:
Some projects or initiatives are very broad and cross-functional and make sense to belong to the CEO but are not a strategic use of the CEO's time. OKRs are a prime example. OKRs need to happen and are key to the business but it is not efficient for the CEO to shepherd the process along. The CoST 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:
The CEO will have other projects that come up that he will task the CoST with, such as following up on something or carrying on a conversation on his behalf.
Examples of tasks that are important to the CEO:
The CoST works through a doc titled "Chief of Staff, Cheri, and Sid." It's format is structured like the 1-1 Suggested Agenda Format. Many of the tasks on the sheet 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, requires 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 CoST. When tasks are DONE, they should be labelled as such. The CEO will review and delete the item once it's been assessed as completed.
We work from the bottom up in agendas, unless told to prioritize otherwise.
The Chief of Staff supports Board activities as specified in the Board Meeting section of the handbook and as directed by the CEO.
There is an OKR schedule that dictates the timeline of events. We use a handbook page for each quarter. The CEO's Objectives every quarter map to the sequence of our strategy. The CEO's KRs are what we're measuring for the company for that quarter.
While OKRs are what's changing every quarter, what we're focused on moving (improving, being more efficient, etc.), KPIs are how we're consistently measuring how we're doing as an organization. KPIs occur at multiple layers and have multiple parts. The CEO maintains an index of GitLab KPIs and links to where they are defined. There is a process for updating the list by adding, removing, or changing a KPI.
Group Conversations are updates on different parts of the company every 6 weeks. The Chief of Staff prepares the General Group Conversation slides for the CEO. During the General Group Conversations, please help facilitate the flow and ask team members to verbalize. The CEO gives a General Group Conversation that covers the whole of the company. The CEO's GC slides usually cover:
The Group Conversations are stored in the "CEO Evangelism" folder on Google Drive.
Be sure that slides are prepared with enough notice for the CEO to record a video and for it to be shared at least 24 hours in advance of the Group Conversation.
The executives get together every quarter for the e-group offsite. The CoS plays an important role. It's 3 to 4 days long with an All-Directs the following day. There is a content discussion. There are recurring content discussions. Here is feedback on the last offsite all-directs meeting.
In Q1 of a new fiscal year, the Chairperson of the Compensation Committee conducts the annual CEO Evaluation. The Chairperson meets with all members of GitLab's Board and E-Group for their feedback on the CEO's performance over the past Fiscal Year. The Chairperson meets with the CEO for their self-assessment at the beginning of the evaluation cycle.
The CEO's self assessment is centered on three main areas
The Staff EBA to the CEO assists the Chairperson to schedule the performance review meetings with each Board Member (50 minutes, 1:1) and E-Group member (25 minutes, 1:1). These are conducted in an interview format to capture the richest possible feedback regarding the CEO's performance. During these calls, Board Members can expect to share their perspectives on the CEO's major accomplishments and disappointments in areas such as: vision, strategy, operations, management team development, company culture and relationship with the Board. General areas of strength. Areas for improvement and/or additional focus. Key fiscal year strategic/operational, non financial goals.
The results from the Board and E-Group team interviews are summarized (without attribution) by the Chairperson and shared for discussion at the March Board of Directors meeting.
The CoS is responsible for a mid-year and an end of year update to the Board on the progress made across focus areas. This will come in the form of a progress scorecard. For example, if one area of focus is "set 3-year strategy", the CoS will evaluate whether the activity is on track or needs attention. The scorecard will be updated with a progress score (on track, needs attention, or at risk) and a high level summary of relevant key activities.
The All-Directs group is made up of anyone who reports directly to the e-group. The CoS enables and manages this group.
This is not the SSOT for these dates and is meant only for informational/organizational purposes.
Informal Board Meetings
The Chief of Staff may occasionally have a Chief of Staff Shadow, a GitLab team member who will participate in a specific project or initiative for a fixed period of time. 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 Shadow can participate. Interested team members can share their interest with the Chief of Staff in the #chief-of-staff-team channel. The CoST 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
#chief-of-staff-team for review and merge.
|Start Date||End Date||First & Last Name||GitLab Handle|