On this page we plan to take you through the organizational structure, layers and Job Frameworks that build GitLab as a company. We are working with two Job Frameworks, one for Individual Contributors and one for People Managers. We aim to explain how we use those frameworks, other projects and further considerations in GitLab’s Organizational Structure.
You can see who reports to whom in the most up-to-date organization chart by logging into Workday, choosing the Profile section, and select Team from the left sidebar to view Org Chart. Our HRIS is the Single Source of Truth for team member and organizational information.
|Level (People Manager/IC)||Example(s)||Scope of impact||Expected Behaviors|
|CEO||Chief Executive Officer||GitLab Global Organization||Champions|
|Executive||Chief People Officer and Chief Technology Officer||Division||Champions|
|VP/Fellow||VP of Global Channels||Department(s)||Drives Change|
|Senior Director||Senior Director, Engineering||Sub-department(s)||Develops the framework and strategy|
|Director/ Distinguished||Director of Customer Success Operations||Sub-department/multiple teams||Drives the framework, strategy and plans|
|Senior Manager/Principal||Principal Engineer||Across Sub-departments||Fosters|
|Manager/Staff||Engineering Manager||Across Teams||Implements|
|Senior||Senior People Connect Specialist||Cross functional work||Models|
|Intermediate||Intermediate Backend Engineer||Work within team||Grows/Acts|
|Associate||Business Development Associate||Own work||Learns/Develops|
GitLab has at most eight layers in the company structure (Associate/Intermediate/Senior, Manager, Senior Manager, Director, Senior Director and/or VP, Executives, CEO). You can skip layers but you generally never have someone reporting to the same layer (Example of a VP reporting to a VP).
A dual career path is a career path that allows upward mobility for team members without requiring that they be placed into a People Manager position. This structure serves as a way to advance team members who have deep specialist/technical skills but who are either 1) not interested or inclined to pursue a People Manager position and rather work as an Individual Contributor (IC), or 2) there is not sufficient business need to add additional layers of people management into a team at this time. While today the dual-career path is most built out in our Engineering division, other divisions across the company have began to build these out as well where structure and business need permits. The fork between specialist/technical work and the People Manager track is generally above the Senior level. Once someone reaches a Senior-level role, and wants to progress, they will need to decide whether they want to remain purely specialist/technical or pursue a People Manager role. Their manager can provide opportunities to try tasks from both tracks if they wish. In most cases, the IC track and the people management path compensation bands align. Team members can review compensation details in our compensation calculator.
We’ve developed Job frameworks to provide clarity and consistency in our expectations for each job level at GitLab. There are two Job Frameworks: one for Individual Contributors and one for People Managers which are available to team members internal only, that map to the levels outlined in our job grades. If we make any updates to the frameworks we will always communicate that broadly. If you as a team member want to propose any changes we recommend for you to open a confidential issue in the People Business Partner project.
The Job frameworks will help team members understand the career level at which they're contributing and take ownership of their progression. Team members will also more easily see what skills are required of them at the next level in order to be ready to progress, when the business need supports the additional scope.
This guidance will better equip managers to have more productive conversations about performance expectations and career progression, enable them to support their team members in setting personal development goals and creating shared expectations, and ensure consistency in our expectations for different levels across the organization.
Having Job frameworks that managers and team members share will help us make things more transparent, consistent, actionable, and equitable. Departments leads can work with their People Business Partner to build out specific functional frameworks with job specific competencies beyond the general frameworks provided here.
We are using the Job Frameworks in the following programs:
For each Job Framework we have identified categories for describing competencies we expect to see at each level. Below we describe the definitions of each category:
Besides the above competency categories we have added two categories to the Job Frameworks:
Individual contributors are Managers of One. ICs make up the majority of the GitLab team members. The Job Framework for ICs is a high level guide that describes the minimum competencies we expect at each level of an IC. For exact requirements and responsibilities per level we refer to the Job Family page of each job.
You can find the Job Framework for People Managers in the tab here. Below we will describe each level and their reporting structure.
For all People Managers we have general expectations in behavior which we describe below. These are not captured in the Job Framework but rather can be used as a guide on how we expect people managers to behave and interact with their team/peers. The difference with the Job Framework is that it doesn’t describe high level competencies but rather sets very concrete expectations and GitLab basics.
Managers belong to the Management Group. You can view the Job Framework for expectations per competency category. Typically a Manager reports to a Senior Manager or Director.
Senior Managers belong to the Management Group. Furthermore you can view the Job Framework for expectations per competency category. Typically a Senior Manager reports to a Director or above.
Directors are typically managers of managers. They make up the Director Group. In some cost center, Directors map to departments. For example, under the G&A Division, Business Operations is a department led by a Director. This is not a hard-and-fast rule, though, as under G&A, People is all under one department. Members of the director group are expected to demonstrate leadership in the way all members of the management group are, plus the additional competencies you can find in the Job Framework. Typically a Director reports to a Senior Director or above.
Members of the director group are expected to demonstrate leadership in the way all members of the management group are, plus:
Senior leaders are defined as Senior Directors or VPs. They are all members of our S-group. Senior Directors are typically managers of Managers and/or Directors. In some divisions, senior leaders map to departments in the cost center structure. Members of the S-group are expected to demonstrate leadership in the way all members of the director group are, plus the additional competencies you can find in the Job Framework. Typically a Senior Director reports to a VP or above.
Members of the S-group are expected to demonstrate leadership in the way all members of the director group are, plus:
VP’s are members of our S-group. VP’s are typically managers of Senior Directors and/or Directors. Similar to Senior Directors they map to departments.
Typically a VP reports to an Executive.
The executive layer is structured as follows. R&D focused executives include the VP's of Product and the Chief Technology Officer (CTO). Go-to-market focused executives include the Chief Revenue Officer (CRO) and Chief Marketing Officer (CMO). The three enabling functions, legal, finance and people, also each have a C-level executive, the Chief Legal Officer (CLO), Chief Financial Officer (CFO) and Chief People Officer (CPO).
Together, these executives consist of the E-group They meet weekly, attend quarterly board meetings, have a public Slack channel #e-group for most discussion topics, as well as a private one for rare confidential matters.
Except for Sales and Marketing, there are usually multiple executives to a cost center. For example, CLO, CFO, CEO, and CPO all fall under the G&A (General & Administrative Expenses) Cost Center.
Members of the E-group are expected to demonstrate leadership in the way all members of the S-group are, plus:
Members of the management group are expected to demonstrate leadership in the way all GitLab team members are, plus:
#team-member-updateschat channel (but only after the Google/Slack accounts are revoked, see the offboarding page and the offboarding checklist for details). We must respect the privacy of the individual concerned. If you are asked why someone has left or is leaving, please refer that person to the general guidelines section of the handbook where we describe what can and cannot be shared.
Board Members serve on the GitLab board and participate in board meetings and board committees, as well as other responsibilities.
You may occassionally hear of the E-Group hosting an "CEO Skips" call or meeting. The CEO Skips group is made up of anyone who reports directly to the e-group. It also includes People Business Partners, Chief of Staffs, and internal communications. It is made up of some ICs, some managers, some directors, and some senior leaders.
Functional Leaders include all CEO Skips and a small number of other team members who are invited by E-Group members.
This group is called on to help provide input and communicate messaging when appropriate.
As an example, the Functional Leaders meets after every e-group offsite.
Directs-Group is a group made up of a senior leader from each function. These leaders operate as extensions of E-Group and support key initiatives within a six to nine month rotation. The CoST to the CEO is responsible for organizing and orienting this group in collaboration with the cohorts E-Group Sponsor.
Each Directs-Group cohort must meet the following criteria:
During the Directs-Group nomination process, E-Group will nominate a person to lead the cohort. Ideally this person comes from the previous cohort so they have experience. It is this person's responsibility to:
This person will be selected based on:
The cohorts span six to nine months aligning with two to three quarters in GitLab's fiscal calendar. Specific start dates are timed to align with E-Group Offsites.
Each cohort will have an E-Group sponsor for the duration of the cohort. This person will attend Directs-Group Meetings and serve as a formal link to the broader E-Group. This person will be a stable counterpart to the Directs-Group Leader. The E-Group sponsor and Directs-Group Leader will come from different functions. The Sponsor will also assist Directs-Group in identifying at least one area in which they can contribute as a cohort. During Directs-Group meetings, the Sponsor will check on initiative status and offer feedback.
Past, present and future Directs-Group Particpants will be listed here.
|Term||Directs-Group Cohort Members|
|2022-01 to 2022-10||Urja Patel, Matt Taylor, Rob Allen, David Hong, Melissa Smolenksy, Christopher Lefelhocz, Kenny Johnston, Justin Farris|
|2022-11 to 2023-08||Jim Gladen, Pattie Egan, Dave Steer, Hillary Benson, Eliran Mesika (cohort lead), Stan Hu, Christie Lenneville, Ryan O'Nell, Joaquin Fuentes, Sid Sijbrandij (E-Group Sponsor)|
|2023-08 to 2023-06||TBD|
Each Directs-Group will have at least one cohort project. Cohort projects should be cross-functional initiatives designed to improve GitLab in someway. At least one cohort project should be identified within the first month of the cohort. Selection should involve Directs-Group and the E-Group Sponsor. Cohorts can recommend project ideas for incoming cohorts.
Note - within the Engineering and Product divisions we try to maintain a close relationship between our organizational structure and our Product Hierarchy in order to maintain stable counterparts in our organizational structure.
Finance also has a notion called "departments" for financial planning purposes. But these do not align with our organizational departments. For instance the finance department "product development" rolls up both the PM and Engineering functions. But it excludes the Support department, which is part of the engineering function, but a different budget. This name collision should probably be resolved in the future. For futher reference see our department roll up structure for accounting purposes.
We try our best to keep our handbook and documentation up to date, but certain terms used in the past have been updated through time. The term Functional Group is no longer used, and it currently is encompassed by the term Departments. The term Functional Group leader is no longer used, and it is currently encompassed by the term E-group leaders.
In many ways, we are organized by output. This way we can ensure that responsibilities don't overlap. We also ensure every department has a clear priority.
Our engineering organization is directly aligned to groups as defined in product category hierarchy. Our groups operate on the principle of stable counterparts from multiple functions.
For example, we have a Product Manager, Product Marketing Manager, Engineering Manager, Content Marketer, Backend Developers, Frontend Developers, and Product Designers that are all dedicated to a group called "Package". Collectively, these individuals form the "Package group". The word "Package" appears in their titles as a specialty, and in some cases, their team name.
We distinguish between types of stable counterparts to these Product Groups with:
A group has no reporting lines because we don't want a matrix organization. Instead, we rely on stable counterparts to make a group function well. In some shared functions, like design, technical writing and quality individuals are paired to one or more stages so that there are stable counterparts.
While everyone can contribute, the scope of a group should be non-overlapping and not a required dependency for other groups to deliver value to users. This facilitates results, iteration and efficiency.
Internal platform groups (those focused on a non-user facing part of our product, like a set of internal APIs) tend to create heavy coordination costs on other groups which depend on platform improvements to deliver valuable features to users. In order to stay efficient, it is important to ensure each group is non-blocking and is able to deliver value to users directly. This is why we avoid internal platform groups.
It is also important to ensure a group doesn't have a scope definition that is shared across multiple groups. Here are two examples:
We do have the Application Performance group and Database group whose charters involve consulting and providing frameworks for other teams, but are considered non-blocking.
The Application Performance group is focused on identifying systemic performance bottlenecks, creating documentation, and tooling to assist other groups in understanding and improving the performance of their features.
The Database group is focused on the specifics of database management/scaling and to provide consulting for development teams in need of database development guidance. While database related merge requests still require approval from a database maintainer our database review process has necessarily scaled beyond just the members of the database team.
The ability to execute the product roadmaps is dependent on the health of the product groups. Rather than rely on intuition, forceful personalities, or other ad-hoc methods, there are frameworks, such as the Drexler-Sibbet model, for developing high-performance teams. Furthermore, team health can be measured and improvements made systematically. For example, the Spotify Health Check model is a lightweight method of visualizing what can be improved within a team.
The goal of product group health assessment is to enable groups to identify improvement areas. If they are used to gauge the relative "maturity" of the group, it creates a perverse incentive for groups to stack the results to make them look as good as possible. As a result, it is important that health assessments should not be used by management to compare and contrast product groups against each other. Instead, the leaders of the product group are the DRIs to manage assessments and iterate on improvement over time.
To get started, feel free to make a copy of the Team Health Survey Template and edit to suit your development group's needs.
The Learning & Development team can facilitate a live learning session with product groups to enable high performance. The Drexler-Sibbet model is a framework to lead teams through stages towards high performance. During the live learning session, a L&D facilitator will collaborate with a product group to define activities to align team members on what needs to occur to achieve high performance. If interested in scheduling a session, contact
#learninganddevelopment to learn more.
Because it is our single source of truth (SSOT) for employee data, BambooHR serves as the SSOT for product group assignment. Each team member in R&D functions (Product/Engineering) is assigned a
specialty field in their
team.yml entry. While this entry is editable in the www-gitlab-com project, any adjustments will be over-written by a daily sync from BambooHR. In order to adjust a team members specialty their manager must initiate a Job Information Change.
When designating a team members
specialty we use the smallest unit of our Product hierarchy and their designated names. So for example:
The goal of a Single-Engineer Group (SEG) is to initiate GitLab into a planned or minimal category within the GitLab project. The single-engineer group is not to invest in an existing viable or complete category. Here is a list of product ideas that are candidates for a SEG to work on.
At GitLab, we believe in the power of a single engineer to accomplish amazing feats. Many open source projects started with a single engineer’s decision to build around a problem they personally experienced. For instance, Continuous Integration by DZ and GitLab Runner by Kamil. We want to create room for this energy.
Our belief is that we can guarantee a higher rate of success by incubating ideas inside our larger organization and existing code base while limiting the negative aspects of friction that come from a larger organization. A few benefits of SEG include:
As a matter of process, we require that Single-engineer groups take part in our Software Demo Process as a way to collaborate asyncronously with stakeholders, get iterative feedback, and maintain at least minimal alignment with the rest of GitLab while keeping their autonomy
If the group finds great success, as measured by adoption, and needs to drive deeper category maturity then the next step is to consider forming a multi-person group. Sometimes the category is complete and the group can successfully dissolve. There are other times when the category does not yeild the adoption. We will gather the lessons learned and consider either dissolving the group or investing further based on the learnings.
We have a huge opportunity in front of us and we want to be ambitious. Therefore over time we want to invest 10% of our R&D to continue to pursue these. However, in the spirit of iteration, we will start with only a handful of Single-engineer groups. As we learn more, and we get more dollars to invest, we will gradualy add more SEGs.
The success of the Engineer relates to getting a rapid, high-quality answer to the question of product-market fit. That answer can absolutely be "no", so performance is not contingent on the group graduating to a larger, multi-person group. The measure of this is GMAU.
Anyone at GitLab can propose the creation of a single-engineer group.
The single-engineer group is prioritized just like any other new investment and needs to get approval from
If the SEG is in the Development Department, the VP of Development is responsible for deciding the reporting structure for the engineer while they are a single-engineer group.
Criteria for the engineer:
There are no stable counterparts for a single-engineer group. The best way to think of this is a community contribution. The selection criteria is setup to select engineers that can work independently without stable counterparts. This setup is to avoid the following undesirable side effects.
The MR describes an example of how to create a single-engineer group.
A working group is a specific type of group that assembles for a period of time to accomplish a business goal. Working groups have defined responsibilities and meet regularly. Ideally a working group can disband when the goal is complete to avoid accrued bureaucracy.
Middle managers are team members who do not report to the CEO and have managers of people reporting to them. It is not defined by someone's title or their place in the org chart, but by these two criteria.
People can be a specialist in one thing and be an expert in multiple things. These are listed on the team page.
Specialists carry responsibility for a certain topic. They keep track of issues in this topic and/or spend the majority of their time there. Sometimes there is a lead in this topic that they report to. You can be a specialist in only one topic. The specialist description is a paragraph in the job description for a certain title. A specialist is listed after a title, for example: Developer, database specialist (do not shorten it to Developer, database). Many specialties represent stable counterparts. For instance, a "Software Engineer in Test, Create" specializes in the "Create" stage group and is dedicated to that group. If you can have multiple ones and/or if you don't spend the majority of your time there it is probably an expertise. Since a specialist has the same job description as others with the title they have the same career path and compensation.
Expert means you have above average experience with a certain topic. Commonly, you're expert in multiple topics after working at GitLab for some time. This helps people in the company to quickly find someone who knows more. Please add these labels to yourself and assign the merge request to your manager. An expertise is not listed in a role description, unlike a specialist.
For Production Engineers, a listing as "Expert" can also mean that the individual is actively embedded with another team. Following the period of being embedded, they are experts in the regular sense of the word described above.
Developers focused on Reliability and Production Readiness are named Reliability Expert.
Whereas an expert might assist you with an individual issue or problem, mentorship is about helping someone grow their career, functional skills, and/or soft skills. It's an investment in someone else's growth.
Some people think of expertise as hard skills (Ruby, International Employment Law, etc) rather than soft skills (managing through conflict, navigating career development in a sales organization, etc).
If you would like to be a mentor in a certain area, please add the information to the team page. It is important to note whether you would like to be a mentor internally and/or externally at GitLab. Examples of how to specify in the expertise section of the team page:
Mentor - Marketing, Internal to GitLab or
Mentor - Development (Ruby), External and Internal to GitLab.
Some of the things we do make are GitLab.com specific, but we will not have GitLab.com specific people, meetings, or product KPIs. We want to optimize for IACV and customer success and .com is simply a way to deliver that. Our innovation and impact will slow down if we need to maintain two separate products and focus our energy on only one of them. The majority of work in any role applies to both ways of delivery GitLab, self-managed and .com.
We do have an exception to the above, which is a senior leader in Product Management that is responsible for the cross-functional outcomes needed on GitLab.com. This is because GitLab.com is a large operational expense, it's also potentially a large source of IACV, and because it's strategically important that we have a thriving SaaS offering as more of the world gets comfortable hosting their source code in the cloud.
Here are some examples of the things that this senior leader will coordinate:
Some of individual contributors (without any direct reports) have manager in their title without a comma after it. These titles are not considered a people manager in our company structure nor salary calculator, examples are product manager, accounting manager, account manager, channel sales manager, technical account manager, field marketing managers, online marketing manager, and product marketing manager. People with manager and then a comma are a people manager in our company structure.
The term "team" is reserved for the smallest group. A team is defined as a manager and their reports. "Team" does not refer to a group or department.
We refer to all the people working for the company as "team members". This is a bit confusing, given that "team" refers to a small group, but we believe "team member" is preferable over all the alternatives we considered:
GitLab is a project bigger than GitLab the company. It is really important that we see the community around GitLab as something that includes the people at the company. Therefore, when you use the term "community," you should be referring to all GitLab users and contributors - including team members.
To refer to users and contributors who are not team members, use "wider community."
For more, please see the GitLab writing guidelines.