1. You are here:
2. Meet the GitLab team
3. Organizational Structure

On this page

Introduction

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.

Organizational chart

You can see who reports to whom in the most up-to-date organization chart by logging into BambooHR, choosing the People section, and the Org Chart view. Our HRIS is the Single Source of Truth for team member and organizational information.

Layers

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).

Dual Career Path at GitLab

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.

Job Frameworks

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.

Goals of the Job Frameworks

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.

How to use Job Frameworks

We are using the Job Frameworks in the following programs:

• Promotion Process
  • Here the review of the Job Framework will be required ahead of the quarterly Department Promotion Calibrations.
  • The Job Framework will help provide focus for the promotion document to ensure core areas of performance at the next level are captured consistently across the company
• Career Development Conversations
  • Both managers and team members can leverage the frameworks in their conversations.
  • The frameworks drive transparency of the competencies and job criteria of different levels at GitLab. When aligned with the Career Development goals of the team member, the team member and manager can collaborate on developing these competencies by leveraging Learning & Development Programs
• Organizational Design and Headcount Planning
  • The frameworks will support Leadership and hiring teams in identifying the appropriate levels for to be opened roles.
  • For expanding and introducing new job levels we will leverage the frameworks to review what distinctive competencies are that we would need.
• Talent Assessment:
  • In the near future we will further build out how we can leverage Job frameworks in the Talent Assessment process.
• Succession Planning:
  • In the near future we will further build out how we can leverage Job frameworks in Succession planning.

Competencies per Job

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:

• Scope & Influence: The scope of the responsibilities and ways each job influences product, team members or company strategy.
  This ranges from focus on own work to cross company and external influence in terms of product, team members, customers or company strategy.
• Complexity & Problem solving: The level of complexity and problem solving skills in day-to-day responsibilities and projects.
  This is ranging from low/moderate complexity and problem solving to high complex issues that influence the accomplishment of long-term goals of GitLab.
• Leadership & People Management/Communication: The level of leadership they display and how they communicate within the organization. We expect that individual contributors also show leadership in their roles.
  This ranges from within their team to executives and board members.
• Values Competencies: Competencies that are aligned with our CREDIT Values.
• Remote Working Competencies: Competencies that are aligned with our Remote working competencies.
• Functional Competencies: Competencies that are specific per function. These are built out by each function themselves.

Besides the above competency categories we have added two categories to the Job Frameworks:

• Typical Reporting Structure: This shows the typical reporting structure for that Job level.
• Distinction with next level: This is a brief statement of what distinguishes one level from the next level.

Individual Contributor Job Framework

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.

People Managers Job Framework

You can find the Job Framework for People Managers in the tab here. Below we will describe each level and their reporting structure.

General Expectations of all People Managers

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

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

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.

Director

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.

Director group

Members of the director group are expected to demonstrate leadership in the way all members of the management group are, plus:

1. They have the ability to align the day-to-day execution to the top objectives of the company, and they are responsible for making sure the top objectives are well communicated to team members.
2. They work peer-to-peer and sponsor healthy conflict amongst the team to resolve issues quickly, escalating only when all options are exhausted.
3. They ambitiously define roles for, grow and hire their teams for what is needed from the business in the next 3-4 years.
4. They coach their teams to work within the communication guidelines and lead by example.

Senior Directors

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.

S-group

Members of the S-group are expected to demonstrate leadership in the way all members of the director group are, plus:

1. They have significant strategic and functional responsibility.
2. They have significant operating budget responsibility (things like compensation planning, budget allocation, negotiation, investment tradeoff decisions).
3. They have leverage and influence over the performance and success of large teams (both reporting directly and indirectly) and their success will result in increased success across large numbers of people.
4. The impact of their decisions are broad and significant.
5. Some of them have critical external responsibility to represent the company and make decisions and statements for which the company is accountable.

VP

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.

Executives

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.

E-group

Members of the E-group are expected to demonstrate leadership in the way all members of the S-group are, plus:

1. They suggest relevant, ambitious, and quantifiable OKRs and achieve 70% of them.
2. They are reliable and ensure their teams complete what they agreed to do.
3. They are proactive about detecting and communicating problems in their functions before other departments even notice them.
4. They hire and retain leaders that perform better in their functional areas.
5. They create roles and set requirements for what is needed 3-4 years out and hire for that profile.
6. They get a huge amount of things done by iterating quickly and training their department in iteration.
7. They define and communicate the business strategy and vision, instead of being overly tactical in the business.
8. They share insights about other functional areas that make others better at their job.
9. They suggest and implement improvements to our cross-functional processes.
10. They frequently help achieve results outside their function.
11. They make other executives better in their discipline

Management group

Members of the management group are expected to demonstrate leadership in the way all GitLab team members are, plus:

Board Members

Board Members serve on the GitLab board and participate in board meetings and board committees, as well as other responsibilities.

CEO Skips

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.
This group is called on to help provide input and communicate messaging when appropriate.
As an example, the CEO Skips meets after every e-group offsite.

Directs-Group

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 and cascading communications within a six month rotation. The CoST to the CEO is responsible for organizing and orienting this group.

Directs-Group Program Objectives

1. Give greater exposure to E-Group and E-Group decision making to develop leaders with C-level potential
2. Enlist a larger group of people to help drive and inform key initiatives
3. Support cascade of information from E-Group to the rest of GitLab

Directs-Group Responsibilities

1. Attend portions of and contribute in E-Group Weekly meetings and E-Group Offsites
2. Participate in onboarding, offboarding, monthly Directs-Group syncs, professional development programming, and ramping of the next cohort
3. Support communication cascading and initiative support resulting from your engagement in Directs-Group
4. Serve in this role while managing existing responsibilities

Directs-Group Selection Process

1. The CoST to the CEO kicks off the selection process three months in advance of every cohort end date to allow adequate time for Directs-Group identification and onboarding in advance of first E-Group Offsite and appropriate transition from one Directs group to another.
2. Each E-Group member identifies first and second choice candidates. E-Group will discuss if TMRG criteria is not met within first choice candidate selections.
3. Candidates will be identified and notified at least 45 days before the start of the new cohort in which they would serve in the role.
4. If a candidate declines their nomination, the function leader can nominate a new candidate for consideration.

Directs-Group Selection Criteria

Each Directs-Group cohort must meet the following criteria:

1. High growth and high performance team members in good standing
2. Director + who are direct reports to an E-Group member
3. Folks who consistently demonstrate CREDIT Values
4. ⅓ or more of each cohort needs to be comprised of members from underrepresented groups

Directs-Group Timing

The cohorts span nine months aligning with three quarters in GitLab’s fiscal calendar. Specific start dates are timed to align with E-Group Offsites.

Directs-Group Participants

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
TBD

2023-09 to 2023-06
TBD

Organizational Structure

• Divisions: the area under one executive. e.g. the Engineering division.
• Departments: lead by Directors or VPs and comprise multiple teams or sub-departments e.g. the Infrastructure department within the Engineering division
• Sub-departments: lead by Directors or Senior Managers and comprised of multiple teams e.g. the Enablement Sub-department within the Development department
• Compartments: lead by Senior Managers and comprised of multiple teams where the Sub-department structure is already used e.g. the Manage Compartment with the Dev Sub-department
• Teams: constitute departments and are made of a line manager and their direct reports e.g. the Security operations team within the Security Department

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.

Organized by Output

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.

Division
Output

Marketing
Generate Pipeline

Sales
Close Pipeline

Product
Prioritize development

Engineering
Execute development

People
Enable people

Finance
Ensure correctness

Legal
Ensure compliance

Product Groups

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:

• Primary Stable Counterparts – Team members assigned to our Product hierarchy (typically groups) from Product, Development, Product Design and Quality functions which we call the Quad.
• Complete Stable Counterparts – All team members assigned to product hierarchy from functions outside of the primary functions and defined in our product categories page. For example – we assign stable counterparts from Support, Product Marketing and Customer Success who are all considered part of the complete stable counterparts.

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:

1. We don’t have an internationalization group.
   That responsibility is shared across many groups.
   We might instead have an internationalization tooling group.
2. We don’t have a performance group.
   Ensuring GitLab is performant is the responsibility of all groups.
   We do have the Memory group and Database group whose charters involve consulting and providing guidance for other teams, but should be considered non-blocking.

The Memory group focused on the specifics of reducing GitLab’s memory footprint, creating documentation and tooling to assist in memory related concerns.

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.

Product Group health Assessment

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.

Building High Performing Product Groups Learning Session

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.

Setting Product Group for Team Members

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:

• A team member who is a stable counterpart in the Code Review group in the Create stage would have the specialty designation of Create:Code Review
• A team member who is a stable counterpart to the entire Verify stage would have a specialty designation of Verify
• A team member who is a stable counterpart to the Access and Import groups in the Manage stage, and the Gitaly group in the Create stage would have specialty designations of Manage:Access, Manage:Import, and Create:Gitaly.

Single-Engineer Groups

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:

1. There are lots of decisions to be made, which happen more effectively in a single brain.
2. There is not enough code for multiple people to work on without running into merge conflicts.
3. Starting work earlier allows for more time for other people to contribute. We need to have a head start many years ahead of commercialization.

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.

Success criteria

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

• Chief Product Officer
• CTO
• CEO

Selection

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:

• The engineer must be a senior engineer (or above)
• They must be passionate about the subject matter
• They must be excited about the ability to work independently, or have prior success in a similar model
• Being a prior company technical cofounder
• Being an early contributor to a successful open source project
• Working successfully on a prior single-engineer group

No Stable counterparts

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.

• Inadvertently asking other team members to contribute when they have their full-time responsibilities in their home group can lead to burnout and more investment than single-engineer groups are modeled to invest.
• Engineer losing the freedom because other stable counterparts may insist on more rigor around problem validation and/or solution validation.

Example for creating a Single-engineer group

The MR describes an example of how to create a single-engineer group.

Working Groups

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 Management

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.

Roles

People can be a specialist in one thing and be an expert in multiple things. These are listed on the team page.

Specialist

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

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.

Mentor

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.

GitLab.com isn’t a role

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.

1. We have a functionally organized company, the functions need to as mutally exclusive as possible to be efficient, .com overlaps with a small part of many functions.
2. Having .com specific people will increase the pressure to get to two codebases, that can be a big hindrance: “splitting development between two codebases and having one for cloud and one for on-prem is what doomed them”, and “they split cloud and on-prem early on and it was a 10-year headache with the OP folks feeling left in line to jump in the pool but never could. While cloud pushed daily/weekly with ease, OP was easily 6-mo behind leaving customers frustrated”
3. The reasons .com customers churned were all things that occur in both self-managed and .com
4. Improvements we can make in user growth might be informed by .com specific data but can be implemented for both delivery mechanisms.

Exception: Product Management Senior Leader

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:

• Growth Group: Stages per User (SpU)
• Pricing: Tiers
• Infrastructure Department: Cloud spend (within limits, not cost per user)
• Development Department: Prioritization of large enterprise features

Other Considerations

The word “Manager” in a title doesn’t imply people management or structure

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, tài khoản manager, channel sales manager, technical tài khoản 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.

“Team”, “team member”, and “community” terminology

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.