Expansion Development Department

Vision

Scale and develop our diverse, global team to drive results that support our product and customer growth, while maintaining our values and unique way of working.

Mission

GitLab’s unique way of working asynchronously, handbook first, using the product we develop, and with clear focus on our values enables very high productivity. In delivering on growth, we maintain our values and ways of working while developing team members and increasing the diversity of our team. We focus on constantly improving usability and reliability of our product to reach maximum customer satisfaction. Community contributions and customer interactions rely on efficient and effective communication. We are a data-driven, customer experience first, open core organization delivering one secure, reliable, world leading DevOps platform.

Efficiency

GitLab’s Development group ships thousands of product merge requests per month. Continuing to scale our development process to an ever larger number of contributors requires efficiency, collaboration, and iteration. In FY24, we want to keep our MR Rate stable as we continue to onboard new team members, increasing our overall output and demonstrating the scalability of our approach to development. We will focus on training our new hires on iteration and process improvements, saving team members time. We will also review the best metrics to focus on and are considering moving back to an overall MR Rate measure (from an authorship one). Doing so will help us measure the efficiency of our responsiveness to our peers for the company and the community.

Usability

User experience is a continued focus area for FY24. Millions of customers use GitLab so UX improvements can have a huge collective impact across all of these individuals.

Development team members should also constantly suggest and investigate how to improve the overall user experience of the product. These can range from enhancing performance (actual and perceived), suggesting new technologies, solving user experience issues efficiently, etc.

Product with a customer focus

Lastly, we will continue our strong partnership with Product to make GitLab the best, most complete DevSecOps platform on the planet. While we continue adding features to the product we must also work to identify technical debt and bring it to the prioritization discussion. We expect that Engineering managers are already addressing technical debt that is group specific with their Product Manager.

This coordination and prioritization requires a lot of work and effort to provide the right data and make the right decisions. We will focus on a variety of factors, but top of mind will be our parent department’s direction to be customer focused.

Diversity

We will follow our parent department Engineering lead.

Organizational responsibilities

The Expansion department includes the following sub-departments and groups:

• Secure
• Software Supply Chain Security
• Fulfillment
• Growth

Team Members

The following people are permanent members of the Development Department:

Name	Role
Aaron Huntsman	Senior Backend Engineer, Software Supply Chain Security:Pipeline Security
Aboobacker MK	Senior Backend Engineer, Software Supply Chain Security:Authentication
Adam Cohen	Staff Backend Engineer, Application Security Testing:Static Analysis
Adil Farrukh	Engineering Manager, Software Supply Chain Security:Authentication
Aditya Tiwari	Senior Backend Engineer, Application Security Testing:Secret Detection
Adrien Narinesingh	Associate Backend Engineer, Security Risk Management:Security Infrastructure
Ahmed Hemdan	Staff Backend Engineer, Application Security Testing:Secret Detection
Aishwarya Subramanian	Senior Backend Engineer, Fulfillment:Fulfillment Platform
Alan (Maciej) Paruszewski	Engineering Manager, Security Risk Management:Security Policies
Alex Buijs	Senior Fullstack Engineer, Software Supply Chain Security:Authorization
Alexander Dietrich	Senior Backend Engineer, Secure:Dynamic Analysis
Alexander Turinske	Staff Frontend Engineer, Security Risk Management:Security Policies
Aman Luthra	Backend Engineer, Fulfillment:Subscription Management Team
Amar Patel	Engineering Manager, Application Security Testing:Secret Detection
Ammar Alakkad	Senior Frontend Engineer, Fulfillment:Utilization
Andrew Evans	Senior Backend Engineer, Software Supply Chain Security:Authentication
Andrew Jung	Backend Engineer, Software Supply Chain Security:Compliance
Andy Schoenen	Senior Backend Engineer, Security Risk Management:Security Policies
Angelo Gulina	Senior Frontend Engineer, Fulfillment:Utilization, Fullstack Engineer (Intern), Fulfillment:Utilization
Arpit Gogia	Backend Engineer, Secure:Dynamic Analysis
Artur Fedorov	Senior Frontend Engineer, Security Risk Management:Security Policies
Ayush Billore	Backend Engineer, Software Supply Chain Security:Authorization
Bala Kumar Subramani	Senior Backend Engineer, Security Risk Management:Security Infrastructure
Bhavya Kaushal	Vulnerability Research Engineer
Bishwa Hang Rai	Senior Backend Engineer, Fulfillment:Purchase
Bogdan Denkovych	Senior Backend Engineer, Software Supply Chain Security:Authentication
Brian Williams	Staff Backend Engineer, Security Risk Management:Security Insights
Buck O'Leary	Senior Fullstack Engineer, Growth::Acquisition
Charlie Kroon	Fullstack Engineer, Security Risk Management:Security Insights
Chen Charnolevsky	Senior Frontend Engineer
Corinna Gogolok	Staff Backend Engineer, Fulfillment:Provision
Craig Smith	Senior Backend Engineer, Application Security Testing:Secret Detection
Daniel Abeles	Manager, Vulnerability Research Engineering
Daniel Tian	Senior Frontend Engineer, Software Supply Chain Security:Authorization
Darby Frey	Staff Fullstack Engineer, Expansion
Dave Pisek	Senior Frontend Engineer, Security Risk Management:Security Insights
David Hamp-Gonsalves	Senior Fullstack Engineer
Dheeraj Joshi	Senior Frontend Engineer, Secure:Secret Detection
Diana Zubova	Frontend Engineer, Fulfillment:Subscription Management Team
Diane Russel	Backend Engineer, Govern:Authorization
Dinesh Bolkensteyn	Staff Vulnerability Research Engineer, Vulnerability Research
Divya Mahadevan	Fullstack Engineer, Fulfillment:Provision
Dmytro Biryukov	Senior Backend Engineer, Govern:Pipeline Security
Dominic Bauer	Senior Backend Engineer, Security Risk Management:Security Policies
Doug Stull	Staff Fullstack Engineer, Growth:Acquisition
Drew Blessing	Senior Backend Engineer, Software Supply Chain Security:Authentication
Eduardo Sanz-Garcia	Senior Frontend Engineer, Software Supply Chain Security:Authentication
Erick Bajao	Senior Backend Engineer, Govern:Pipeline Security
Ethan Urie	Staff Backend Engineer, Application Security Testing:Secret Detection
Etienne Baqué	Senior Backend Engineer, Fulfillment:Fulfillment Platform
Eugie Limpin	Senior Fullstack Engineer, Software Supply Chain Security:Authorization
Fabien Catteau	Staff Backend Engineer, Secure:Composition Analysis
Fernando Cardenas	Senior Frontend Engineer, Secure:Composition Analysis
Gal Katz	Backend Engineer
Gregory Havenga	Senior Backend Engineer, Security Risk Management:Security Infrastructure
Hakeem Abdul-Razak	Associate Backend Engineer, Software Supply Chain Security:Authentication
Hannah Baker	Backend Engineer, Secure:Dynamic Analysis
Harsimar Sandhu	Senior Backend Engineer, Software Supply Chain Security:Compliance
Hinam Mehra	Fullstack Engineer, Software Supply Chain Security:Authorization
Hitesh Raghuvanshi	Senior Backend Engineer, Software Supply Chain Security:Compliance
Hua Yan	Application Security Testing:Senior Backend Engineer
Huzaifa Iftikhar	Senior Backend Engineer, Software Supply Chain Security:Compliance
Ian Anderson	Staff Backend Engineer, Software Supply Chain Security:Authorization
Igor Frenkel	Senior Backend Engineer, Secure:Composition Analysis
Illya Klymov	Staff Frontend Engineer, Software Supply Chain Security:Compliance
Imre Farkas	Staff Backend Engineer, Software Supply Chain Security:Authentication
Isaac Dawson	Principal Vulnerability Research Engineer, Vulnerability Research
James Lopez	Senior Engineering Manager, Fulfillment:Fulfillment Platform & Fulfillment:Utilization
Jarka Košanová	Staff Backend Engineer, Software Supply Chain Security:Authorization
Jason Goodman	Senior Backend Engineer, Fulfillment:Utilization
Jason Leasure	Application Security Testing:Staff Backend Engineer
Jay Montal	Senior Fullstack Engineer, Growth::Acquisition
Jay Swain	Engineering Manager, Software Supply Chain Security:Authorization
Jerome Ng	Director of Engineering, Fulfillment
Joey Khabie	Backend Engineer
Josianne Hyson	Backend Engineer, Fulfillment:Subscription Management Team
Julian Thome	Application Security Testing:Staff Backend Engineer
Kamil Niechajewicz	Engineering Manager, Growth
Kos Palchyk	Senior Frontend Engineer, Fulfillment:Utilization
Lorenz van Herwaarden	Senior Frontend Engineer, Security Risk Management:Security Insights
Lucas Charles	Principal Engineer, Secure & Govern
Lukas Wanko	Fullstack Engineer
Marcos Rocha	Backend Engineer, Security Risk Management:Security Policies
Martin Cavoj	Senior Fullstack Engineer, Security Risk Management:Security Policies
Mehmet Emin Inac	Staff Backend Engineer, Security Risk Management:Security Infrastructure
Meir Benayoun	Staff Backend Engineer, Application Security Testing:Static Analysis
Mher Tolpin	Application Security Testing:Senior Backend Engineer
Michael "Maw" Wildpaner	VP, Engineering
Michael Becker	Senior Backend Engineer, Security Risk Management:Security Insights
Michael Henriksen	Senior Vulnerability Research Engineer, Vulnerability Research
Michael Lunøe	Staff Frontend Engineer, Fulfillment:Subscription Management Team
Michał Zając	Senior Backend Engineer, Security Risk Management:Security Infrastructure
Mike Eddington	Staff Backend Engineer, Secure:Dynamic Analysis
Miki Amos	Senior Backend Engineer, Secure:Composition Analysis
Minahil Nichols	Fullstack Engineer, Fulfillment:Subscription Management Team
Miranda Fluharty	Frontend Engineer, Govern:Pipeline Security
Mireya Andres	Frontend Engineer, Govern:Pipeline Security
Mo Khan	Senior Backend Engineer, Software Supply Chain Security:Authorization
Mohamed Moustafa	Fullstack Engineer
Nataliia Radina	Frontend Engineer, Software Supply Chain Security:Compliance
Nathan Rosandich	Engineering Manager, Software Supply Chain Security:Compliance
Neil McCorrison	Engineering Manager, Security Risk Management:Security Insights
Nick Ilieskou	Senior Backend Engineer, Secure:Composition Analysis
Olivier Gonzalez	Staff Backend Engineer, Secure:Composition Analysis
Or Gal	Manager, Software Engineering
Orin Naaman	Backend Engineer, Secure:Composition Analysis
Oscar Tovar	Senior Backend Engineer, Secure:Composition Analysis
Paulo Barros	Senior Backend Engineer, Fulfillment:Provision
Philip Cunningham	Senior Backend Engineer, Application Security Testing:Composition Analysis
Qingyu Zhao	Senior Backend Engineer, Fulfillment:Provision
Radu Birsan	Fullstack Engineer
Ragnar Hardarson	Engineering Manager, Fulfillment:Subscription Management Team
Ross Fuhrman	Senior Backend Engineer, Secure:Secret Detection
Roy Liu	Associate Fullstack Engineer, Growth:Acquisition
Rushik Subba	Intermediate Backend Engineer, Security Risk Management:Security Infrastructure
Ryan Cobb	Backend Engineer, Fulfillment:Subscription Management Team
Ryan Wells	Engineering Manager, Security Risk Management:Security Infrastructure
Sam Figueroa	Fullstack Engineer, Software Supply Chain Security:Compliance
Samantha Ming	Senior Frontend Engineer, Security Risk Management:Security Insights
Sashi Kumar Kumaresan	Staff Backend Engineer, Security Risk Management:Security Policies
Savas Vedova	Staff Frontend Engineer, Security Risk Management:Security Insights
Schmil Monderer	Staff Backend Engineer, Security Risk Management:Security Infrastructure
Scott Hampton	Engineering Manager, Govern:Pipeline Security
Senior Backend Engineer	Senior Backend Engineer
Senior Manager, Software Engineering	Senior Manager, Software Engineering
Serena Fang	Backend Engineer, Application Security Testing:Secret Detection
Serhii Yarynovskyi	Fullstack Engineer, Growth:Acquisition
Shabini Rajadas	Backend Engineer, Govern:Pipeline Security
Shao Ming Tan	Backend Engineer, Application Security Testing:Composition Analysis
Sharmad Nachnolkar	Senior Frontend Engineer, Fulfillment:Subscription Management Team
Sheldon Led	Senior Frontend Engineer, Fulfillment::Utilization
Shreyas Agarwal	Senior Backend Engineer, Fulfillment:Platform
Smriti Garg	Senior Backend Engineer, Software Supply Chain Security:Authentication
Subashis Chakraborty	Senior Backend Engineer, Security Risk Management:Security Insights
Sunny Mittal	Staff Technical Program Manager
Suraj Tripathi	Senior Backend Engineer, Fulfillment:Utilization
Tal Kopel	Manager, Software Engineering, Secure:Composition Analysis
Tarun Vellishetty	Fullstack Engineer, Fulfillment:Fulfillment Platform
Thiago Figueiró	Manager, Software Engineering, Secure:Composition Analysis
Thomas Woodham	Senior Engineering Manager, Secure
Tyler Amos	Staff Backend Engineer, Fulfillment:Fulfillment Platform
Ugo Nnanna Okeadu	Backend Engineer, Security Risk Management:Security Insights
Vamsi Vempati	Senior Frontend Engineer, Fulfillment:Subscription Management Team
Vijay Hawoldar	Staff Backend Engineer, Fulfillment:Utilization
Vishwa Bhat	Senior Backend Engineer, Application Security Testing:Secret Detection
Vitaly Slobodin	Staff Frontend Engineer, Fulfillment:Fulfillment Platform
Vladlena Shumilo	Senior Backend Engineer, Fulfillment:Fulfillment Platform
Yasha Rise	Senior Backend Engineer, Secure:Composition Analysis
Zamir Martins Filho	Senior Fullstack Engineer, Secure:Composition Analysis

Stable Counterparts

The following members of other functional teams are our stable counterparts:

Development-Specific People Processes

Promotion Process

Aligned with the company-wide promotion cadence, Development utilizes a quarterly process to collect, validate, approve, review all promotion proposals prior to them being added via the company-wide process. The goal of this quarterly promotion projection and review is to:

• Promote the right people at the right time
• Maintain a high bar for promotions
• Ensure predictability and intentionality with promotions
• Ensure alignment with overall company promotion rate
• Add another layer of review to reduce bias in the promotion process

Development adheres to the company-wide quarterly timeline outlined here as our SSOT.

The Development Department has an additional formal step built in to our promotion process beyond what the company is currently adhering to through our peer review process. Ahead of the commencement of the Calibration stage of our process, all promotion documents should be peer reviewed by a Senior Manager or Director. The due date to complete the peer review is before the scheduled Calibration session.

FY'23 Calibration sessions:

1. FY24-Q1: January 13, 2022
2. FY24-Q2: April 7, 2022
3. FY24-Q3: June 30, 2022
4. FY24-Q4: October 5, 2022

Calibration session attendees are the following team members: Senior Managers, Directors, Sr. Directors, VP, and Development’s aligned People Business Partner. Leaders are welcome to conduct Calibration sessions prior to the scheduled sessions above with their sub-departments as well (though this is not a requirement).

In addition to the company-wide calibration preparation, for the Development department we also ask that leaders come prepared to discuss:

1. Status of maintainership
2. Most recent talent assessment

Calibration Agenda

In order for calibration to be effective it’s important that all participants have had an opportunity to review promotional documents and summaries ahead of the meeting.

The calibration agenda will consist of the following for each candidate:

1. General Information

   • Promotion Doc Peer Reviewer(s)
   • Link to GitLab Profile

2. Core accomplishments (list 2)

3. Improvement areas (list 2)

   • The promotion document outlines strengths, but we also want to highlight how we will support a team member’s development areas at the next level.

4. Cross-functional Feedback

   • As our business goals and initiatives become increasingly cross-functional, managers should have a picture of how their team member collaborates effectively within their immediate teams, and with their core cross-functional partners and stakeholders.

5. Questions/feedback?

Please aim to be concise and crisp in the calibration agenda summary for each candidate. Leaders are able to reference promotion documents for details, while the calibration agenda summary is meant to be a snapshot of key points to help facilitate discussion and provide an overview for the group.

To allow time for review and the addition of questions/feedback, summaries should be included in the agenda no less than one week prior to the Development Leadership scheduled calibration date.

In line with our guidance on feedback, feedback should be regular and ongoing. Calibration sessions are meant to discuss team member promotion readiness and calibrate promotions across the department, but they should not replace the regular and ongoing feedback provided throughout the year. Any relevant feedback should be given promptly and not wait until talent assessments or promotion calibration. This will ensure that both the team member and their manager have an opportunity to address feedback in a timely manner.

Talent Assessment Process

Talent Assessment Process guidelines specific for the Expansion Development Department is documented in this handbook page.

How we hire contractors

In this handbook page we document the process that the development departments follow, including planning budget, candidate sourcing, interview process, contracting and onboarding.

How We Work

Onboarding

Welcome to GitLab! We are excited for you to join us. Here are some curated resources to get you started:

• Joining as an Engineer
• Joining as an Engineering Manager

Cross-Functional Metrics

Link to dashboard

Overview

The Cross-Functional Prioritization framework exists to give everyone a voice within the product development quad (PM, Development, Quality, and UX). By doing this, we are able to achieve and maintain an optimal balance of new features, security fixes, availability work, performance improvements, bug fixes, technical debt, etc. while providing transparency into prioritization and work status to internal and external stakeholders so they can advocate for their work items. Through this framework, team members will be able to drive conversations about what’s best for their quad and ensure there is alignment within each milestone.

The Cross-Functional Prioritization contains three key tenets:

• Release slate is divided into three main components: features and usability, optimization and maintenance, and bugs including severity-based SLAs
• Cross-functional DRIs are responsible for prioritization in each section, anyone is still able to advocate for prioritization changes
• DRI decisions informed by qualitative and quantitative data, up to and including automatic scheduling of work items based on SLA policies

An aspirational goal for the R&D organization is achieving an end state where our aggregate R&D development capacity is allocated along a 60%/40% split as follows:

• 60%: focused on features and usability
• 40%: focused on optimization, general maintenance, security items, and bugs

We recognize that making progress towards our desired end state requires significant effort and cannot be achieved immediately. Success will require cross-functional discipline, diligence, and alignment in both planning and execution, with tangible progress towards our desired end state 60%/40% split being measurable release over release. We recognize that based upon the maturity of a given area, this ratio may need to be different per team. We see this represented in data today across the portfolio, where for example a team with relatively immature features may require more feature work allocated, while teams with more mature features carry a heavier maintenance burden. Each group has the ownership and accountability to define the correct ratio across all categories based on Category maturity as well as maintenance needed to continue meeting our security, scalability, reliability, availability, and quality requirements. Teams will align with R&D leadership across Product & Engineering to ensure R&D demonstrate continuous improvement towards our desired 60%/40% end state.

The table below summarizes the 60%/40% split by component:

A balance across these components while empowering DRIs will allow GitLab to operate in a way that will allow us to meet (and exceed) revenue goals while maintaining the security, stability, reliability, and availability of our platform.

Cross-functional milestone planning

To support GitLab’s long-term product health and stability while keeping the pace of new features for users, teams are asked to plan their milestones with an appropriate ratio of work. When labeling, if the label selection for an issue or merge request isn’t obvious, work with your peers/manager or reach out to Staff TPM R&D Compliance for further clarification.

To assist with reporting and support SOX compliance, please review and leverage the labels per table below:

Note: These are the original labels from the working group. These were chosen so that teams would not have to relabel historically, and existing dashboards would not be broken.

If one of these labels clearly doesn’t apply for an issue, consider using the type::ignore label. This will exclude the issue from automation and dashboards used to do cross-functional prioritization and metrics tracking for the product. It is highly important we have accurate data, so please only use this label if the issue clearly does not pertain directly to Engineering changes to the product itself. This label will typically apply to issues used for planning or to track a process. For example, you could use the type::ignore label for a milestone planning issue where the issue’s purpose is organization and will not have MRs directly associated with it.

A team’s ratio might change over time and different teams may have different ratios. Factors that influence what ratio is appropriate for a given team include the product category maturity, the area of the product they are working in, and the evolving needs of GitLab the business. Teams should review labeling for accuracy and minimize the number of type::undefined items. This allows us to review the plans at the group, section, and company level with team members to ensure we appropriately prioritize based on cross-functional perspectives.

For more details on these three work types, please see the section on work type classification. The development EM is the DRI to ensure that the merge requests are accurately labeled.

Prioritization and DRI by Component

Our backlog should be prioritized on an ongoing basis. Prioritization will be done via quad planning (collaboration between product, development, quality, UX) with PM as the DRI for the milestone plan. PMs, EMs, Quality, and UX will provide the following:

1. Product Manager provides prioritized type::feature issues
2. Engineering Manager in development provides prioritized type::maintenance issues
3. Test Platform Managers provide prioritized type::bug issues using the bug prioritization dashboard

Note: UX-related work items would be prioritized in accordance with the appropriate sub-types. UX related bugs are included in the automated process (S1/2 and so on), UX-related maintenance items will be included in the EM’s prioritized list, Product (feature) UX items will have been included as part of our normal Product Development Flow.

The DRIs of these three core areas will work collaboratively to ensure the overall prioritization of the backlog is in alignment with section direction or any other necessary product and business needs. If a team is not assigned a Product Designer then there is no UX counterpart needed for prioritization purposes. PMs will prioritize the final plan for a given milestone.

Milestone planning and prioritization

Quads should follow the standard milestone planning process as described in our Product Development Flow. PMs will keep the overall prioritized backlog following the agreed-upon ratios and guidance from their EM, Quality and UX counterparts.

Review and monitoring team health

Stable counterparts across the quad should regularly review their overall team health across many measures, including their merge request ratio and make adjustments accordingly. For guidance, below are some questions to ask to inform that discussion.

Example questions to ask as stable counterparts review team health

Context:

1. What groups/sections does this review cover?
2. Is the dashboard accurate? Are the number of merge requests in the dashboard within 5% of the SSOT (the issues themselves)? If not, what needs to be done to correct?

Maintenance/quality:

1. Are the % of undefined merge requests < 1% for the timeframe being analyzed? If not, what should be done to correct?
2. How do error budgets look?
3. Are past due bugs being prevented/prioritized as appropriate?
4. Are usability issues being prioritized as appropriate?
5. Are security issues being prioritized as appropriate?
6. Are infrastructure backlog issues being prioritized as appropriate?
7. Are maintenance priorities from the engineering development manager being prioritized as appropriate?

Features:

1. How is the group addressing the product investment themes?
2. How do revenue drivers impact plans for this group?
3. How are customer requests being addressed for this group?

Trends:

1. Evaluate the percentage ratios of completed work (feature / maintenance / bug) for the previous milestone/timeframe against the team’s planned ratio for that milestone.
2. Is there predictability from milestone to milestone (number of issues or issue weight per release)?
3. Compare the planned milestone with the previous months merge request trends for the team. Any trends to note?
4. What overall trends does the group want to highlight?
5. What flags do you want to raise? What won’t happen?

Cross-Functional Collaboration

Working across Stages

Issues that impact code in another team’s product stage should be approached collaboratively with the relevant Product, UX, and Engineering managers prior to work commencing, and reviewed by the engineers responsible for that stage.

We do this to ensure that the team responsible for that area of the code base is aware of the impact of any changes being made and can influence architecture, maintainability, and approach in a way that meets their stage’s roadmap.

Architectural Collaboration

At times when cross-functional, or cross-departmental architectural collaboration is needed, the GitLab Architecture Evolution Workflow should be followed.

Follow the Sun Coverage

When cross-functional collaboration is required across global regions and time zones, it is recommended to adopt the Follow the Sun Coverage approach to ensure seamless global collaboration.

Decisions requiring approvals

At GitLab we value freedom and responsibility over rigidity. However, there are some technical decisions that will require approval before moving forward. Those scenarios are outlined in our required approvals section.

Security Vulnerability Handling

1. The development groups who introduce or consume the dependency of concern (e.g. gems, libs, base images, etc.) are responsible for resolving vulnerabilities detected against the dependency.
2. For business selected vendors that provide base images (RHEL’s UBI8 for example), we need to wait for their patches, or need to log Deviation Request (DR) as viable resolutions. The VulnMapper, an automation developed by the Threat Management team, can create vendor dependency DRs to a large extent, but there are still cases that DR needs to be reported manually.
3. The assigned development group can redirect issues if the initial assignment was inaccurate, following the processes for shared responsibility issues and/or Shared responsibility functionality.

Development Headcount planning

Development’s headcount planning follows the Engineering headcount planning and long term profitability targets. Development headcount is a percentage of overall engineering headcount. For FY20, the headcount size is 271 or ~58% of overall engineering headcount.

We follow normal span of control both for our managers and directors of 4 to 10. Our sub-departments and teams match as closely as we can to the Product Hierarchy to best map 1:1 to Product Managers.

Development Staff Meeting

While we try to work as much as possible async, the Development department leadership does meet synchronously on a cadence of weekly. This meeting coordinates initiatives, communicates relevant information, discusses more difficult decisions, and provides feedback on how we are progressing as an organization. As part of this meeting, we discuss our culture of reliability monthly. This was part of the agenda spawned from an initiative we took up in August of 2021. We want to make sure we keep the organization healthy when thinking about reliability in every part of our work.

Daily Duties for Engineering Directors

This section applies to those who report to the VP of Development

The following is a non exhaustive list of daily duties for engineering directors, while some items are only applicable at certain time, though.

1. Review engineering metrics
   1. Development Department Performance Indicators
   2. Sub-department Performance Indicators
   3. Dev
   4. Enablement
   5. Fulfillment
   6. Growth
   7. Ops
   8. Secure
   9. Software Supply Chain Security
2. Review hiring dashboards
3. Personal todo list
4. Personal GitLab board(s) if any
5. Working groups that the director drives or participates in
   1. Action items in agenda documents
   2. Issue boards
   3. Slack channel
6. Infradev triage
   1. Follow up open questions and ensure appropriate handling of issues with regard to priority and severity
   2. Agenda document
   3. Infradev board
7. Performance refinement
   1. Follow up open questions and ensure appropriate handling of issues with regard to priority and severity
   2. Agenda document
   3. Performance board
8. Infrastructure Development Escalations
   1. Triage new issues, enhance Issue details and ensure appropriate handling based on priority and severity
   2. Sync discussions for infradev Issues are part of the GitLab SaaS Weekly Meeting
   3. Agenda document
   4. Infradev board
9. Follow active Engineering Global Prioritization(s) that the director sponsors
   1. Standup/status update document
   2. Issue board
10. Holiday Emergency Contact Rotations
11. Review and approve security approvals for the GitLab project when required and informing the security engineering team when a security risk is accepted rather than being resolved prior to approval.

Developing and Tracking OKRs

In general, OKRs flow top-down and align to the company and upper level organization goals.

Managers and Directors

For managers and directors, please refer to a good walk-through example of OKR format for developing team OKRs. Consider stubbing out OKRs early in the last month of the current quarter, and get the OKRs in shape (e.g. fleshing out details and making them SMART) no later than the end of the current quarter.

It is recommended to assess progress weekly.

1. Append the percentage score to the subject of Objective epics and Key Result issues.
2. Set the Health status of epics and issues.
3. In the case where weekly assessment is impractical, an assessment shall be made by the end of each month.

Staff Engineers, Distinguished Engineers, and Fellows

Below are tips for developing individual’s OKRs:

1. Align OKRs to team goals. However, it’s unnecessary to derive from all organizational OKRs. Simply decide what makes sense to your personal situation.
2. Follow the same timeline of managers and directors, i.e. stubbing out early and bring OKRs in shape by the end of the current quarter.
3. Refer to the same walk-through example of OKR format.
4. Make SMART OKRs - Specific, Measurable, Achievable, Relevant, Time-bound.
5. Follow the same progress assessment instructions above.

Examples

1. Engineering
2. Development

Engineering Allocations and Tracking

Engineering Allocation require us to track goals with more diligence and thought. We need confidence that we’re making correct decisions and executing well to these initiatives. As such, you will see us reviewing these more closely than other initiatives. We will meet on a cadence to review these initiatives and request additional reporting to support the process. Possible requests for additional data:

1. Demos
2. GitLab Roadmaps
3. GitLab Architecture Workflow
4. Dogfooding of features we think may be useful

We will hold Engineering Allocation Checkpoints on a cadence. The recommended cadence is weekly.

Roadmaps for Engineering Allocations

We track Engineering Allocation roadmaps. To use this effectively, roadmaps must have correct dates for their epic and weights assigned to issues. If a team does not normally use weights, then assign each issue a weight of 1 (all issues are equal).

Team allocation measurement

Each team needs to demonstrate how their allocation is being used. This is done to verify we are not over/under investing for a given initiative. This can be done via assignment (people assigned to work) and/or issues assigned. We will track issues and MRs and see as a percentage how that compares to the overall teams work.

Ownership of Shared Services and Components

The GitLab application is built on top of many shared services and components, such as PostgreSQL database, Redis, Sidekiq, Prometheus and so on. These services are tightly woven into each feature’s rails code base. Very often, there is need to identify the DRI when demand arises, be it feature request, incident escalation, technical debt, or bug fixes. Below is a guide to help people quickly locate the best parties who may assist on the subject matter.

Ownership Models

There are a few available models to choose from so that the flexibility is maximized to streamline what works best for a specific shared service and component.

1. Centralized with Specific Team
   1. A single group owns the backlog of a specific shared service including new feature requests, bug fixes, and technical debt. There may or may not be a counterpart Product Manager.
   2. The single group is a specific team, meaning there is an engineering manager and all domain owner individuals reside in this team. The DRI is the engineering manager.
   3. This single group is expected to collaborate closely and regularly in grooming and planning backlog.
   4. This model may require consensus from the Product Management counterpart.
   5. This model may fit a subject domain that experiences active development.
2. Centralized with Virtual Team
   1. A single group owns the backlog of a specific shared service including new feature requests, bug fixes, and technical debt. There may or may not be a counterpart Product Manager.
   2. The single group is a virtual team, meaning it consists of engineers from various engineering teams, for example maintainers or subject matter experts. Typically there isn’t an engineering manager for this virtual team. The DRI is an appointed person in the group who may not necessarily be an engineering manager.
   3. This single group is expected to collaborate closely and regularly in grooming and planning backlog.
   4. This model may fit a subject domain that’s in maintenance mode.
3. Collectives
   1. Collectives consist of individuals from existing teams who voluntarily rally around a shared interest or responsibility, but unlike Working Groups may exist in perpetuity. The shared interest could be a specific technology or system. Collective members feel a collective responsibility to weakly own, improve upon or otherwise steer the subject they govern.
   2. This is a weaker form of the Virtual Team but introduces more structure than a fully decentralized model. It can be appropriate when some form of ownership is desirable where the subject has cross-cutting impact and wide reach and cannot clearly be allocated to any specific team.
   3. Collectives do not have product or engineering managers, they are fully self-governed.
   4. Members of the Collective sync regularly and keep each other informed about the shared interest. Problem areas are identified and formalized in the Collective, but are not logged into a Collective backlog. Instead a DRI is assigned who should put the task forward to the team with the greatest need for the problem to be resolved. This is to ensure that work is distributed fairly and that there are no two backlogs that compete with each other for priorities.
   5. Collectives work best when they consist of a diverse set of individuals from different areas of product and engineering. They double as knowledge sharing hubs where information is exchanged from across teams in the Collective first, and then carried back by the individuals to their specific teams.
4. Decentralized
   1. The team who implements specific functions or utilizes certain features of the shared services is responsible for their changes from local development environment to production deployment to continued maintenance post-deployment. There is not a development-wide single DRI who owns a portion or the entirety of a shared service.
   2. A specialty team may exist for specific subject domains, however their role is to enable scalability, availability, and performance by building a solid foundation and great tools for testing and troubleshooting for other engineering teams, while they are not responsible for gating every single change in the subject domain.

Shared Services and Components

The shared services and components below are extracted from the GitLab product documentation.

Learning Resources

For a list of resources and information on our GitLab Learn channel for Development, consult this page.

Continuous Delivery, Infrastructure and Quality Collaboration

In late June 2019, we moved from a monthly release cadence to a more continuous delivery model. This has led to us changing from issues being concentrated during the deployment to a more constant flow. With the adoption of continuous delivery, there is an organizational mismatch in cadence between changes that are regularly introduced in the environment and the monthly development cadence.

To reduce this, infrastructure and quality will engage development via SaaS Infrastructure Weekly and Performance refinement which represent critical issues to be addressed in development from infrastructure and quality.

Refinement will happen on a weekly basis and involve a member of infrastructure, quality, product management, and development.

Global Prioritization

Execution of a Global prioritization can take many forms. This is worked with both Product and Engineering Leadership engaged. Either party can activate a proposal in this area. The options available and when to use them are the following:

• Rapid action - use when reassignment isn’t necessary, the epic can have several issues assigned to multiple teams
• Borrow - use when a temporary assignment to a team is required to help resolve an issue/epic
• Realignment - use when a permanent assignment to a team is required to resolve ongoing challenges

Email alias and roll-up

1. Available email alias (a.k.a. Google group): Managers, Directors, VP’s teams: each alias includes everyone in the respective organization.
2. Naming convention: team@gitlab.com, examples below -
   • Managers: configure-be@gitlab.com includes all the engineers reporting to the Configure backend engineering manager.
   • Directors: ops-section@gitlab.com includes all the engineers and managers reporting to the director of engineering, Ops.
   • VP of Development: development@gitlab.com includes all engineers, managers, and directors reporting to the VP of Development.
3. Roll up: Teams roll up by the org chart hierarchy -
   • Engineering managers’ aliases are included in respective Sub-department aliases
   • Sub-department aliases are included in Development alias

Working with Support

When Development collaborates with Support it provides invaluable insight into how customers are using the product and the challenges they run into. A few tips to make the process efficient:

• Get access to Zendesk so you view the question and communication from customers.
• Always write answers in a way that they can be “cut-and-pasted” and sent to a customer.
• Reference documentation in your responses and make updates to GitLab documentation when needed.
• Refer to existing issues and epics to reiterate our transparency value and to invite participation from the customer.
• If you are unclear about the support-development collaboration process or workflow then please refer to the handbook page how to use gitlab.com to request help from the GitLab development team

Incident Management

Team members in some job families contribute to incident management directly through an on-call schedule for Incident Managers. Team members should complete onboarding so they can be added to the schedule when needed. These frequently asked questions cover exemptions and changing shifts.

• Incident Management process
• Incident Manager On Call onboarding

Development Escalation Process

• General information
• Process outline

Reducing the impact of far-reaching work

Because our teams are working in separate groups within a single application, there is a high potential for our changes to impact other groups or the application as a whole. We have to be cautious not to inadvertently impact overall system quality but also availability, reliability, performance, and security.

An example would be a change to user authentication or login, which might impact seemingly unrelated services, such as project management or viewing an issue.

Far-reaching work is work that has wide-ranging, diffuse implications, and includes changes to areas which will:

1. be utilized by a high percentage of users
2. impact entire services
3. touch multiple areas of the application
4. potentially have legal, security, or compliance consequences
5. potentially impact revenue

If your group, product area, feature, or merge request fits within one of the descriptions above, you must seek to understand your impact and how to reduce it. When releasing far-reaching work, use a rollout plan. You might additionally need to consider creating a one-off process for those types of changes, such as:

• Creating a rollout plan procedure
  • Consider how to reduce the risk in your rollout plan
  • Document how to monitor the rollout while in progress
  • Describe the metrics you will use to determine the success of the rollout
  • Account for different states of data during rollout, such as cached data or data that was in a previously valid state
• Requiring feature flag usage (example)
• Changing a recommended process to a required process for this change, such as a domain expert review
• Requesting manual testing of the work before approval

Identified areas

Some areas have already been identified that meet the definition above, and may consider altered approaches in their work:

AI-powered stakeholders

This section provides an overview of all teams invested in implementing and maintaining AI features. Our Duo initiative is a cross-category effort.

These are the stakeholders:

ClickHouse Datastore usage

ClickHouse usage by Monitor:Platform Insights group

Customer Account Escalation coordination

If development is the DRI or actively participating in a Customer Account Escalation, consider the following:

• Be careful to not make commitments to customers without first talking to product management and development leaders to confirm the impact that commitment may have on other commitments.
• The customer will want to know when they can see the benefits of a change. They may not be familiar with GitLab practices for tracking and predicting due dates and milestones. Also, they may not be familiar with our workflows and associated labels nor the predictability of code review timelines, different timelines on releases to GitLab.com compared with releases for self-hosted customers and our use of feature flags.

* Customers often don't rely on asynchronous communication at the level that GitLab does. Educate the customer on our practices and adapt to find a combined asynchronous and synchronous communication method and cadence that works for everyone.
* Encourage customers to collaborate with us in epics, issues, and merge requests of interest. Keep in mind that they may not have access to ones that are confidential and/or may not be comfortable or able to collaborate with us in this public forum.
* Consider utilizing Google documents to collaborate with the customer as a backup for collaboration via epics, issues, and merge requests.
* Consider utilizing a shared Slack channel to collaborate, adding the customers to our slack via "one Slack channel access requests".  [Example](https://gitlab.com/gitlab-com/team-member-epics/access-requests/-/issues/16192)
* In meetings, tell customers why we like to record them and ask if they are OK with doing so. Consider using [Chorus](/handbook/sales/field-operations/sales-operations/go-to-market/chorus/) for scheduling the recordings to address legal requirements for recording meetings with customers.
* In meetings, tell customers why we take notes before, during, and after the meeting, as it may not be natural for them to collaborate in this way.
* Make sure the appropriate priority label is applied to all issues being tracked by the customer.
* In the agenda for recurring meetings, track the items tracked by the customer in priority order at the top and review the status, next steps, customer DRI, and GitLab DRI for each.  Discuss in the meeting periodically.
Remind GitLab team members in Slack to update the status of items they are the DRI for before recurring meetings.
* Post a link to the meeting notes and recording in a Slack channel for the customer escalation, so those who did not attend know that the notes and recording are available for review.
* When there is an action item for someone in a meeting (whether they are present or not), tag them in an issue or MR (or in Slack) so they will see it.

## FY24 Team Building "Fun" Budget

### Overview of the budget

As part of the [FY24 team building budget](/handbook/finance/expenses/#team-building-budget) available to each division, Engineering is allowing team members and teams to self-organize and propose team building events to use the budget.
Development teams may apply to use the budget for team building events.

The budget limit per team member in FY24 is $500 and a team member must be part of an approved application to submit expenses related to a team building event.

### Examples of how it may be used

The team building budget may be used for a variety of activities, including but not limited to:

- [In-person meetups](/handbook/leadership/in-person/) with teammates and other department team members. Note that the budget is limited and may not cover the full cost of travel and lodging.
- Expensing a meal for a virtual team event.
- Credits for team members to buy GitLab swag.
- Coordinating a social event with team members who are already attending a conference.

### What it is not intended for
- Conference registration and travel. These should be applied for separately using the Growth and Development benefit application process.

### Application Process

- Create an issue in your team's issue tracker or [the Team Member Socials issue tracker](https://gitlab.com/gitlab-com/gitlab-team-member-socials/-/issues) containing the following details:
    - Event/Usage description
    - Event date
    - Quarter when expenses will bu submitted. This can be different from the quarter in which the event will take place.
    - Number of team members attending
    - Total amount requested in USD.
- Ask your stage or sub-department leader to add the issue details to the FY24 Fun Budget Application Google Spreadsheet and ping the VP Development for approval.
- Once approval is granted or denied, the stage/sub-department leader will update the spreadsheet with the status and inform the team members who applied.

## Common Links

* [Development department board](https://gitlab.com/gitlab-com/www-gitlab-com/-/boards/1008667?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Development%20Department)
* [Current OKR's](https://gitlab.com/gitlab-com/www-gitlab-com/-/boards/1008667?scope=all&utf8=✓&state=opened&label_name[]=Development%20Department&label_name[]=OKR)
* Slack channel #expansion-development
* [Manager Notes](/handbook/engineering/development/managers/)

View page source - Edit this page - please contribute.