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.
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.
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.
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.
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.
We will follow our parent department Engineering lead.
The development team is responsible for developing products in the following categories:
The following people are permanent members of the Development Department:
The following members of other functional teams are our stable counterparts:
| Person | Role |
|---|---|
| Kalyani Yerraguntla | Learning & Development Program Manager |
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:
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:
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:
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:
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 guidelines specific for the Expansion Development Department is documented in this handbook page.
In this handbook page we document the process that the development departments follow, including planning budget, candidate sourcing, interview process, contracting and onboarding.
Welcome to GitLab! We are excited for you to join us. Here are some curated resources to get you started:
The quad members (UX/Design, Quality, Product Management, Development) utilizing this process should focus on:
As long as the quad achieves these goals, they are encouraged to apply the process as appropriate based any unique characteristics of their group and also tailor the process based on how the team prefers to operate.
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 type::feature, type::maintenance, and type:bug work. When labeling if the label selection for an issue or merge request isn't obvious, don't spend more than 60 seconds to decide and make a best effort to choose the most appropriate label.
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 accurateliy labeled.
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:
type::feature issuestype::maintenance issuestype::bug issues using the bug prioritization dashboardNote: 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.
The Product Manager is responsible for planning each milestone. Product Managers are also responsible for ensuring that their team's target ratios are maintained over time.
Add the milestone (example) to review the milestone plan. The board will show the number of issues and cumulative issue weights for type::feature, type::maintenance, and type::bug issues.
Cross-functional reviews will be done at the group, stage/section, and company level.
When the data is up-to-date and accurate. See the timeline
Review the dashboard filtered for the review scope (group, section, etc).
Context:
Maintenance/quality:
Features:
Trends:
The review collaboration can be done in a way that's most effective for the group, either synchronously (e.g. scheduled recurring call) or asynchronously (e.g. such as in retrospective issues).
Required collaborators from the quad for the group are:
The managers of the required collaborators should be included as optional participants.
The stage/section review is coordinated by each direct report of the VP of Development.
Required collaborators from the quad for the stage/section are:
Optional collaborators who should be invited but not required to participate:
The collaboration should be async first but include an optional sync review amongst stakeholders.
The name of the meeting and associated agenda document should be clearly defined so that the invitees can decide if they should attend.
The company-wide review is coordinated by the VP of Development.
Required collaborators from the quad for the stage/section are:
Optional collaborators who should be invited but not required to participate:
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.
At times when cross-functional, or cross-departmental architectural collaboration is needed, the GitLab Architecture Evolution Workflow should be followed.
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.
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.
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.
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.
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.
In general, OKRs flow top-down and align to the company and upper level organization goals.
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.
Below are tips for developing individual's OKRs:
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:
We will hold Engineering Allocation Checkpoints on a cadence. The recommended cadence is weekly.
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).
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.
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.
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.
The shared services and components below are extracted from the GitLab product documentation.
| Service or Component | Sub-Component | Ownership Model | DRI (Centralized Only) | Ownership Group (Centralized Only) | Additional Notes |
|---|---|---|---|---|---|
| Alertmanager | Centralized with Specific Team | @twk3 | Distribution | Distribution team is responsible for packaging and upgrading versions. Functional issues can be directed to the vendor. | |
| Certmanager | Centralized with Specific Team | @twk3 | Distribution | Distribution team is responsible for packaging and upgrading versions. Functional issues can be directed to the vendor. | |
| Consul | |||||
| Container Registry | Centralized with Specific Team | @dcroft | Package | ||
| Email - Inbound | |||||
| Email - Outbound | |||||
| GitLab K8S Agent | Centralized with Specific Team | @nicholasklick | Configure | ||
| GitLab Pages | Centralized with Specific Team | @johnhope | Knowledge | ||
| GitLab Rails | Decentralized | DRI for each controller is determined by the feature category specified in the class. app/controllers and ee/app/controllers | |||
| GitLab Shell | Centralized with Specific Team | @sean_carroll | Create:Source Code | Reference | |
| HAproxy | Centralized with Specific Team | @amoter | Infrastructure | ||
| Jaeger | Centralized with Specific Team | @dawsmith | Infrastructure:Observability | Observability team made the initial implementation/deployment. | |
| LFS | Centralized with Specific Team | @sean_carroll | Create:Source Code | ||
| Logrotate | Centralized with Specific Team | @twk3 | Distribution | Distribution team is responsible for packaging and upgrading versions. Functional issues can be directed to the vendor. | |
| Mattermost | Centralized with Specific Team | @twk3 | Distribution | Distribution team is responsible for packaging and upgrading versions. Functional issues can be directed to the vendor. | |
| MinIO | Decentralized | Some issues can be broken down into group-specific issues. Some issues may need more work identifying user or developer impact in order to find a DRI. | |||
| NGINX | Centralized with Specific Team | @twk3 | Distribution | ||
| Object Storage | Centralized with Specific Team | @lmcandrew | Scalability::Frameworks | ||
| Patroni | General except Geo secondary clusters | Centralized with Specific Team | @twk3 | Distribution | |
| Geo secondary standby clusters | Centralized with Specific Team | @juan-silva | Geo | ||
| PgBouncer | Centralized with Specific Team | @twk3 | Distribution | ||
| PostgreSQL | PostgreSQL Framework and Tooling | Centralized with Specific Team | @alexives | Database | Specific to the development portion of PostgreSQL, such as the fundamental architecture, testing utilities, and other productivity tooling |
| GitLab Product Features | Decentralized | Examples like feature specific schema changes and/or performance tuning, etc. | |||
| Prometheus | Decentralized | Each group maintains their own metrics. | |||
| Puma | Centralized with Specific Team | @pjphillips | Cloud Connector | ||
| Redis | Decentralized | DRI is similar to Sidekiq which is determined by the feature category specified in the class. app/workers and ee/app/workers | |||
| Sentry | Decentralized | DRI is similar to GitLab Rails which is determined by the feature category specified in the class. app/controllers and ee/app/controllers | |||
| Sidekiq | Decentralized | DRI for each worker is determined by the feature category specified in the class. app/workers and ee/app/workers | |||
| Workhorse | Centralized with Specific Team | @sean_carroll | Create:Source Code |
For a list of resources and information on our GitLab Learn channel for Development, consult this page.
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.
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:
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:
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.
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:
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:
Some areas have already been identified that meet the definition above, and may consider altered approaches in their work:
| Area | Reason | Special workflows (if any) |
|---|---|---|
| Database migrations, tooling, complex queries, metrics | impact to entire application The database is a critical component where any severe degradation or outage leads to an S1 incident. |
Documentation |
| Sidekiq changes (adding or removing workers, renaming queues, changing arguments, changing profile of work required) | impact to multiple services Sidekiq shards run groups of workers based on their profile of work, eg memory-bound. If a worker fails poorly, it has the potential to halt all work on that shard. |
Documentation |
| Redis changes | impact to multiple services Redis instances are responsible for sets of data that are not grouped by feature category. If one set of data is misconfigured, that Redis instance may fail. |
|
| Package product areas | high percentage of traffic share | |
| Gitaly product areas | high percentage of traffic share | |
| Create: Source Code product areas | high percentage of traffic share. Special attention should be paid to Protected Branches, CODEOWNERS, MR Approvals, Git LFS, Workhorse and the git over SSH / gitlab-sshd interfaces. Please contact the EM (@sean_carroll) or PM (@tlinz) if you are unsure. | |
| Pipeline Execution product areas | high percentage of traffic share | Documentation |
| Authentication and Authorization product areas | touch multiple areas of the application | Documentation |
| Compliance product areas | potentially have legal, security, or compliance consequences | Code Review Documentation |
| Workspace product areas | touch multiple areas of the application | Documentation |
| Specific fulfillment product areas | potentially impact revenue | |
| Runtime language updates | impacts to multiple services | Ruby Upgrade Guidelines |
| Application framework updates | impacts to multiple services | Rails Upgrade Guidelines |
| Navigation | impact to entire application | Proposing a change that impacts navigation |
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:
| Team | Stake |
|—————————————————————————————————————————————————————-| — |
| Create:IDE | Owns the WebIDE (maintainers) |
| Editor Extensions | Maintains the GitLab Workflow VS Code Extension (maintainers), Jetbrains, Neovim, Visual Studio extensions and the language server. Also contributes with UX improvements for Code Suggestions within GitLab Workflow. |
| Enablement:Cloud Connector (@mkaeppler, @nmilojevic1) | AI-Assissted for Self-Managed |
| AI Framework | GitLab Chat / Abstraction Layer and GitLab Chat for VSCode and WebIDE|
| Create:Code Creation | Code Suggestions |
| AI Model Validation Group | Suggested Reviewer, Code Suggestions AI Gateway functionality, Evaluating and tuning ML Models |
| Infrastructure | Code Suggestions AI Gateway scalability |
ClickHouse usage by Monitor:Observability group
If development is the DRI or actively participating in a Customer Account Escalation, consider the following:
As part of the FY24 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.
The team building budget may be used for a variety of activities, including but not limited to: