In May of 2019, our team of 638 GitLab team-members from around the world had our annual company trip in New Orleans!
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.
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.
For additional information about how GitLab uses this data to make progress, please see our handbook page with more details.
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:
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.
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.
Learn more about GitLab's all-remote culture.
Please see our identity data.
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-organised or organised by the DIB Team.
#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.
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, and in Q3 we will have a workshop dedicated primarily for allies.
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.
Currently, we have two GitLab team members who are certified to facilitate the #IamRemarkable workshop:
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.
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.
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.
We launched our Global Diversity, Inclusion & Belonging Advisory Group - A team of company influencers who can be instrumental in driving DIB efforts from a global perspective. We are empowering team members with Team Member Resource Groups based on diversity dimensions
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.
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.
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) BambooHR, 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:
If you are unsure how to answer, per the Americans with Disabilities Act (ADA), a disability means, with respect to an individual: a physical or mental impairment that substantially limits one or more of the major life activities of such individual; a record of such an impairment; or being regarded as having such an impairment as described in Section 36.105, paragraph (f) of the ADA. So to clarify, you may have been or currently be diagnosed by a disability as per the ADA and not feel that it substantially limits your life activites and still self-identify as having a disability status.
Please find an overarching list of what can fall into the disability defition per the ADA, including:
And not all disabilities are obvious to the eye. These are known as invisible disabilities. An invisible disability is a physical, mental, or neurological condition that can’t be seen from the outside. But it can impact someone’s movements, senses, or activities, according to the Invisible Disabilities Association. Some examples of invisible disabilities include autism spectrum disorder, depression, diabetes, and learning and thinking differences such as ADHD and dyslexia. Invisible disabilities can also include symptoms such as chronic pain, fatigue, and dizziness.
GitLab values all team members for their strengths. We offer team members with disabilities — whether visible or invisible — an equal opportunity to succeed, to learn, to be compensated fairly, and to advance. True inclusion is about embracing differences. At GitLab, we are proud to make reasonable accommodations to the known disability of a team member. Please review the reasonale accommodation handbook section if you need a reasonable accommodation due to your disability. Find more information on GitLab Inc's Individuals with Disabilities policy.
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 threeyear 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 BambooHR 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) BambooHR, 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:
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.
In order to ensure that the training we provide is inclusive to all, we have a quality check process to ensure that all learning, development and training material and courses adhere to our Diversity, Inclusion, and Belonging Value.
The quality check will ensure that all materials and courses are:
|Required by all team members||Must completed DIB/L&D review before assigning|
|Required by some team members||Must completed DIB/L&D review before assigning|
|Not required||Highly suggested to complete DIB/L&D review process|
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, Community Relations creating training for the wider GitLab 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.
Community members from all backgrounds are encouraged to join our First Look UX research participant panel. Feedback from our community is what makes GitLab lovable and anyone is able to sign up to our research program for invites to usability tests, user interviews, surveys, and more.
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.