At GitLab, one of our objectives and key results (OKRs) for Q3 is for more than 95% of our recruiting outreach to be directed at candidates who identify with an underrepresented group.
As recruiters and hiring managers know, outreach is only one part of the recruiting puzzle. If we’re going to build a more diverse team, we need to ensure our entire hiring process sets each and every candidate up for success.
In the spirit of transparency and iteration, we’d like to share a few tactics our recruiting team is experimenting with across different parts of the hiring process. Each tactic aims to increase the diversity of the team and ensure candidates feel like they belong at GitLab.
Outbound only
The first and most important step we took was adopting an outbound-only recruiting model. With this model, we’re able to focus our recruiting team’s time on sourcing candidates who will both add to our team’s diversity and raise the bar once they’re on board.
We saw an average of 40,000 applications per month with our previous inbound model, and 99% of these applicants were rejected. Many hours were lost reviewing unqualified candidates and imbalances of representation in our funnel made it difficult to add to the team’s diversity.
We’ve been utilizing this outbound-only model since March 2020 and we’ve already seen a positive impact. Two stand-out examples come from August. We saw 60% of Sales candidates identity as non-male and 28% of Engineering candidates identify as Black. We’re encouraged by the signals we’re seeing so far and the outbound approach is here to stay.
Inclusive language review for our job families
Moving to an outbound-only approach meant we no longer needed our traditional job adverts. It also gave us an opportunity to iterate on our job family pages. At GitLab, job families simply outlined a role’s responsibilities. Now, we’ve repurposed those pages to be more of a marketing tool for the role and work at GitLab.
One of our top priorities in iterating on these job family pages was to improve the inclusivity of the language we use. We’re incredibly fortunate to have our People Ops Engineer, Lien, who built a tool to help us do this.
Using GitLab CI (our Continuous Integration tool), each job family was assessed for its use of gendered language, misused words, and bias towards growth-mindset rather than fixed-mindset terms. The results were published in a YML file that gave us a starting point to improve upon.
Utilizing the CLI and UI version of the inclusive check tool (that you can use, too!), we’ve made incremental improvements to the language we use to describe our roles. The tool also allows us to notify our team members if they’re proposing a change that will have a negative impact on the language used. It’s a win/win.
Dedicated time to source candidates from underrepresented groups
We also spend time collaborating together to source candidates for our four highest priority roles as part of our Sourcing for Underrepresented Groups (SURG) initiative.
The SURG initiative increases the understanding of priority positions, enables team members to source candidates from underrepresented groups for functions they usually do not contribute to, and creates opportunities for recruiting team members to collaborate outside of the usual Recruiter: Sourcer partnership. On average we contact 100 prospective candidates from underrepresented groups each month through the initiative.
We’ve made some incredible hires and, selfishly, I’ve loved collaborating with different team members, too.
Utilizing team member feedback to improve messaging response rates
When sourcing for a Software Engineer in Test position, we noticed our response rates were lower than we’d expect.
We decided to gather feedback on four different messaging styles, assembled the different options into a GitLab issue, and shared the options in our #women and #diversity _inclusion_and_belonging Slack channels.
The feedback was clear: The original messaging received a resounding rebuff from the women on our team.
The themes and insights from this feedback outlined the importance of emphasizing our approach to asynchronous work as this enables our team members to balance work and personal lives.
It was also made clear we needed to make the prospective candidate feel something. The original messaging failed to do this. Fortunately, our values, culture, product, and professional growth opportunities provided a foundation for us to do this.
The good news? We saw response rates rise to 50% after incorporating this feedback.
TMRG conversation at end of the hiring process
Any candidate nearing the end of the recruiting process is offered a call with a team member outside of the interview panel who is part of a Team Member Resource Group (TMRG).
We recently brought in this change. There are two primary goals. The first is to provide the candidate with a unique perspective on GitLab that interview processes may not offer. We also hope these conversations can foster a relationship with someone on the team prior to them even signing a contract with us. We can’t thank the TMRG members enough for their willingness to take part in these conversations!
An environment where everyone can thrive!
We’ve been able to deliver and iterate on these tactics because of the leadership of our Diversity Inclusion and Belonging Manager, Candace, the commitment from so many team members who ensure this is an environment where everyone can thrive, and our values of collaboration and iteration.
I’m excited to see the impact our recruiting team can have in playing a part in our wider Diversity, Inclusion, and Belonging strategy while we all look forward to making the GitLab team even closer to a full representation of society.
