GitLab Commit Virtual is here. Register Now for our 24 hour immersive DevOps experience.
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.

Layers

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

GitLab Inc. has at most six layers in the company structure (IC, Manager, Director, Senior Leadership, Executives, Board). You can skip layers but you can never have someone reporting to the same layer since that creates too many layers in the organization. The CEO is the only person who is part of two levels: the board and the executives.

Levels

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.

Manager

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

Director

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.
Scope
  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
Complexity
  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
Leadership
  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.

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

Scope
  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
Complexity
  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
Leadership
  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

VP

Scope
  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
Complexity
  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
Leadership
  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

Executives

The executive layer is structured as follows. There are two primary processes, product (product management, engineering) and go-to market (marketing and sales). Some companies have a Chief Product Officer (CPO) for the former and a Chief Operating Officer (COO) for the latter. We have a flatter organization. The C-level exec for product is the CEO and the EVPs of Product Management, Product Strategy, and Engineering report to the CEO. Marketing and sales have separate executives. 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.
Scope
  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.
Complexity
  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
Leadership
  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.

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.

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.

Working Groups

A working group is a specific type of group that assembles for a period of time to accomplish a business goal. Working groups have defined responsibilities and meet regularly. Ideally a working group can disband when the goal is complete to avoid accrued bureaucracy.

Middle Management

Middle managers are team members who do not report to the CEO and have managers of people reporting to them. It is not defined by someone's title or their place in the org chart, but by these two criteria.

Roles

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

Specialist

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

Expert

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

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

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

Mentor

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

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

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

GitLab.com isn't a role

Some of the things we do make are GitLab.com specific, but we will not have GitLab.com specific people, meetings, or product KPIs. We want to optimize for IACV and customer success and .com is simply a way to deliver that. Our innovation and impact will slow down if we need to maintain two separate products and focus our energy on only one of them. The majority of work in any role applies to both ways of delivery GitLab, self-managed and .com.

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

Exception: Product Management Senior Leader

We do have an exception to the above, which is a senior leader in Product Management that is responsible for the cross-functional outcomes needed on GitLab.com. This is because GitLab.com is a large operational expense, it's also potentially a large source of IACV, and because it's strategically important that we have a thriving SaaS offering as more of the world gets comfortable hosting their source code in the cloud.

Here are some examples of the things that this senior leader will coordinate:

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