Organizational Structure

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

Layers

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

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 internal GitLab team members 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 that 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 understand the skills required for higher levels within the organization. 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:
  • Job frameworks should be leveraged in the Talent Assessment program for both the self-assessment and the manager assessment in evaluating a team member against the competencies for their grade level. In a review of the competencies per level, strengths and development opportunities may surface which can help with content for the review that can lead to discussions with the team member and their manager on future development and career opportunities.
• Succession Planning:
  • We leveral Job Frameworks in Succession planning as we assess requirements for each role level.

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 ranges from low/moderate complexity and problem solving to highly 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.
• High Performing Teams: Each characteristic of high performance is broken into 3 indicators to help you recognize and measure success.
• 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 team members should 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.

VP-Directs

VP-Directs are a subset of GitLab VPs who report directly to a member of E-Group. They are members of the VP-Directs Group.

Executives

The executive layer is structured as follows. R&D focused executives include the Chief Product Officer (CPO), Chief Information Security Officer (CISO) 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:

1. Ensuring team members feel included and valued is one of the most important tasks of a manager. Proactively create psychological safety with your team members so that diverse perspectives can be heard and everyone can communicate and contribute authentically and creatively.
2. Ensuring team members understand what is expected of them in their roles is a critical role that managers have to ensure company success. Managers should ensure job families include specific performance indicators and that is clearly communicated to each team member.
3. Managing underperformance is another important task of a manager.
4. When times are great, be a voice of moderation. When times are bad, be a voice of hope. In order to effectively be the voice of hope, managers should make sure they understand the company mission, goals, and leadership decisions. If managers have concerns about leadership decisions, they should voice them to leaders in order to understand the context, share key insights from their team members to ensure we make sound decisions, and then be able to explain context to their team members.
5. To maintain an effective organization, a manager’s span of control should be around 7 people, ranging anywhere from 4 to 10. Below this range the inefficiency of an extra organizational layer is larger than the benefit of a specialized group. Above this range, the manager doesn’t have time to do proper 1:1s anymore.
6. The span of control is the same at every level of the organization. This prevents the organization from having an additional layer that adds cost and reduces decision making speed. To increase the number of reports you can handle increase delegation to the directly responsible individual who can be a manager. Size the number of reports on where you expect the organization to be in 6 months from now.
7. When you praise someone, try to do it publicly and in front of an audience. When you give suggestions to improve, do it privately 1 on 1. A Harvard study has shown that the ideal ratio of positive to negative feedback for high-performing teams is nearly 6:1. Be generous with your positive feedback.
8. Express gratitude in team meetings, group conversations, and other communications to people who constructively challenge your opinions and ask difficult questions. This helps create psychological safety, promote our values, and prevent the five dysfunctions.
9. Understand that there are different ways to get to the same goal. There are different perspectives, and discussions need to happen.
10. When someone says they are considering quitting, drop everything and listen to them. Ask questions to find out what their concerns are. If you delay, the person will not feel valued and the decision will be irreversible.
11. In addition to announcing new team member arrivals, departures are also announced in the #team-member-updates chat 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.
12. People should not be given a raise or a title because they ask for it or threaten to quit. We should pro-actively give raises and promote people without people asking. If you do it when people ask, you are being unfair to people that don’t ask and you’ll end up with many more people asking.
13. Don’t refer to GitLab as a family. It is great that our team feels like a close-knit group and we should encourage that, as this builds a stronger team. But families and teams are different. Families come together for the relationship and do what is critical to retain it. Teams are assembled for the task and do what is required to complete it. Don’t put the relationship above the task. Besides, families don’t have an offboarding process. Families should have unconditional love, while teams have conditional love. The best companies are supporters of families.. The idea that your team is your family can lead to unwarranted pressure: “this office is like a family… in that there is vague pressure to be here on holidays”. You are the CEO of your own career, treat GitLab as a customer.
14. Praise and credit the work of your reports to the rest of the company, never present it as your own. This and many other great lessons can be found in an Ask MetaFilter thread worth reading.
15. Try to be aware of your cognitive biases.
16. Combine consistency and agility.
17. Consider maintaining a README file for your teams which documents your expectations and working style. Encourage MRs to it.
18. Although our time scales are shorter, there is a great article about how to think about PIPs.
19. Do everything to unblock people. If someone has a question that is keeping them from being productive, try to answer the question yourself or find someone who can.
20. Communicate in a professional manner as though your words will be shared widely (e.g. published in a newspaper).
21. Employ multimodal communication to broadcast important decisions.
22. You are expected to respond on social media. If you have questions, please seek counsel in the #social_media chat channel.
23. Make sure your reports experience a sense of progress in their work.
24. A tweet by Sam Altman combined with a reply by Paul Graham says it best: “People either get shit done or they don’t. And it’s easy to be tricked because they can be smart but never actually do anything.” Watch for results instead of articulate answers to questions, otherwise you’ll take too much time identifying under-performers.
25. GitLab Contribute (formerly GitLab summits) is meant for informal communication and bonding across the company. There is a limited time for business activities during GitLab Contribute so all our regular meetings should happen outside of it. We want informal, cross team, and open-ended meetings that include individual contributors. For example, inviting everyone to suggest currently missing functionality in GitLab.
26. Never delay a decision until GitLab Contribute. Instead, use them as a deadline to get things done earlier.
27. We don’t have explicit 20% time at GitLab. We measure results and not hours. If people are getting good results in the work that is assigned to them they are free to contribute to other parts of the company or work on a pet project. Don’t say, “Your work on that pet project is hurting your performance.” Instead, say, “We agreed to get X done but it is delayed, what happened and how can I help?”
28. Pick a metric before launching something new. 9 out of 10 launches fail. If a project is not working out shut it down completely. Starving a team of headcount to have it die a slow death is not frugal nor motivating. Fund the winners which will still take years to break even.
29. Do not discuss raises in advance because the salary calculator may change before the amount of the raise is decided.
30. Do not discuss promotions, salary increases, or bonuses until the changes have gone through the entire approval process. People Ops will inform the manager when they can inform the team member of the promotion and increase.
31. Instead of prescribing a direction to your reports, it is best to ask questions following the Socratic method until you’re happy with the direction. Your reports will have deeper knowledge in a more narrow area, so it is easy to draw different conclusions because they base theirs on different data. That is why the questions are so important.
32. Follow Berkshire’s common injunction: “Always tell us the bad news promptly. It is only the good news that can wait.” Make sure to inform your manager of bad news as quickly as possible. Promptly reporting bad news is essential to preserving the trust that is needed to recover from it.
33. Try to avoid military analogies and imagery. We’re not an army, we’re not at war, there is no battle, we’re not killing anyone, and we don’t have weapons. Military language is not inclusive and can lead to zero sum thinking. We take competing and winning very seriously, but there is no need to describe things using vocabulary of physical violence. Similarly, non-collaborative and aggressive terms like “rock star” and “badass” put up walls between people. If a term is standard in the industry, for example killing a Unix process, it is acceptable to use it because that is more efficient. Do use “primary-secondary” instead of “master-slave” for replication mechanisms.
34. Complain up and explain down. Raise concerns you hear to your manager. When peers or reports complain, explain why a decision was made. If you don’t understand why, ask your manager.
35. Create empathy for decisions from other leaders that negatively impact your team by explaining the reasons behind them. Organize a recorded AMA session with your team and the other leaders and encourage your team (as well as yourself) to ask any unanswered questions. Lead by example by ensuring that the discussion exposes what is best for the organization as a whole. Never present yourself as protecting the team from the rest of the organization; this creates a siege mentality and hinders collaboration.
36. Coach team members to establish good remote work practices, by encouraging asynchronous communication, being handbook-first, communicating poor audio or video quality, or pointing out an open microphone.
37. Ensuring that GitLab’s policies are upheld is an essential part of a manager’s responsibility. Managers have an obligation to look out for both their team members and the business’s best interest. If a manager becomes aware that a team member is in violation of a GitLab policy (including but not limited to the GitLab Code of Business Conduct and Ethics and Relocation policy as examples), it is their responsibility to communicate this to the aligned People Business Partner or Legal team immediately.

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 occasionally 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

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

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 Office of the CEO is responsible for organizing and orienting this group in collaboration with the cohorts E-Group Sponsor.

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 within their teams and functions. This would include cascading to peers on their functional leadership team.

Directs-Group Responsibilities

1. Attend portions of and contribute in designated meetings with E-Group and E-Group Offsites
2. Participate in onboarding, offboarding, regularly scheduled 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
5. Contribute to the cohort project

Directs-Group Selection Process

1. The Office of 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 performing 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
5. Include someone who is based outside of the United States

Directs-Group leadership

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:

1. Get agreement between E-Group and Directs-Group on key deliverables
2. Ensure that the group functions well
3. Be an official member of the incoming cohort
4. Help ramp up the incoming cohort
5. Coordinate incoming team activities and deliverables
6. Serve as a cohort representative with E-Group
7. Ensure that the group, in collaboration with the E-Group sponsor, achieves success in at least one cohort project

This person will be selected based on:

1. Their demonstrated ability to lead a cross-functional leadership team
2. Ability to make this additional time commitment

Directs-Group Timing

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.

E-Group Sponsor for Directs-Group

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.

Directs-Group Participants

Past, present and future Directs-Group Participants will be listed here.

Term	Directs-Group Cohort Members
2022-01 to 2022-10	Urja Patel, Matt Taylor, Rob Allen, 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)

Cohort project

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.

Cohort Projects:

1. 2022-01 to 2022-10 : Stop Initiative, Internal Handbook updates
2. 2022-11 to 2023-08 : Strategic plan refresh

VP-Directs Group

VP-Directs Group is largely made up of VP-Directs, VPs who report directly to members of E-Group. This is a senior group of leaders who are able to assist in the cascading of critical communications, support change management, ensure our mission & vision continues to be thoroughly understood at all levels of the organization, support in top priority cross-functional activities, and act as a gauge of company sentiment & engagement. In cases in which a function has 0-2 VP-Directs, an E-Group member may nominate 1 or 2 additional people from within the function to help represent the function.

VP-Directs Group Objectives

Through monthly meetings and a Slack channel, this group will be engaged to:

1. Cascade information: E-Group has a specific message that the organization needs to absorb and understand and senior leaders can help in communicating the message. This is particularly important when heavy change management is required for a specific issue or challenge and E-Group needs broader leadership support. We’d ask this group to absorb it and drive the change through their organizations.
2. Provide information and share perspectives: This group can be a senior sounding board as decisions are made or actions are being taken. For example, this group could be engaged when E-Group has identified a need for a strategic organizational pivot and broader senior level input is desired.
3. Provide cross-functional initiative leadership: E-Group may ask this group to take on specific cross-functional initiatives. For example, this group could play a role in addressing feedback from the Employee Engagement Survey (alongside all functional leaders) or support strategic planning activities.
4. Hear from customers: We’ll invite customers to speak to this group, so we can, as a leadership group, understand their perspective on GitLab and our challenges and opportunities and continue to drive customer-centricity throughout the organization.

VP-Directs Group Commitment

1. Participate in monthly meeting, synchronously when possible (recorded meeting, if appropriate)
2. Monitor the Slack channel
3. Share input on proposals and plan
4. Reach out to program managers with any ideas on what should be discussed or how to improve group effectiveness

VP-Directs Group Management

Initial management will include:

1. Rotating E-Group sponsor: formal E-Group representative
2. The Chief of Staff to the CEO: owns E-Group interlock, partners with sponsor
3. VP of Talent and Engagement: Owns team engagement and partners with VP of Global communications on internal communications. VP of Global communications owns broader communication where necessary. This initial management team will be responsible for getting the group up and running and starting to establish rigor & routine. We can iterate from this model as we better understand this The management team will:
4. Coordinate with the EBA team to ensure that invite series are sent and established
5. Ensure appropriate actions are noted and followed up on, hold accountability where necessary
6. Serve as an intersection between E-Group and VP Group to ensure that meetings have a clear purpose, information is being effectively shared, and group goals are being met

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 further 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 might instead have a performance tooling group.

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.

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, Workday 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 Workday. 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 asynchronously 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 yield 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 gradually 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.

Sponsorship

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 co-founder
• 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 mutually 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, 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.

“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:

1. We don’t use the term “employees” because we have many contractors working for GitLab Inc.
2. “Staff” appears on our user profile if we work for GitLab Inc., but this is confusing because it’s also an engineering level.
3. “Gitlabbers” is no longer used, because it isn’t inclusive of the wider community.
4. We considered calling team members “Tanuki” (referring to our logo), but it is confusing to refer to humans with an animal species.

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.