Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Organizational Structure

On this page

Organizational chart

You can see who reports to whom on our organizational chart.


Level Example(s) Peer group / shorthand for peer group
CEO Chief Executive Officer n/a
Executive Chief People Officer and Chief Technology Officer Executives / E-group
Senior Leader Senior Director or VP of Global Channels Senior leaders / S-group
Director Director of Engineering Directors / D-group
Senior Manager Senior Manager TBD
Manager Engineering Manager Managers / M-group
Individual contributor (IC) Staff Developer ICs

GitLab Inc. has at most seven layers in the company structure (IC, Manager, Senior Manager, Director, Senior Leadership, Executives, CEO). You can skip layers but you can never have someone reporting to the same layer, except from Manager to Senior Manager, since that creates too many layers in the organization.


Individual Contributor

Individual contributors are Managers of One. Along with the E-group, S-group, Director Group, and Management Group, ICs make up the GitLab team members.


Managers and Senior Managers are people managers. They belong to the Management Group.

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


Directors are managers of managers. They make up the Director Group.

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:

  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.
  1. Provides leadership and department/teams direction through senior managers, managers, and/or Fellow/Distinguished or staff individual contributors

  2. Contributes to the development of product or department and/or divisional strategy
  3. Typically part of the divisional leadership function and manages other teams or departments
  1. Directs the resolution of highly complex or unusual business problems that impact the department / team or GitLab
  2. Uses boring solutions to think beyond existing challenges
Decision Making
  1. Guided by divisional strategy, decisions impact overall success of department, team or GitLab operations
  2. Contributions result in the development of innovative GitLab services or products
  3. Makes sound decisions that support the strategy
  4. Ability to align the day to day execution to divisional OKR's
  5. Responsible for communicating top objectives and strategies to team members
Influencing ability
  1. Negotiates and influences the opinions and decision making of internal senior leaders on matters of significance to the division
  2. Guides process improvement and manages the rate and impact of change
  3. Adapts plan in response to changing objectives
  4. Promotes ideas persuasively, shaping others' opinions, and working through conflicts to win/win solutions
  1. Provides direction and develops long- range plans that affect a major area of GitLab
  2. Communicates division strategy and makes sound decisions that support the strategy
  3. Projects credibility and poise even in highly visible or adversarial situation, demonstrating professionalism and passion
  4. Develops and leverages a high performance workforce to create a competitive advantage
Business Expertise
  1. Uses financial information to make sound budgeting decisions
Functional Knowledge
  1. To be completed by Org Leader for each level
Values Alignment
  1. Demonstrates Values & Ethics, including the Code of Conduct in personal behavior

  2. Lives by GitLab values and holds other to the same standard
  3. Creates a culture of personal investment, excellence and accountability
  4. Builds and deploys teams that leverage individual and collective capabilities
  5. Actively sees out and invites alternative viewpoints in planning, discussion and decision making.
Remote Working
  1. Demonstrates all aspects of working remotely in personal behavior i.e. Manager of 1, Working Async, Well Written Artifacts, Handbook First, Single Source of Truth, Producing Videos

Senior leaders

The title of a senior leader can be either VP or Senior Director. They are all members of our S-group.


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:

  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.

Senior Director

  1. Provides leadership and department/teams direction through directors and/or senior managers

  2. Accountable for establishing quarterly OKR's for ensuring the performance and results of one or more teams
  3. Develops and executes department strategy to achieve key OKRs
  1. Anticipates factors that could impact GitLab strategies and its position in the marketplace
  2. Identifies and resolves strategic and GitLab wide problems or issues by developing new or innovative solutions
  3. Consistently works with abstract ideas or situations across areas of the business, assessing variables, evaluating fundamental issues, and providing direction for major departments or teams
Decision Making
  1. Decisions have a long-term effect on GitLab success
  2. Plays a key role in corporate development of methods, techniques and evaluation criteria for projects, programs and people
Influencing ability
  1. Regularly interacts with executives and/or major customers
  2. Interactions frequently involved highly visible activities such as speaking with customers, influencing other executives and represents GitLab on matter of importance to the organization
  3. Continuously improving processes
  4. Champions change and reinvents business practices or processes
  1. Provides strategy, vision and direction regarding issues that may have GitLab wide impact
  2. Inspires managers to build and develop capabilities in others to meet our OKR's
  3. Links strategy, priorities, team members, and assets to drive work efforts ahead and produce desired results
  4. They ambitiously define roles for, grow and hire their teams for what is needed from the business in the short term and needed in the future
Business Expertise
  1. Uses financial information to keep organization on budget and focused on right business priorities
Functional Knowledge
  1. To be completed by Org Leader for each level
Values Alignment
  1. Demonstrates Values & Ethics, including the Code of Conduct in personal behavior

  2. Creates environment to encourage team member engagement
  3. Develops leaders
  4. Builds trust with other with others by demonstrating respect, valuing people and creating transparency
Remote Working
  1. Demonstrates all aspects of working remotely in personal behavior i.e. Manager of 1, Working Async, Well Written Artifacts, Handbook First, Single Source of Truth, Producing Videos


  1. Sets vision and direction through resource allocation decisions for a significant department
  2. Senior leader responsible for multiple departments and teams
  3. Develops and implements strategic plans and objectives for the department in alignment with GitLab strategy; oversees direction and approves tactical administrative or operational policies and resource allocation decisions to ensure achievement of objectives
  1. Develops strategic plans to ensure successful implementation of action plans and objectives where analysis of situations or data requires and in depth knowledge of GitLab, competitive environment and department finances
  2. Participates in the development of GitLab processes that impacts product, programs and team members
  3. Typically approves budgets and schedules to meet GitLab goals
  4. Entails setting clear direction and priorities for cross-departmental teams, creating a shared purpose and objective and keeping teams focused on one vision
Decision Making
  1. Erroneous decisions will have a serious impact on the overall success of long-term GitLab operations
  2. Demonstrates personal accountability and ownership for decisions, results, and consequences. Holding others accountable to agreed upon expectations by instilling discipline and a strong focus on executions and results
Influencing ability
  1. Negotiates and influences opinions and decision making at the senior leadership level (internally and externally) on extremely critical matters, influencing policy making and changing the thinking of others on broad and complex issues that may fall outside of the organization function or function
  2. Regularly interacts with executives and/or major customers
  3. Interactions frequently involve highly visible activities such as speaking to or negotiating with customers, influencing other executives and represents GitLab on matter of great significance to the organization
  1. Leads change that maximizes results in their department and across GitLab
  2. Displays drive and purpose
  3. Open minded and flexible in thought and tactics
  4. Develops a clear sense of mission, purpose, and long-term direction for the department and teams. Helping team members understand why the desired outcomes are important
  5. Develops and implements distinctive strategies to achieve competitive advantage, aligning departments to support strategic priorities
  6. Sizes up and resourcefully responds to changing market conditions, new business challenges and new opportunities
Business Expertise
  1. Uses financial indicators and analysis to manage overall financial performance and evaluate business opportunities
  2. Deep understanding of organizational design for different phases of the organization
Functional Knowledge
  1. To be completed by Org Leader for each level
Values Alignment
  1. Demonstrates Values & Ethics, including the Code of Conduct in personal behavior

  2. Role models all GitLab values
  3. Models the development of a diverse an inclusive workforce and environment
  4. Actively works to increase diversity in the succession pool
Remote Working
  1. Demonstrates all aspects of working remotely in personal behavior i.e. Manager of 1, Working Async, Well Written Artifacts, Handbook First, Single Source of Truth, Producing Videos


The executive layer is structured as follows. R&D focused executives include the Chief Product Officer (CProdO) and the Chief Technology Officer (CTO). Go-to-market focused executives include the Chief Revenue Officer (CRO) and Chief Marketing Officer (CMO). The three enabling functions, legal, finance and people, also each have a C-level executive, the Chief Legal Officer (CLO), Chief Financial Officer (CFO) and Chief People Officer (CPO). Together, these executives consist of the E-group They meet weekly, attend quarterly board meetings, have a public Slack channel #e-group for most discussion topics, as well as a private one for rare confidential matters.

Except for Sales and Marketing, there are usually multiple executives to a cost center. For example, CLO, CFO, CEO, and CPO all fall under the G&A (General & Administrative Expenses) Cost Center.


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

  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.
  1. Typically part of the E-group
  2. Manages a GitLab Division
  3. Sets vision and direction through resource allocation decisions for departments where each is typically led by a VP
  4. Develops GitLab and/or divisional policies and authorizes their implementation.
  5. Detailed knowledge of GitLab allows for innovative concepts and promoting new ideas.
  6. Provides vision and direction to senior leaders and managers in various divisions, departments and/or teams.
  7. Recognized as an influential leader within and outside of GitLab.
  1. Consistently works with abstract ideas or situation across all areas of the business.
  2. Through assessment of intangible variables, identifies and evaluates core issues, providing strategy and direction for department and teams.
  3. Requires in-depth knowledge of the Division , business strategies, and GitLab's goals as well as external factors affecting governance of GitLab activities.
Decision Making
  1. Erroneous decisions may impact GitLab viability.
  2. Makes well-informed, effective, and timely decisions, even when data is limited or solutions produce unpleasant consequences; perceives the impact and implication of decisions.
Influencing ability
  1. Interacts internally and externally with executive level management or corporate leaders that requires negotiation skills on extremely critical matters.
  2. Influences long-term vision and strategy of corporate consequence.
  3. Works across organizational boundaries to build values and strategic partnerships
  4. Proactively detects communication problems in their division before they are observed by other divisions
  5. Frequently help achieve results outside their own division
  1. Takes a long-term view and builds a shared vision with others; acts as a catalyst for organizational change.
  2. Influences others to translate vision into action.
  3. Positions GitLab for future success by identifying new opportunities; builds the organization in a global environment.
  4. Holds self and others accountable for measurable, high-quality, timely, and cost-effective results.
  5. Identifies new business opportunities and makes them a reality, championing innovation and risk-taking.
  6. Gets a huge amount of things done by iterating quickly and training their departments / teams on iteration.
  7. Hires and retains leaders that perform better in the function than they do.
  8. Fosters a high standard of ethics and instills mutual trust and confidence.
Business Expertise
  1. Uses knowledge of external trends and the organization's competitive advantage, aligning the organization to support strategic priorities
Functional Knowledge
  1. Deep understanding of current and emerging technologies or methodologies in their division
  2. Demonstrated ability to attract, retain and grow our talent
  3. Ability to collaborate across all divisions effectively
  4. Respect of fellow experts in the same field
  5. Strong track record of emotional intelligence and soft skills (communication, leadership, developing others, inspiring others, conflict resolution, team building and decisiveness)
Values Alignment
  1. Demonstrates Values & Ethics, including the Code of Conduct in personal behavior

  2. Integrates GitLab Values into all parts of the division
  3. Champions a diverse and inclusive workforce and environment
Remote Working
  1. Demonstrates all aspects of working remotely in personal behavior i.e. Manager of 1, Working Async, Well Written Artifacts, Handbook First, Single Source of Truth, Producing Videos

Board Members

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


You may occassionally hear of the E-Group hosting an "All-Directs" call or meeting. The All-Directs group is made up of anyone who reports directly to the e-group. 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 all-directs meets after every e-group offsite.


Directs-Group is a group made up of a senior leader from each function. These leaders operate as extensions of E-Group and support key initiatives 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 in November and May to allow adequate time for Directs-Group identification and onboarding in advance of first E-Group Offsite.
  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 in the month before the start of the quarter 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. ⅓ of each cohort needs to be comprised of members from underrepresented groups

Directs-Group Timing

The cohorts roughly align with half years in GitLab's fiscal calendar (February to July and August to January). The first rotation starts in January and ends in June. The second starts in July and ends in December. These 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-06 | | | 2022-07 to 2022-12 | |

Organizational Structure

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:

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:

Note: It is not currently possible to select multiple specialty field values for team members who are stable counterparts across many groups. We are working on a solution.

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


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:

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.

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.


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


Specialists carry responsibility for a certain topic. They keep track of issues in this topic and/or spend the majority of their time there. Sometimes there is a lead in this topic that they report to. You can be a specialist in only one topic. The specialist description is a paragraph in the job description for a certain title. A specialist is listed after a title, for example: Developer, database specialist (do not shorten it to Developer, database). Many specialties represent stable counterparts. For instance, a "Software Engineer in Test, Create" specializes in the "Create" stage group and is dedicated to that group. If you can have multiple ones and/or if you don't spend the majority of your time there it is probably an expertise. Since a specialist has the same job description as others with the title they have the same career path and compensation.


Expert means you have above average experience with a certain topic. Commonly, you're expert in multiple topics after working at GitLab for some time. This helps people in the company to quickly find someone who knows more. Please add these labels to yourself and assign the merge request to your manager. An expertise is not listed in a role description, unlike a specialist.

For Production Engineers, a listing as "Expert" can also mean that the individual is actively embedded with another team. Following the period of being embedded, they are experts in the regular sense of the word described above.

Developers focused on Reliability and Production Readiness are named Reliability Expert.


Whereas an expert might assist you with an individual issue or problem, mentorship is about helping someone grow their career, functional skills, and/or soft skills. It's an investment in someone else's growth.

Some people think of expertise as hard skills (Ruby, International Employment Law, etc) rather than soft skills (managing through conflict, navigating career development in a sales organization, etc).

If you would like to be a mentor in a certain area, please add the information to the team page. It is important to note whether you would like to be a mentor internally and/or externally at GitLab. Examples of how to specify in the expertise section of the team page: Mentor - Marketing, Internal to GitLab or Mentor - Development (Ruby), External and Internal to GitLab. isn't a role

Some of the things we do make are specific, but we will not have 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 This is because 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:

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.

Wider community

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 referring to both people at the company and outside of it use community or GitLab team-members.

Team and team-members

Team is reserved for the smallest group. It is defined by a manager and their reports. It does not refer to a group or a department.

We refer to all the people working for the company as team-members. This is a bit confusing since team is reserved for the smallest group but it is preferable over all the alternatives we considered:

  1. Employees since we have many contractors working for GitLab Inc.
  2. GitLab team members since this should include the wider community.
  3. Incers (referring to GitLab Inc.) since it sounds dull.
  4. Staff is what is on our user profile if we work for GitLab Inc. but is also an engineering level.
  5. Tanuki (referring to our logo) since it is confusing to refer to humans with an animal species.
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license