About a year ago, I wrote a reflection on Summit and Contribute, our all staff events, and later that year, wrote a series of posts on the GitLab values and culture from my own perspective. There is a lot that I mention in the blog post series and I’ll try not to repeat myself (too much), but I realize I never wrote a general reflection at year 1, so I’ve decided to write about both years now but split into 2 parts.
Getting Hired
Overall, it was really nice to have the general process and everything laid out on the website. The process I went through was very straightforward.
- Apply.
- Take home test.
- Screening call.
- Interview with manager.
- Interview with (interim/stand in) director.
- Interview with VP.
- References check.
At GitLab, the time till hire is meant to be fairly short so as not to lose great candidates simply due to the length of the process. Admittedly, one of the reasons I accepted at GitLab was because they offered before the ones I was still interviewing with. While I knew GitLab did not fit into my experience as well as some of the others, I was very intrigued by the values and the way they seemed to be applied.
Of course, I was particularly attracted to the transparency of seemingly everything.
Getting Started
Onboarding anywhere can be overwhelming and tedious at the same time. GitLab in some ways isn’t any different. You still have a ton of account setups and things to check off, but there’s a nicely laid out template and provisioning of accounts is mostly done by other people. You only need to deal with it if for some reason it was missed.
Coffee Chats
As part of onboarding, you’re encouraged to have coffee chats with people in other departments and outside your geographical area. One of the great things of being in a fully remote company is that you’re not location bound (though you are timezone bound).
But it’s not only during onboarding! We’re encouraged to continue having coffee chats with random people within GitLab. We have a donut bot that randomly pairs people (who are in that channel) every 2 weeks. It completely ignores timezones but sometimes people will do the calls outside of “standard” work hours, so it works out.
It’s a great way to meet people you might not normally and hear about what’s happening in other parts of the company.
Sometimes you end up communicating or working with people you might not expect to and it’s great when you see a familiar face.
Learning GitLab (6 months)
I was hired at GitLab as a Support Agent, like everyone else newly hired to the team focused on the SaaS product. We had a couple of Support Engineers on the team, but the hiring process for that position was geared towards people who would work on the self-managed product, so we never actually hired any new ones.
My first manager, Lyle Kozloff, was hired specifically to build out a team to work on GitLab.com (SaaS), and with the first hire in March, when I joined in June, the team was still quite small and new. A lot of processes weren’t written or weren’t quite fleshed out yet.
Even then, GitLab is a large product and at the time, there were close to 300 company members, so there was a lot to learn both on the technological side and the company/culture side.
The Culture Shock and Adjustment
Learning technology is usually the “easy” part. Learning to work within a company is usually the hard part, and often what sets them apart.
While I’ve never worked in a “tech startup”, I’ve worked in small, flexible teams, and the co-op somewhat worked like a startup. I also know quite a few people who have or do work in startups, so I had heard a lot of stories.
I’m not sure anything though could have truly prepared me for GitLab’s culture.
Little did I know that not only do GitLab team members follow the values, but that many of them will call others out on not following them, publicly. Additionally, it was done in a way that followed our values too. Our CEO, Sid, very much leads by example in this area, but Victor Wu, a former product manager, is the one I probably remember most especially in my early months of doing this in places that was visible to me. I learnt a lot about our values from his messages, so I am still grateful that I had a chance to work with him.
Everyone that I met and began working with were welcoming and ready to share their knowledge. I constantly felt like I had crammed twice as much knowledge than I normally did in the same amount of time, but it was a great experience to be learning about technology that I had only heard of.
Nevertheless, I wasn’t sure how I could best give back and start making a positive impact.
When I spoke with my manager about it, he completely changed my work life. He told me that I didn’t need to ask for permission on everything and that
we trust you to contribute.
Having worked at many public institutions where procedures can be quite entrenched and literally yelled at for asking the “wrong” questions a couple of times (let alone doing something wrong), I didn’t realize how much my fear of stepping on people’s toes was hobbling my growth and impact at GitLab.
At GitLab though, part of our values is having “short” toes, and assuming positive intent. Added to that, the level of trust that we have across team members and teams is amazing.
It was quite an adjustment for me, but I embraced it.
Becoming Senior (1 year)
My fear of making mistakes has never disappeared, but with my manager’s encouragement, I started to take on work that I thought would benefit the team without asking ahead of time.
To help coordinate or advertise that I’m working on something, I typically create an issue in the appropriate project tracker and assign myself.
I also started digging into some of the common support topics we got. In particular, I looked at, started troubleshooting, filing issues, and once even getting a patch exception on project imports.
Then I took it further by proposing we should either have language to clearly explain why we won’t import projects for customers (then point them to our migration services team) or come up with a process where we could import one or two projects that might be blocking them from fully migrating. In the end, it took more than 6 months to work out the whole process and then I ended up doing a second, more complete security review about 4 months ago, but I’m happy to report that we’ve done over 20 imports since then. (Most were actually early on because our development teams have made a lot of improvements to imports in recent months.)
As I got to know more people and discussing issues with others more in-depth, I eventually started collaborating with other teams including with the VPAT (Web Accessibility evaluation). This internal “consultation” turned into my taking on a counterpart role with the UX team.
Later on, when we started formalizing the counterpart role, no surprised to anyone who knows my penchant for documentation and my self-labelling of being a documentarian, I also became one of the docs counterparts (and until more recently, the main one). I would say I know the docs team almost as well as the support team and am considered an honourary docs team member.
I also get pinged on issues and in Slack in some areas where we lack an existing counterpart or where I’ve become an expert.
While it was only a small improvement, I even decided to brush off my web skills and help make updates to our Support portal:
In February 2019, less than 10 months after I started at GitLab, I became the first Senior Support Agent.
My manager said it a recognition of the work that I was doing. It was awesome. When he first suggested finalizing the promotion document, I was floored. Never had I imagined I could go anywhere and get promoted so quickly.
Unsurprisingly, my job didn’t really look different after my promotion. I continued to work the way I thought I should, which meant not only working on tickets, but helping others, updating documentation, continually learning (meaning always working on a training “course”), and taking on whatever projects I could.
The Engineering Team
I want to wrap up this first part by talking about being part of the Engineering team.
Which department the Support team is part of differs quite broadly depending on the organization, often being in product or customers success.
I don’t know the full history, but at GitLab, the first Support team members were Support Engineers, and would not only be expected to troubleshoot any issue with GitLab, but also determine if and which piece connected or related to GitLab might be the issue. The product is what we support, but GitLab and the runner can be installed on almost any combination of hardware and OS, any part of which might affect GitLab itself. At rare times, Support might walk a customer through how to patch their instance. In most cases, we file an issue, or contribute a fix that will make its way up to all users.
I think being part of Engineering has been a big plus. We get any department-wide updates including major updates on how infrastructure and development are improving our largest instance of GitLab (GitLab.com), changes to development guidelines, productivity, and hiring.
I believe there’s also a certain amount of lower mental barrier when reaching out, since it’s all “engineering” and not reaching across departments. I think there are less barriers at GitLab, but I know that before I adjusted to the culture, reaching out to another department involved internal mental resistance nonetheless, and I know I’m not the only one.
Our UX (user experience) team is part of engineering as well, and technical writing (docs) team got moved to engineering last year. It consolidated all the “teams” within the company that were regularly making changes to the repository (which includes documentation).
Especially with the way GitLab works, I don’t think it would have been bad for Support to be elsewhere (there were rumours floating around at some point), but being in Engineering implies that you contribute to the GitLab projects, and that’s a good expectation to have.
Part 2 coming soon!
Here’s a group of capybaras to say show the sense of camaraderie and collaboration, also as a reward for reading through part 1. Part 2 coming soon!
