Key Reviews

Purpose

At most companies, this would be a quarterly meeting for senior function leaders to present priorities, progress, and risk mitigations to the CEO. We allow some additional stakeholders to attend to invite a broader range of perspectives, give visibility to peers across functions, and create broader accountability.

Members of E-Group and department leaders nominated by their E-Group leader are optional attendees.

These meetings are designed to ensure that the CEO and function are aligned on:

1. Month-to-month variances.
2. Performance against the plan, forecast and operating model.
3. Connection between OKRs and KPIs.
4. Progress against Yearlies and OKRs.
5. Accountability to the rest of the company.

Key Metrics

1. KPIs of that function or department.
2. OKRs for that function.

Timing

Key Reviews are once per quarter.

Scheduling

The Sr. EBA to the CFO is the scheduling DRI for the Key Reviews and will schedule no more than 2 Key Reviews on a given day. The Key Review meeting invitations will utilize that review’s functional DRI’s Zoom account, always be set to record, and set the Sr. EBA to the CFO and the functional DRI’s corresponding EBA as co-hosts.

A Key Review should not be cancelled without permission. Permission to cancel or make changes to the Key Review schedule must be requested in the #key-review Slack channel, tagging the CFO for approval and the Sr. EBA to the CFO for awareness. If the CFO is not available, the CEO will make the decision. All changes to the Key Review schedule and/or invites have to be posted in the #key-review Slack channel.

The Key Review schedule will be posted in the #key-review Slack channel on the first Monday of each month (if that Monday falls on a holiday it will be posted on the next business day).

A Key Review does not need to be scheduled if everything is on track and awareness is good.

Invitees

Required invites are the CEO, the CFO, and the function head. Optional attendees are all other members of the e-group, VP-Directs, the Chief of Staff to the CEO, and other folks as designated by their E-Group member.

Key Review Meetings may contain MNPI. As materials are limited access, participation is limited.

If the Key Review meeting will not contain MNPI, it can be livestreamed to GitLab Unfiltered, with the distinction of being streamed as Private or Public, depending on the department.

Functions that have these quarterly meetings are:

1. Sales & Customer Success (Chris Weber - function DRI), mid-month 1
2. Marketing (Ashley Kramer - function DRI), mid-month 1
3. Product (David DeSanto - function DRI), mid-month 1
4. People Group (Wendy Barnes - function DRI), mid-month 1
5. Finance (Brian Robins - function DRI), end of month 1
6. Support (Johnny Scarborough Jr. - function DRI), month 2
7. Legal and Corporate Affairs (Robin Schulman - function DRI), end of month 2
8. Security (Josh Lemos - function DRI), end of month 2
9. Business Technology (Nabitha Rao - function DRI), beginning of month 3
10. Data (Amie Bright - function DRI), mid-month 3
11. Development (Christopher Lefelhocz - function DRI), month 3
12. Infrastructure (Mek Stittri - function DRI), month 3

Function DRIs are expected to review the invite list in advance of each Key Review. If cross-functional topics are being discussed, they are encouraged to invite folks who should be involved in the conversation. If there are MNPI concerns, they may choose to link to a separate agenda for this part of the discussion.

If you would like to be added to a function’s Key Review ask your functional E-Group member to ask the EBA to the CFO to add you.

Meeting Format

There are three meeting formats. The preferred meeting format leverages the KPI Slides project which uses Reveal JS to automate the slide preparation and leverages version control to provide a history of changes over time. Other teams leverage Google Slides for their meetings. Some teams leverage Sisense’s existing automation functionality to prepare Google Slides with automated charts.

Content to cover in each Key Review:

1. Review of 3-5 Discussion Topics. (65% of review time)
   1. Leaders are encouraged to highlight one or two specific discussion topics they would like to discuss or one decision they want to get alignment on. This helps to focus the conversation on important topics.
   2. We often share a lot of details within Key Review decks. The Discussion Topic section should clearly identify and elevate a 3-5 key items that warrant greater leadership awareness and attention. These could include progress on key contributors success contributors, an update on areas of urgent concern, or other topics which are valuable to surface to a broader group for awareness & collaboration.
   3. Review action items in prior quarter: results, learnings
   4. Review actions being taken now, expected impact, measurement plan
   5. Prioritize topics that need awareness or require coordination with/support from other teams. This should be a good forum to highlight when things are off track.
2. Progress against Yearlies/OKRs (30% of review time)
3. Key Metrics Update (5% of review time)

Important notes:

1. Before every Key Review, the OKRs should be updated by the functional DRI in GitLab Maintaining the status of OKRs.
2. A document will be linked from the calendar invite for participants to log questions or comments for discussion and to any additional track decisions & action items.
3. Every department KPI should be covered. This can be in the presentation and/or links to the handbook.
4. Wherever possible, the KPI or KR being reviewed should be compared to Plan, Target, or industry benchmark.
5. There is no presentation; the meeting is purely Q&A. Of course, people can ask to talk them through a slide. If you want to present, please post a YouTube video and link that from the slide deck, agenda, and/or Slack.
6. The functional owner is responsible for updating and posting their Key Review agenda 24 hours in advance of the meeting, post in the #key-review Slack channel.
7. Video is not required, but if there is a video it should be posted 24hrs in advance in the #key-review Slack channel.
8. The agenda document should include a presentation link that is accessible by all team members, as well as a Q&A section.
9. If the Key Review does not contain MNPI or not public information, it should be publicly streamed to YouTube Unfiltered in alignment with GitLab’s value of transparency. Key Reviews not containing MNPI with not public information should be privately streamed to YouTube Unfiltered. If the Key Review contains MNPI it should not be streamed, but can be recorded and shared in a limited access manner.
10. Should public or private streaming be unavailable, Key Reviews are set to auto-record to the cloud and should be uploaded to the GitLab Unfiltered Key Reviews Playlist on YouTube if it does not contain MNPI or not public information. It is the DRI’s or their EBA’s responsibility to ensure that the video, if not containing MNPI or not public information, is uploaded to GitLab Unfiltered with the correct visibility (private or public). If it contains MNPI, then the recording can be shared in a limited access manner.
11. If the function DRI is not available to attend their Key Review then the function’s leadership team is responsible for attending the meeting and providing updates.
12. Repetition in recognizing what is working or not working from month to month is okay as repetition can be an organizational tool for teaching people what’s important amidst all the noise.

Also see First Post is a badge of honor.

Group Conversations and Key Review Metrics

Function DRIs are expected to use and share their function’s Key Review deck, meeting notes and recordings for their scheduled Group Conversations. Any MNPI in the Key Review decks should be removed. Async Group Conversations should follow Key Reviews. The goal for these meetings are to discuss what is important and the decks should be the same. You can add additional slides to the Key Review to give more context, not all slides have to relate to KPIs and OKRs. The difference between the two meetings is the audience, the GCs are for a wider audience of the entire company.

Recordings

To view a recording of a Key Review, visit the playlist on YouTube Unfiltered titled Key Reviews. If you are unable to view a video, please ensure you are logged in as GitLab Unfiltered.

Automated KPI Slides

The original demo and proposal of using the KPI Slide project is on GitLab Unfiltered (internal).

The KPI Slides project is a GitLab-internal project since it includes KPIs that are not public. Those slides are deployed to GitLab pages (also internal, you must have access to the project to see the website). Each group that presents has one markdown file with their KPIs. Every month, groups create an MR to update that markdown file. The following slides need to be updated with an MR:

• Month on the first slide
• Key Business Takeaways- should especially highlight any KPIs that need attention
• OKR statuses

The following Key Reviews are automated: (all links are internal)

• Finance
• Infrastructure
• Marketing
• People
• Product

Google Slides

1. The functional owner will prepare a google slide presentation with the content to be reviewed.
2. The finance business partner assigned to the functional area will meet with the owner at least one week in advance and ensure that follow-ups from last meeting have been completed and that data to be presented has proper definitions and is derived from a Single Source of Truth.
3. The finance business partner / preparer of the key review deck will ensure that the google slide permissions are set to comment for all in the GitLab domain.
4. The title of every slide should be the key takeaway
5. A label on the slide should convey whether the metric result is “on-track” (green), “needs improvement” (yellow), or is an “urgent concern” (red).
6. Teams are encouraged to use this template.
7. Presentations should allow commenting from everyone at GitLab.

Leveraging Sisense in Google Slides

To create these slides, you will need Editor access in Sisense.

• Edit the chart you’re interested in.
• Click “Chart Format” (second tab on far right)
• Under Advanced, select “Expose Public CSV URL”
• Follow the instructions on pulling data out of Sisense
• Select the data set and add a chart to the sheet
• In the slides, Insert > Chart > From Sheets > find the one you’re looking for

Video with explanation of this meeting format (GitLab Internal)

Performance Indicator Pages

Many functions or departments now have Performance Indicator pages that allow one to move top-to-bottom in the handbook to see both KPIs and PIs. Here is an example of the VP of Development presenting the Development Department’s KPIs and PIs in advance of their monthly Key Review.

This method is ideal, as it is handbook-first and makes it easy for everyone to contribute. Commentary can be added via an MR to the data/performance_indicators.yml file. The executive summary section can help consumers of the information understand where to dig in futher.

The difficulty in using performance indicator pages for Key Reviews is for groups who have a signficant number of Performance Indicators that cannot be public. For folks looking to consume this information quickly, having to 2FA into Sisense to see the information can be frustrating. For functions or departments for which this is true, it is recommended to use a different Key Review format.

OKR Slides

OKR slides should:

1. Recap top department OKRs and KRs
2. Link to the department epics
3. Share completion status and provide a health score
4. Flag key achievements
5. Highlight risks or dependencies in need of discussion

At the end of each meeting, all atendees should be able to clearly answer what we are trying to achieve and whether we are on track. The Key Review immediately following the close of quarter should address not only new OKRs but also include an update on scoring of what we have achieved in the previous quarter.