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 functional groups, they can work something out on their own. When a project arises between three or more functional groups, 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.
An example of an underresourced project might be:
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 stregic 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.
Handbook changes that come through the doc can be converted to DONE in the doc with the MR linked if they are merged by the CoS or ISCs. MRs related to the board, what is not public, or the CEO's reponsibilities should be staged and merged by the CEO. If these occur in the doc, they become DOTOs, as they're action items for the CEO. Asks that come through Slack should have the MR linked in the appropriate thread, so that there is a closed loop in Slack.
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 CEO Evangelism process follows what is outlined in the [Executive Technical Evangelism] Process, whether or not it's technical evangelism.
The initial content review for the CEO should be in bullet points only. Then the CEO can talk through the slides and a team member can capture the CEO's tone of voice as he talks through the talk. This helps ensure the talk track is in the CEO's voice.
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.
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.
This is not the SSOT for these dates and is meant only for informational/organizational purposes.
CEO Evangelism
Informal Board Meetings
NomGov Meetings
Board Meetings
E-group Offsites
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.
