Diversity, Inclusion & Belonging

Diversity, Inclusion & Belonging at GitLab

Diversity, Inclusion & Belonging is fundamental to the success of GitLab. We include it in every way possible and in all that we do. We strive for a transparent environment where all globally dispersed voices are heard and welcomed. We strive for an environment where people can show up as their full selves each day and can contribute to their best ability. And with over 100,000 organizations utilizing GitLab across the globe, we strive for a team that is representative of our users.

Diversity complements our other values, specifically Collaboration, Efficiency and Results. And diversity in our leadership supports innovation, promotes better decision making and improves financial results.

GitLab’s Diversity Inclusion and Belonging Mission

• Mission: At GitLab, we believe everyone can contribute and the Diversity Inclusion and Belonging Team are building scalable strategies based on our acronym, A.D.A.P.T. which stands for Action, Doing Good in the communities we serve, holding ourselves Accountable and creating equitable Policies in a Transparent environment. We are focused on helping to build high performing, customer centric teams by expanding, establishing, embedding our DIB (/handbook/values/#diversity-inclusion). Just as DIB is a journey, our acronym, A.D.A.P.T. mirrors the agility required throughout that journey.
• Action - Action puts intentionality into how we attract, progress and retain our team members as well as engage with our customers and the open source community.
• Do Good - We “Do Good” by providing avenues for GitLab & team members to meaningfully contribute to our community and society.
• Accountable - We hold ourselves Accountable in the commitments we make as well as being Answerable for the outcome.
• Policies - We build scalable Policies to govern our work and actionable processes which inform our program development and execution.
• Transparent - Transparency is the T in our GitLab CREDIT values and how we operate within DIB ensuring that our internal efforts are reflected externally.

GitLab’s Diversity, Inclusion & Belonging Vision

Vision: The Diversity Inclusion and Belonging value empowers everyone to contribute.

GitLab’s definition of Diversity, Inclusion & Belonging

The phrase “Diversity, Inclusion & Belonging” (or DIB) refers to the terminology for the initiative to create a diverse workforce and an environment where everyone can be their full selves.

Diversity refers to characteristics of the people who make up GitLab and how they identify. Race, gender, age, ethnicity, religion, national origin, disability, sexual orientation are some examples of how the data might be categorized when looking at GitLab’s diversity. Sometimes we can see things that make us diverse and sometimes we can’t. We believe that a company composed of a diverse group of people may lead to diverse opinions and ideas which, if productively engaged with, can build innovation.

GitLab uses the term “underrepresented” and it is meant to be a way of recognizing that we need more of what we do not have so that we can be at our best.

The context is “at GitLab” or “in a specific department or team at GitLab.” This term is generally used in the context of reporting on how GitLab is working on understanding and improving the sourcing, interviewing, hiring, and retention of those who either want to work or currently work at GitLab. Institutes like the National Science Foundation use the word “underrepresented” when discussing research around diversity so we have chosen to use it as well in order to be able to set goals around the data we have and understand where we need to work harder.

• A single person should not be referred to as a “diverse person” or a “diversity hire” which would imply they are not included in the current community or that they are only employed because of a factor that is not directly related to their skills and their ability to do their job.
• People should not be singled out or “othered” by labels with cold terminology in personal interactions.

For additional information about how GitLab uses this data to make progress, please see “select underrepresented group”

Inclusion is the ability to recognize, respect, and value differences in those around us. It focuses on the action and understanding of what makes us diverse and working towards building a diverse team and creating welcoming workplace. It requires skills such as empathy, openness, listening, etc. This lays the foundation of an inclusive mindset. The foundation of understanding gives way to the actions and being intentional about creating policies and practices that embrace diversity that in the end change the overall company culture to create an environment of inclusion. Inclusion also means being aware of both positive and negative biases and how those biases impact who we hire, work with, and retain.

GitLab believes that many perspectives coming together creates a more innovative environment to work in with more satisfied teammates, leading to a better product and increased profitability.

Belonging is a feeling that your insights and contributions are valued. It goes back to team members feeling they can bring their full selves to work. It’s not enough to simply include people to have a “seat at the table”, but it’s important to amplify everyone’s voices, remove barriers and appreciate each others for their unique backgrounds. Embracing inclusion may increase the sense of belonging. Team members become more engaged and are invested in the work they are doing, because they are able to see themselves in the work being accomplished with the company overall.

We believe in empowering team members to get their work done efficiently and collaboratively by establishing clear DRIs for all our work. DRIs do not owe anyone an explanation for their decisions, but DRIs can still acknowledge input by closing an issue and marking it Won't Do or commenting on an issue acknowledging that they have read all the comments.

All team members don’t have to agree on the best course of action- we can disagree, commit, and disagree- but everyone can contribute and it is on the DRI to acknowledge those. Some other ways we actively cultivate a sense of Belonging at GitLab include creating and cultivating allies, welcoming family members in the background of a call, and sharing negative feedback in 1-1 settings.

A good way to look at Diversity, Inclusion & Belonging is:

• Diversity
  • diversity dimensions/layers that make people who they are
  • knowing the layers and having a seat at the table
• Inclusion
  • having a voice
  • feeling empowered to use your voice
• Belonging
  • acknowledgment of your voice being heard
  • the feeling of being a part of something
  • creating an environment where team members feel secure to be themselves

Examples of Select Underrepresented Groups

An underrepresented group describes a subset of a population that holds a smaller percentage within a significant subgroup than the subset holds in the general population. The accepted definition of “underrepresented minorities” from the National Science Foundation and other major research institutions focuses on racial and ethnic groups whose representation in a profession is significantly below their representation in the general population. Populations whose representation in tech roles has been historically low. Tech roles are based on Federal Employer Information Report EEO-1 skill designations. At GitLab, this includes all technical roles across the company, such as Engineering & Product.

At GitLab, we consider the following groups to be underrepresented groups:

• Women - Globally
• Women in Management - Globally
• Women in Senior Leadership - Globally
• Black/African American - United States
• Black/African American in Management - United States
• Black/African American in Senior Leadership - United States
• Hispanic/Latino - United States
• Hispanic/Latino in Management - United States
• Hispanic/Latino in Senior Leadership - United States
• Indigenous Peoples/Alaska Native - United States
• Indigenous Peoples/Alaska Native in Management - United States
• Indigenous Peoples/Alaska Native in Senior Leadership - United States
• Hawaiian/Pacific Islander - United States
• Hawaiian/Pacific Islander in Management - United States
• Hawaiian/Pacific Islander in Senior Leadership - United States

**Due to data and or legal limitations, this is not an exhaustive list of all of our underrepresented groups. Those with disabilities, those that identify as LGBTQIA+, those who choose not to disclose as well as underrepresented ethnicities outside of the US, etc.

The DIB Team is actively working on finding data sets outside the US and inclusion metrics for underrepresented groups we cannot report on as team member representation.

Of Note: Management refers to Team Members who are People Managers, whereas Leadership denotes Team Members who are in Director-level positions and above.

Source: GitLab’s People Analytics Team, WorkDay

Diversity, Inclusion and Belonging Team

• Liam McNally - Manager, Diversity, Inclusion and Belonging
• Sherida McMullan - Vice President, Diversity, Inclusion and Belonging

Request Needed or Want to Learn More?

• Have a request for DIB support? Open an issue here.
• Stay updated via our slack channel - #diversity_inclusion_and_belonging
• Have questions or suggestions for diversity, inclusion and belonging? Please email diversityinclusion@gitlab.com
• Monthly DIB Initiatives Company Call. This call will allow time for GitLab team members to gain an understanding of what we are doing with DIB here at GitLab. It is the second Wednesday of every month. If you aren’t able to attend live calls, and would like to listen in on past calls, you can do so here with our DIB playlist. You have to be logged into GitLab Unfiltered. If you are not sure how to log into GitLab Unfiltered, you can review how to here.

Values

Inclusive teams are naturally more engaged, collaborative and innovative. We aim to align our values to be reflective of our company wide commitment to fostering a diverse and inclusive environment.

In addition, the very nature of our company is to facilitate and foster inclusion. We believe in asynchronous communication, we allow flexible work hours. GitLab team members are encouraged to work when and where they are most comfortable.

Fully distributed and completely connected

The GitLab team is fully distributed across the globe, providing our team the opportunity to connect with each others cultures, celebrations and unique traditions. We collaborate professionally and connect personally!

Our unique all-remote team opens our door to everyone. Candidates are not limited by geography and we champion this approach, to the extent that it’s possible, for all companies!

By having no offices and allowing each GitLab team member to work and live where they are most comfortable, GitLab offers a uniquely inclusive culture.

• All-remote means that you will not sacrifice career advancement by working outside of the office, as even GitLab executives are fully remote.
• All-remote creates a workplace where caregivers, individuals with physical disabilities, etc. are not disadvantaged for being unable to regularly commute into an office.
• GitLab’s approach to Spending Company Money enables all team members to create a work environment uniquely tailored for them.
• All-remote enables those who must relocate frequently for family and personal reasons to take their career with them.
• All-remote allows movement and relocation to physical settings that contribute to an individual’s health (e.g. moving to a location with an improved air quality index).

Learn more about GitLab’s all-remote culture.

GitLab team member data

Please see our identity data.

What we are doing with Diversity, Inclusion & Belonging

Diversity Inclusion & Belonging Roundtables

A DIB roundtable is a great way to build deeper connections with team members and develop safe spaces to discuss DIB related issues. The DIB roundtable will ask team members to share stories and anecdotes as well as challenge team members to think about how they personally and collectively can positively impact DIB.

This page outlines the process of DIB Roundtables. These can be self-organized or organized by the DIB Team.

Talent Acquisition initiatives

This page provides an overview of our Diversity, Inclusion & Belonging Talent Acquisition initiatives.

Engineering Initiatives

This page provides an overview of our Diversity, Inclusion & Belonging Engineering initiatives

Sales Initiatives

This page provides and overview of Diversity, Inclusion and Belonging Initiatives within Sales

Sales Sponsorship Program

#IamRemarkable Workshop

#IamRemarkable is a workshop created by Google. The initiative aims to empower women and other underrepresented groups to celebrate their achievements in the workplace and beyond, and to challenge perceptions around self-promotion.

Logistics

At GitLab we launched the #IamRemarkable workshop in April 2021, and aim to continue with two workshops per quarter on an ongoing basis. Before the start of each quarter, a quarterly workshop planning issue will be opened where team members have the opportunity to volunteer to participate. Slots will be allocated on first come first serve basis.

Our pilot workshop was for team members who are a part of our Women’s TMRG. Our Q2 workshops will be open for any member of an underrepresented group, from Q3 moving forward, we will also have three slots/session for allies to attend the workshops.

The workshops are kept to a max of 15 team members to generate more comfort and psychological safety within the group, in addition to providing everyone with an opportunity to share and contribute to discussion. Each workshop is two hours in duration. Due to the personal nature of the workshop, we do not record #IamRemarkable sessions.

Facilitators

Currently, we have three GitLab team members who are certified to facilitate the #IamRemarkable workshop:

1. Giuliana Lucchesi
2. Terri Chu
3. Gosia Ksionek

In order to more efficiently scale this initiative at GitLab, we would love to have more facilitators join us! Anyone can register to become a facilitator. As soon as you have been certified, feel free to add your name to the list of facilitators above.

Stay Interviews or Team Member Experience Interviews

The stay interview with Black Team Members pilot program was developed as part of feedback from the Reverse AMA discussions with Sid. It was mentioned that “stay” interviews might be helpful in determining retention indicators for underrepresented groups.

Inclusive benefits

We list our Pregnancy & Maternity Care publicly so people don’t have to ask for them during interviews. In addition GitLab offers an Employee Assistance Program to all team members via Modern Health, a one-stop shop for all tools related to mental well-being and self-improvement.

Inclusive language

In our GitLab Values we list: ‘Use inclusive language. For example, prefer “Hi everybody” or “Hi people” to “Hi guys”. And speak about courage instead of aggression. Another example is to avoid terms like “gossip” that have negative gender connotations. Also see the note in the management section of the leadership page to avoid military analogies.

• For an additional resource, we also have a presentation on Inclusive Language

TMRGs - Team Member Resource Groups

We have created several TMRGs and welcome interest in creating new ones. Would you like to sign up for an Team Member Resource Group, start an TMRG, or just learn more? See our TMRG Guide.

Military veterans and spouses

GitLab welcomes military veterans from around the world, as well as military spouses, to learn more about life at GitLab and to apply for vacancies. We recognize the values gained from military experience, and we foster an inclusive atmosphere to thrive in when returning to civilian life.

Our all-remote culture provides an ideal work environment for military veterans and spouses. By empowering team members to live and work where they are most comfortable, veterans and spouses can work in a safe, nurturing environment that they choose and design.

We encourage military veterans and spouses to read testimonials from GitLab team members to understand the benefits of all-remote when joining the workforce following military service. We are committed to our Military Leave policy.

GitLab is actively iterating within Diversity, Inclusion & Belonging and Talent Acquisition to ensure that additional underrepresented groups are pursued, embraced, and positioned for success.

Disability Inclusion

GitLab welcomes all types of team members, including any that may choose to identify as ones that currently have or were previously diagnosed as having a disability. In our HRIS (Human Resource Information System) Workday, on the Job tab page, in the Equal Employment Opportunity section, we have a field titled Disability Status that we ask our team members to complete during the onboarding process. The reason we ask is because it is a legal requirement in the United States for us to request this information. We encourage GitLab team members to self-disclose in our HRIS without any fear of judgment or negative consequences, even if you are not in the United States, but it is always optional. All disability data is completely confidential, and only requested for mandatory reporting purposes.

The options of this field are:

• Yes, I have or previously had a disability
• No, I do not have a disability
• Prefer Not to Answer

If you are unsure how to answer, please review our Individual with Disabilities Policy.

At GitLab, we are proud to make reasonable accommodations to the known disability of a team member. Please review the reasonable accommodation handbook section if you need a reasonable accommodation due to your disability. Find more information on GitLab Inc’s Individuals with Disabilities policy.

Related Disability Legislation

• United Nations Convention on the Rights of Persons with Disabilities (CRPD)
• Global Disability Legislation

United States Veteran Inclusion

The United States Office of Federal Contract Compliance Programs (OFCCP) enforces the affirmative action provisions of the Vietnam Era Veterans’ Readjustment Assistance Act of 1974. This law, sometimes referred to as VEVRAA, requires employers doing business with the United States Federal Government (such as our GitLab Federal entity) to take steps to recruit, hire and promote protected veterans. It also makes it illegal to discriminate against protected veterans when making employment decisions on hiring, firing, pay, benefits, job assignments, promotions, layoffs, training, and other employment-related activities. Under VEVRAA, a veteran who served on active duty in the U.S. military and was discharged or release from service under conditions other than dishonorable may be classified as one or more of the four Protected Veteran categories:

• Disabled Veteran A veteran who served on active duty in the U.S. military and is entitled to disability compensation (or who but for the receipt of military retired pay would be entitled to disability compensation) under laws administered by the Secretary of Veterans Affairs, or was discharged or released from active duty because of a service-connected disability.
• Recently Separated Veteran A veteran separated during the three-year period beginning on the date of the veteran’s discharge or release from active duty in the U.S. military.
• Armed Forces Service Medal Veteran A veteran who, while serving on active duty in the U.S. military, participated in a U.S. military operation that received an Armed Forces service medal.
• Other Protected Veteran (listed in Workday as Active Duty Wartime or Campaign Badge Veteran) A veteran who served on active duty in the U.S. military during a war, or in a campaign or expedition for which a campaign badge was authorized under the laws administered by the Department of Defense.

In our HRIS (Human Resource Information System) Workday, on the Job tab page, in the Equal Employment Opportunity section, we have a field titled Protected Veteran Status that we ask our US-based team members to complete during the onboarding process. The reason we ask is because it is a legal requirement in the United States for us to request this information. We encourage GitLab team members to self-disclose in our HRIS without any fear of judgment or negative consequences, but it is always optional. All veteran status data is completely confidential, and only requested for mandatory reporting purposes.

The options of this field are:

• Yes, I am a US Veteran with a Protected Status
• Not Applicable
• Prefer Not to Answer

Above this field, we have a section titled Veteran Status that we ask our US-based team members to review and also complete during the onboarding process, if it applies to them and if they so wish. The reason we ask is because it is a legal requirement in the United States for us to request and document this information. We encourage our US-based GitLab team members to self-disclose their Veteran Status in our HRIS without any fear of judgment or negative consequences, but it is always optional. Again, all veteran status data is completely confidential, and only requested for mandatory reporting purposes.

If you are a team member on a GitLab Inc or Federal contract and a disabled veteran you may request a “reasonable accommodation.” A reasonable accommodation is one that allows you to perform your job, and must be provided by GitLab unless doing so would cause GitLab significant difficulty or expense. A reasonable accommodation does not change essential job functions. GitLab can choose the type of reasonable accommodation that will be made available; however, the accommodation must be effective. More information on how to request a reasonable accommodation is available here. Please review the reasonable accommodation handbook section if you would like an accommodation due to your veteran status.

Diversity, Inclusion & Belonging Learning & Development

• We have a variety of trainings on GitLab University including
  • DIB @ GitLab
  • Neurodiversity in the Workplace
  • Digital Accessibility
  • With many others to increase your knowledge on DIB Subjects
• Live Inclusion training
• Live Ally training
• Delivering Through Diversity McKinsey and Company research on Diversity and its value. To earn badges and save your responses, you’ll need to sign up! Use your GitLab address to sign in using Google+.
• To be truly inclusive is to be aware of your biases as well as strategies for stopping the effects of those biases. As part of our efforts, we recommend everyone to partake in the Harvard project Implicit test which focuses on the hidden causes of everyday discrimination.

Process for learning material and course creators

Team members who might use this process include: DIB and L&D team members, managers creating training for their teams, departments creating required compliance training, team members creating training for their peers or community, Developer Relations creating training for the wider GitLab community

1. When a new training is created or curated open up an issue using the following template. It is best to open this issue as soon as you’ve begun building out the learning material* so that the DIB and L&D team can provide early guidance
2. Assign the issue to a DIB Team Member and a L&D team member - the assignees must not be someone who participated in creating or curating the training
3. The assignees will go through the content of the training and complete the QA process as outlined in the issue.
4. The content creator and assignees will use the issue to collaborate on and document improvements made to the content that align with quality check list above
5. When all 3 participants agree that the course has met our inclusion and learning standards, close the issue and proceed with adding the materials or course to GitLab Learn

Community

GitLab team members are distributed across the globe, giving us access to an array of opportunity. We encourage collaboration with global organizations and programs that support underrepresented individuals in the tech industry. GitLab also provides additional support through the GitLab Diversity Sponsorship program. We offer funds to help support the event financially, and if the event is in a city we have a GitLab team member, we get hands-on by offering to coach and/or give a talk whenever possible.

We encourage organizers of events that are supported through our GitLab Diversity Sponsorship program to share this sign up link with attendees. Everyone can contribute.

Definitions

• Gender and Sexual Orientation Identity Definitions and FAQ
• Leadership is defined as director and above.
• Geographically is defined as those countries we use in our identity data.
• Women is the term GitLab uses instead of “Female”. “Female/Male” are gender terms often designated at birth. “Woman/Man” are gender terms based on self-identification. At GitLab, we define women based on how team members self-identify their gender in Workday.
• Privilege is an unearned advantage given by society to some people but not all. In the USA figures were released in 2009 that on average women were paid $0.78 for every $1 a man makes. These figures have improved but there is still a gender imbalance.
• Race - As we work to be inclusive and equitable in opportunities, promotions, etc throughout GitLab, it is imperative that we understand our representation. We want to do our best in having categories for race that team members can select where they are able to in some way identify with the options available. Below are the categories GitLab uses with expanded options for each:
  • American Indian or Alaska Native - A person having origins in any of the original peoples of North and South America (including Central America) and who maintains tribal affiliation or community attachment. This category includes people who indicate their race as American Indian, Alaska Native, Navajo, Blackfeet, Inupiat, Yup’ik, Central American Indian groups or South American Indian groups.
  • Asian - A person having origins in any of the original peoples of the Far East, Southeast Asia, or the Indian subcontinent including but not limited to: Cambodia, China, India, Japan, Korea, Malaysia, Pakistan, the Philippine Islands, Thailand, and Vietnam. This includes people who indicate their race as Asian Indian, Chinese, Filipino, Korean, Japanese, Vietnamese and or other not mentioned Asian identifies.
  • Black - A person having origins in any of the Black racial groups of Africa. Including people who indicate their race as Black or African American, Cape Coloreds, Carribean, Kenyan, Nigerian, or Haitian.
  • Hispanic or LatinX - A person of Cuban, Mexican, Puerto Rican, South or Central American, or other Spanish culture or origin, regardless of race. The term, “Spanish origin”, can be used in addition to “Hispanic or Latino”. Although not of Spanish-origin, Brazil is also included in this category due its inclusion in the LatinX definition.
  • Native Hawaiian or Other Pacific Islander - A person having origins in any of the original people of Hawaii, Guam, Samoa, or other Pacific Islands. Included but not limited to people who reported their race as Fijian, Guamanian, Chamorro, Marshallese, Native Hawaiian, Samoan, Tongan or other Pacific Islander.
  • Multiracial - refers to two or more races as described in the listed categories.
  • White - A person having origins in any of the original people of Europe, the Middle East, or North Africa. Included but not limited to people who indicate their race as: White, Irish, German, Italian, Lebanese, Arab, Moroccan, or Caucasian.
• Ethnicity: Can be more broadly defined as “large groups of people classed according to common racial, national, tribal, religious, linguistic, or cultural origin or background.”
  • For example people who are Black/African Descent can have a variety of ethnicities such as African, African American, Afro-Caribbean, Afro-Latinx etc. Whilst physical characteristics can be similar there could be cultural differences.
• Underrepresented Group This can be defined as a group whose percentage of the population in a given group is lower than their percentage of the population of country, community, organization or otherwise.
  • An example of this at GitLab is: Women within Senior Leadership is still low compared to Men within Senior Leadership. Which meant that GitLab created the goal of 50% of all senior leadership should be women by December 2021 to address the imbalance within this underrepresented group.
• TMRG (Team Member Resource Group) - In other organizations, a TMRG can be an ERG (Employee Resource Group). TMRGs are voluntary, team member-led groups focused on fostering diversity, inclusion and belonging within GitLab. These groups help team members build stronger internal and external connections; offer social, educational, and outreach activities; create development opportunities for future leaders; and increase engagement among team members.
• Ally - A diversity, inclusion and belonging “ally” is someone who is willing to take action in support of another person, in order to remove barriers that impede that person from contributing their skills and talents in the workplace or community.
• Allyship - Is the state of being an ally, supporting or being a member of groups or associations of the people you are an ally too. An example of this is someone who does not identify as part of the LGBTQI+ community being a part of the TMRG and supporting the endeavors.
• Unconscious bias - Unconscious biases are stereotypes about certain groups of people that individuals form outside their own conscious awareness. Nearly all our thoughts and actions are influenced, at least in part, by unconscious impulses. There’s no reason bias should be out of scope. Categorizing people based on social and other characteristics is a powerful survival mechanism, as it helps to distinguish friends from foes and make quick “life or death” decisions based on “inner feeling”. At the same time this is a fertile ground for growing stereotypes, prejudice, discrimination.
• Psychological safety - is defined by Amy Edmondson as a “shared belief held by members of a team that the team is safe for interpersonal risk taking”. It’s not about being warm and fuzzy and sharing your feelings. It’s about being comfortable admitting when you are wrong or have made a mistake as well as challenging each other for the better.

Performance Indicators

When measuring diversity-focused performance indicators, we focus on top-of-funnel metrics, like pipeline, because they’re leading indicators which are better measures of where we are heading. It also helps reduce risk that we hire to the performance indicator, instead of hiring the best candidate.

Like all performance indicators, our Diversity Performance Indicators are on the People Success Performance Indicator Page.

View page source - Edit this page - please contribute.