You can see who reports to whom on our organizational chart.
|Level||Example(s)||Peer group / shorthand for peer group|
|Board member||Chief Executive Officer||Board|
|Executive||Chief People Officer and VP of Engineering||Executives / E-group|
|Senior Leader||Senior Director or VP of Global Channels||Senior leaders / S-group|
|Director||Director of Engineering||Directors / D-group|
|Manager||Engineering Manager||Managers / M-group|
|Individual contributor (IC)||Staff Developer||ICs|
GitLab Inc. has at most six layers in the company structure (IC, Manager, Director, Senior Leadership, Executives, Board). You can skip layers but you can never have someone reporting to the same layer since that creates too many layers in the organization. The CEO is the only person who is part of two levels: the board and the executives.
The executive layer is structured as follows. There are two primary processes, product (product management, engineering, alliances) and go-to market (marketing and sales). Some companies have a Chief Product Officer (CPO) for the former and a Chief Operating Officer (COO) for the latter. We have a flatter organization. The C-level exec for product is the CEO and the VP's of Product management, Engineering, and Alliances report to the CEO. Marketing and sales have separate C-level execs. The two enabling functions, finance and people, also each have a C-level executive, the Chief Financial Officer (CFO) and Chief Culture Officer (CCO).
In product (product management, engineering, alliances) a VP is an executive, in other functions a VP is a senior leader. This aligns with the industry convention that in sales a VP is a senior leader and a VP of engineering commonly is an executive.
In product (product management, engineering, alliances) a senior leader has a senior director title, in other functions the title of a senior director can be either VP or senior director. They are all members of our S-group.
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.
A group is any arrangement of people that is not reflected directly in our org structure.
E-group is the portion of our CEO's direct reports who are executives. 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.
L-group are the people attending a regular leadership meeting to work on hard questions handed down from the E-Group. It is composed of part of the senior leaders (S-group) and directors (D-group), and will rotate membership at times throughout the year. It should be an adequate representation of company. It is a leadership development opportunity (secondary benefit, but not primary selection criterium)
For example, we have a Product Manager, Product Marketing Manager, Engineering Manager, Content Marketer, Backend Developers, Frontend Developers, and UX 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.
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.
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.
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 "Test Automation Engineer, Create" specializes in the "Create" stage group and is dedicated to that group. The 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 the majority of work in any role applies to both ways of delivery GitLab, self-managed and .com.
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.
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. When you refer to the community excluding the people working for the company please use: wider community. If refer to both people at the company and outside of it use community or GitLabbers.
Team is reserved for the smallest group. It is defined by a manager and their reports. Confusingly we also refer to all the people working for the company as team-members. Normally you would refer to this as employees but our team-members also include a lot of contractors. Do not refer to team-members as Gitlabbers since this refers to the whole community.