Articles by GitLab
- GitLab E-group offsite
This is the process documentation for GitLab's management team offsite. It covers: • Goals • Attendees • Logistics • Schedule • Offsite Topic Calendar: Recurring discussion topics & Pre-offsite discussion topics • Prep Work • Guidance for invited participants • Agenda and Documenting • Communication guidelines • Topic owner responsibilities • Team norms • Break guidelines • Follow up • Functional Leaders E-Group Offsite Engagement
- How Engineering Management Works at GitLab
The Gitlab team shares a training resource and operational guide for current and future managers.
- GitLab's Data Team's Charter
This is a great example of a team charter. It covers: • Our Mission & Principles • How Data Works at GitLab • How Data Teams Work Together • Data Team Job Levels • How We Measure Impact • How To Connect With Us
- GitLab's Public Roadmap: "Maturity"
GitLab exposes a 2-year roadmap across their 10 products, with a maturity designation per feature. This approach seems to work for GitLab, but may not work for all companies.
- GitLab's Internal Pricing Strategy
GitLab uses a buyer-based open core pricing model where features are tiered based on who cares most about the feature. The free tier contains all major features to promote adoption and growth. Lower tiers have more relative value per dollar to make it easier for free users to upgrade. GitLab aims to balance capturing value from paid tiers while promoting adoption of the full product scope. They default to moving features to lower tiers quickly to increase usage and contributions. The CEO makes final decisions on pricing and tiers based on recommendations from the product and other teams.
- GitLab's Code Review Guidelines
Gitlab's code review guidelines for GitLab team members and wider community members to ensure code is effective, understandable, maintainable, and secure.
- OKR Process at GitLab
This is a detailed manual for GitLab's OKR process: the timeline, the role of the CEO, the role of executives / department managers, and how to cascade them down through teams. • Objectives should be ambitious yet attainable, while Key Results provide measurable milestones for success. • The CEO initiates the OKR process each quarter and executives then propose OKRs for their functions. • Key Results are created as part of Objectives and can become Objectives for lower levels of the organization. • Teams update the status of their Key Results each month and score their Key Results at the end of the quarter based on achievement.
- GitLab's Content Marketing Process
In their internal company handbook, GitLab covers content team responsibilities, how to request content and copy reviews, how content is produced, and how content strategy is set.
- GitLab's Voluntary and Involuntary Termination Processes
This is an extremely detailed firing procedure, including how to create a private slack channel with HR, coordinate the termination date, figure out if a separation and release of claims agreement is necessary, etc.
- GitLab's Team Handbook
The GitLab handbook is the magnum opus of team handbooks. It is core to how GitLab operates as a remote company, and is over 7,000 pages long if it were to be printed. It is so important to GitLab that managers and executives are held accountable to an individual performance KPI on their contributions to the handbook. It is hosted on GitLab, of course.
- GitLab's Roles & Persona
This document discusses personas that GitLab uses to define their target audience and users. Personas help with messaging, marketing, and product design by representing ideal users. Both buyer and user personas are described, with buyers being the decision makers and users being influencers. User personas come from UX research while buyer personas are defined on their website. Organizational archetypes show how development teams are structured. The personas that GitLab markets and sells to include product managers, developers, and security engineers. It provides examples of various personas like Dakota the engineering director. Understanding these personas helps GitLab support the workflows and needs of their different users.
- Real-world Example: GitLab's Internal Positioning Doc
This actual positioning example not only includes a positioning statement, but also an FAQ that positions GitLab relative to specific competitors.
- GitLab's Internal Manual for 1:1s
GitLab's internal manual for 1:1s includes a 30 minute training video and covers 12 tips on how to conduct them. This manual also includes a training video on how to do career mapping, and steps on how transition 1:1s between managers.
- GitLab's Annual Planning Process
This is GitLab's actual, detailed planning process documentation, with a full timeline of events over the course of 4 months.
- GitLab Kickoff Meeting Process
GitLab's kickoffs cover standard components, such as problem statements and designs, but have a unique twist: they are recorded and posted for external viewing by customers and the GitLab community.
- GitLab's Product Designer Career Ladder
GitLab's design career ladder for ICs covers 4 levels. GitLab doesn't use skill groups, but does cover 10-15 skills per level.
- GitLab's Release Post Process & Template
This is the internal process description for how GitLab notifies their customers of product improvements on a monthly schedule. It includes the format, how to prioritize what to write about, and how PMs and PMMs collaborate to produce the post.
- Analyzing and synthesizing user research data
These are GitLab's internal guidelines on how to synthesize research. It covers how to: • Gather data and discuss with your team • Cluster the data into themes • Discuss and revise as needed • Distill findings into insights
- What does product marketing do at GitLab?
This handbook explains how Product Marketing fits into the broader strategic marketing function at GitLab. Click into "Product Marketing team" to learn how their team intersects and collaborates with other teams, what metrics they track, how they build use cases, and how they execute product releases and marketing launches.
- GitLab's On-Call Rotation Process
GitLab's internal process document for on-call rotations covers: • Expectations for On-Call • On-Call Rotation processes for Customer Emergencies, Reliability Engineering, Security, Development Team, and Quality Team
- GitLab's Handbook on Coaching
GitLab's internal guide to coaching covers: • How coaches coach, including the different hats for different conversations and the GROW Model • Attributes of a coachee • Trust and Coaching • Planning for Action
- GitLab Company Handbook: Our Product Prioritization Process
This is GitLab's internal prioritization process. They reference RICE, but also reference factors that are appropriate for their business, including security fixes, data-loss prevention, and availability.
- GitLab Team Retrospective Process
GitLab's teams follow a pretty standard retrospective. They also came up with a process for how to scale retrospectives across teams by introducing a "retrospective of retrospectives" process.
- Gitlab's Incident Classification System
The GitLab team's system for classifying severity and urgency of incidents.
- GitLab's Process for Underperformance and Performance Improvement Plans
GitLab's process guide explains who to discuss underperformance with, how to coach, and how to execute a performance improvement plan, including tying the PIP to company values.
- Incident Management Handbook
A comprehensive resource from the GitLab team outlining many aspects of incident response including: • Key Roles and Responsibilities • Runbooks • Tracking and Communication