We’ve heard people say "every company is a software company," but what about the people who work there? At GitLab, we drink our own wine, and that means all of our team members, in some way or another, are technical because we use GitLab ourselves. In People Ops and recruiting, I use GitLab every day; just take a look at my activity chart!
These blue squares represent contributions I’ve made across the GitLab project (and the white ones prove that work/life balance exists!).
Getting started with issues
A good portion of those blue squares are dedicated towards issues, specifically pre-established template issues, such as the onboarding issue. This is the "first look" our new hires have into GitLab and our workflow, and it’s a fantastic way to get them using issues, and thus GitLab the product, right away. One of the tasks in this issue is "add yourself to the team page," so within the first week at GitLab, all team members submit a merge request, even if they’ve never coded before. Another task is to "make an improvement to the handbook," which both encourages new hires to submit another merge request and to explore our handbook and adopt our ethos of "everyone can contribute."
within the first week at GitLab, all team members submit a merge request, even if they’ve never coded before
Other issue templates we have and use regularly are offboarding and opening new vacancies. People Ops uses these issue templates to maintain version control, enable everyone to contribute, and allow us to continually iterate and improve on how we onboard our new hires, all of which promote the GitLab values.
We constantly iterate on all of our issue templates, predominantly the onboarding issue template mentioned above. You can view its history and see how everyone at the company iterates on our onboarding issue – not just People Ops, but also new hires and seasoned GitLab team-members. You can also view some of the ideas we’re working through in the "Overhaul onboarding for Ta-NEW-kis" issue, and feel free to contribute your own ideas!
Transparent by default
People Ops and HR departments are not typically considered transparent at most companies, but here at GitLab we try our best to be as transparent as possible. The only times we keep things confidential are when we are legally required to, or to protect someone’s privacy. Everything else is fair game! Some great examples in our handbook are our identity data, internal feedback, and the questions we ask in our screening calls with candidates. We make it a point to keep this data, as well as other handbook pages dedicated to People Ops and recruiting, up to date and accurate.
Everyone can contribute
We encourage our team members and the wider GitLab community to contribute and give us their ideas because they will have a fresh look and unique perspective, which can only improve our own understanding.
I remember when I joined GitLab a year ago, I interviewed with Sid Sijbrandij, our CEO, and he asked me what I wanted to accomplish within my first month at GitLab. I told him I wanted to become proficient in Git so that I could properly contribute, and he was surprised! But I was steadfast, and within my first two weeks, I’d already started contributing via my local machine. Sure, I’m not a developer by any means, but I use Git every day, have figured out quite a few things both on my own, and with the help of our #git-help Slack channel, was even granted merge powers last year! Here at GitLab, everyone can contribute, no matter what your background is.
Photo by Maxime Le Conte des Floris on Unsplash
