I had intended to write a single post related to GitLab and how it implements its values, because I was afraid that if I broke it up, I would end up using some of the same examples across the different posts, since a lot of what we do exemplifies more than one value, but in the end, I decided shorter posts would be better. Nevertheless, the series should be read as a single article broken up for publication purposes.
I wanted to write this post because after years of working in public services and similar organizations, GitLab was quite the culture shock, but in a good way. I wanted to share some of my experiences in the hopes that others can learn from how GitLab implements its values — collaboration, results, efficiency, diversity, iteration, and transparency (CREDIT) — that many organizations also value, but where some seem to struggle to implement them.
Context
I was originally going to write this blog post earlier, but in hindsight, I understand a lot more about GitLab’s culture now that it’s been a bit over a year, so putting this off turned out to be a good thing.
For those reading this but aren’t aware, I joined GitLab, an all-remote software company, in June 2018 as a Support Agent for the GitLab.com (SaaS) product (as opposed to the self-managed aka self-hosted version). When I started, I was the 4th agent and 6th individual contributor (IC) to join the GL.com support team. Though the overall company has more than doubled and the support team has now grown to over 50 ICs, the .com team remains small with less than 10 ICs (where the latest new member joined November 2018). The .com team is also comprised mostly of agents with only 2 engineers. In comparison, the self-managed team is made up entirely of engineers.
It’s also important to note that unlike many other support teams in other organizations, at GitLab, it’s a team within the engineering department. Support ICs report to a regional manager, managers report to the director, and the director reports to the VP of engineering (see the org chart for reference). At many other companies, support resides within customer success or a similar department. It makes sense for our team of primarily engineers, and encourages us to file issues, and submit contributions to the product and docs.
The Values
The 6 values are fairly easy to remember thanks to the acronym CREDIT. The handbook already covers a decent list of ways we practice each value, but I wanted to share specifics from my personal experience with some comparison to my perspective on how many other (public) organizations practice these values.
If you have any good stories, please share in the comments or via social media on this post or the individual posts.
Disclaimer
As usual, what I’ve written is based on my personal views and experiences. Although I hope for others to learn from what I’m sharing, I also don’t purport to be “right”. Each organization is different and not everything will work in a given organization especially since each organization’s culture is a unique combination of things.
While I strongly believe that GitLab’s values and the way we put them into practice is how we’ve achieved a great workplace that is also highly efficient and produces excellent results, the culture we have is also a collective thing where we all implicitly agree on the values, that we should uphold them, and is in large part carried over from those who started and have been a part of the company.
Please look forward to them.
