What We Learnt From Our Chat with GitLab
Karthik is the Co-founder of Flexiple. A tech enthusiast who believes in the importance of execution over strategy.
GitLab has 900+ distributed workers. Slated to IPO soon, it might end up being the first true 100% distributed company to attempt this. This is extremely exciting for the remote community and a huge responsibility for GitLab as the entire industry’s eyes are transfixed on it.
So, when we got the opportunity to talk to Darren Murph, Head of Remote at GitLab, our heads were full of questions. Clearly, GitLab has probably figured the most about building distributed teams work at scale.
We wanted to understand why GitLab participates so strongly in the narrative of remote working, how it tackles remote working difficulties, inputs on how companies can turn the remote switch on, and so on. Here are our top learnings from the podcast:
1. Being a strong and loud advocate of remote work is for social good, but also seems to be an important narrative for its IPO
GitLab has clearly taken spreading the word of remote working very seriously. It just naturally led us to ask the question, why they would be investing so much time, energy and money into this initiative. Darren answered this for us.
Firstly, the social impact of it – to ensure that more people benefit from remote work. It totally makes sense for GitLab to make wider impact, but somehow it didn’t seem like the whole of it.
What we understand is that the remote aspect of GitLab is a really critical narrative for it as it prepares for an IPO. This gives their go-to-public story a unique spin while also educating the wider audience about remote work and also of GitLab’s expertise in this regard. Remote work could be considered an investor risk and these initiatives allay those fears.
Listen to this specific section here on the podcast: Link
“A lot of people know the tech side of GitLab but not so much the people & remote side. And that is big for us on the road to becoming a public company”
2. Collaborative documentation is the backbone to efficient functioning at GitLab
Learning how remote work can work at the scale of 900+ distributed workers was one of the most exciting parts of the podcast. According to Darren, the most important practice has been a very high focus on documentation.
GitLab’s handbook is a staggering 3000 pages and has been collaboratively built by one and all at the company from its very beginning. This has ensured that learnings from its inception haven’t been lost and that almost all answers can be found by relying on the handbook. What’s more – if it can’t be found, the onus is on you to find the answer, and then document it there!
Listen to this specific section here on the podcast: Link
“The biggest thing is documentation. And people like me coming in a few years into the company have a lot to be grateful for to our founders to think about documentation when the company was only 3 to 5 people. So, our handbook is 3000 pages long and it documents every process imaginable within GitLab front to back, even cultural processes. Everything is documented. And so, even people coming in now can look back at what was documented at the very beginning and it is very easy to get onboard instead of getting a hand me down of a hand me down of a hand me down.”
3. Key for every remote work company is to be intentional
The key for every company looking to go remote and definitely for already remote companies is to be highly intentional about everything. It is very easy for individuals and companies to default to processes that would work in a typical co-located setting, which can be very dangerous. Therefore, a conscious and intentional approach to everyday work is needed to make remote work successful.
Listen to this specific section here on the podcast: Link
“From the employer’s standpoint, two things come to mind. You need to be extremely intentional about informal communication. And this is a big one because when you are in a co-located setting, people tend to cross paths so they can more naturally develop relationships in and outside of work which generally helps the morale of the company. In a remote setting, you need to be intentional about this. So you need to weave things like coffee chats, group social calls, team social calls, company calls. You need to weave that into the culture and carve out time company-wide to make this a thing.”
4. Local rates-based compensation is practiced but not without negotiation
An interesting approach to compensation, albeit a hotly debated one, is to offer salaries on local rates. GitLab has a compensation calculator public to calculate the compensation for a particular area. What we wanted to understand was how people performing the same skills however from different cities deal with being paid different compensation packages and whether it was a simple concept for all to grasp.
Darren interestingly mentioned that this is something they have to talk through with people about the idea behind the process. Also, the numbers aren’t rigid and it does come down to negotiation based on skills, aptitude and the needs of the company. It comes down to what people value – personal priorities vs. the need to live in big cities.
Listen to this specific section here on the podcast: Link
“It is something that we have to talk through with people. Obviously, in the interview process, there’s room for negotiation based on the needs of the company, and the abilities and aptitude of the person. It’s one of those things that it depends on what people value. It’s really a case by case basis. If people prefer to move and want to be in a big city, they can.”
5. There is still no elegant solution for time zone issues
While remote work does give a person the flexibility to work from different locations, what it also means is that his/ her team members also need to consistently keep adapting to the new work timings and styles of the person.
Darren accepts that the main problem, timezones, are the bane of our existence and there is probably no elegant solution for it. He draws a parallel with multi-national corporations that have headquarters across continents and face similar problems. However, one way to tackle this challenge is to have a total bias to asynchronous communication. This allows all to communicate any update or action ensuring the person at the receiving end can consume it asynchronously.
Listen to this specific section here on the podcast: Link
“So, look, timezones are the bane of our existence. But that’s the same in a multinational that has a headquarters at San Francisco, London and Singapore. Just trying to arrange the timezones between those three offices is a nightmare, and so that doesn’t change in a remote setting. Timezones are tough for any company that are across more than one or two. But how we deal with it, is that we have a bias towards asynchronous communication. And this is really important, because it trains people to default to communicating an update or a change or a thought, anything, in a way that can be consumed asynchronously. In practice, you just assume that no one is online in your timezone. Just assume that you are the only person in the company online at a given point of time.”
6. Interesting method to implement asynchronous through Slack
One interesting nugget that Darren slipped in while discussing how they implement asynchronous through Slack, was that GitLab doesn’t subscribe to a tier that stores messages perpetually.
This forces everyone to document information that is critical to the project or a later time in the future in GitLab project management/ issues rather than relying on a short-term convenient option on Slack.
Listen to this specific section here on the podcast: Link
“We do not pay for a tier in Slack that would keep your messages perpetually and it’s intentional. We actually don’t want people defaulting to using Slack if they could convey project-related information through GitLab issues or merge requests which are much more permanent and are directly related to the work. From an efficiency standpoint, if you have solved something on slack then you have to translate that over to a merge request or to an issue to make something happen.”