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.
The CoST works closely with the CEO, the E-Group, the EBA to the CEO, and CEO Shadows.
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 a project 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 initatives.
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 plays a key role in support Board Meetings.
The Board Meetings page is the single source of truth for information on the Board, but some of the responsibilities of the Chief of staff include: As per the timeline:
The CoS team has been running the OKR process. We set OKRs on a fiscal quarter basis.
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.
OKR improvement points are in this issue: https://gitlab.com/gitlab-com/cos-team/-/issues/9
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 data team maintains a list 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.
The executives get together every quarter for the e-group offsite. The CoS plays an important role. It's 3-days long with an All-Directs the following day. There is a book. There are recurring content discussions. Here is feedback on the last offsite all-directs meeting.
The CoS runs the Board Meeting Process. It's useful to note the next meetings timeline. The CEO has a video and a memo that the CoS prepares.
Every spring the Board does a CEO Evaluation, through which a number of areas for focus come up. The CoS is reponsible for a quarterly update to the board on the progress made on those areas for focus. For example, if one area of focus is "set 3-year strategy", the CoS will review and refresh the strategy page, if appropriate, and share with the Board any updates made to the page.
The Fiscall Year Kickoff is the only all-hands-style meeting at GitLab. The CoS is responsible for organizing it.
The All-Directs group is made up of anyone who reports directly to the e-group. The CoS enables and manages this group.
We outline our biggest risks and our biggest tailwinds in the handbook. The CoS is reponsible for maintaining this list. There is an issue to also add DRIs and review the mitigations.
This is not the SSOT for these dates and is meant only for informational/organizational purposes.
Informal Board Meetings
NomGov Meetings
Board Meetings
E-group Offsites
On the CoST, we use Geekbot for our Daily Standups. These are posted in #chief-of-staff-team-standups in Slack. Once team members are added to the daily standup list, they will receive a message from Geekbot via DM once they've been active on Slack after 6 AM in their local timezone. There is no pressure to respond to Geekbot as soon as it messages you. When Geekbot asks, "What will you do today?" try answering with specific details. Give responses to Geekbot that truly communicate to your team what you're working on that day, so that your team can help you understand if some priority has shifted or there is additional context you may need.
Thoughput for the CoS team is measured as all MRs in across GitLab Company namespaces divided by the number of team members.
Executive Time is measured through the CEO calendar. Sid's Calendar Export is a private google sheet built of a google apps script.
The script is triggered to download all of the Calendar data every time it is run.
The filtered_columns tab on this sheet pulls only the relevant columns for analyses.
This tab is then pulled by SheetLoad into the SheetLoad drive and then ingested into Snowflake.
Events are categorized based on the event name and sender, as outlined by the EBA team best practices.
All personal events are filtered out.
Those categories are applied to our OKRs.
Every event only gets one category.
This is hard since some events may arguably fall into multiple.
For example, a 1:1 with a CRO could go towards IACV, but since it's a 1:1 it goes towards Great Team, like all 1:1s.
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.
