GitLab CEO Sid Sijbrandij occasionally sits down for a "pick your brain" meeting with people seeking advice on open source, remote work, or a discussion of other things related to GitLab.
It is far easier to run an all-remote company than one that’s a hybrid of remote and colocated, says Sid Sijbrandij. When a company adopts a colocated culture there’s less recording of things and fewer digital artifacts, so it’s going to be hard for the rest of the company to figure out how decisions are made.
I interviewed Sid for lessons on building a distributed company like GitLab. Sid answered questions on topics ranging from hiring to customer support.
My top takeaways from the interview:
1. Remote interviews are more convenient than in-person interviews
During an in-person interview, you need to make sure all your interview materials are loaded beforehand on your laptop or iPad. It’s also going to be hard navigating things on your computer while talking to a person in front of you. You might write down notes that you’ll need to digitize later by scanning, which is redundant work. On the other hand, when interviewing someone remotely over a video conference, you have all the materials at hand. Because you’re looking at a screen you can look up information online and quickly take notes without interruption.
2. Spend more time on the candidate’s questions than on your questions
During interviews, you can get a lot of information about the candidate from the questions they come prepared with and their follow-on questions. When Sid interviews, he spends most of the interview on the candidate’s questions.
3. It is really important to write things down
People are very efficient at reading things. If you write something down you can refer to it, so you don’t have to say everything again. In order to have alignment in a distributed company, repetition of goals and strategy is needed. Repetition is easier when you have one writeup and people are able to easily find it.
4. Google Docs is superior to a whiteboard
It is quite common to have meetings where everyone is looking at the same thing. But, because of time zone differences, it’s hard to involve everyone in a meeting. While whiteboards are commonly used in in-person meetings, they’re not missed that much by remote workers. Google Docs is superior to a whiteboard because you never run out of space, you can use numbered lists and indentation, and people can view them afterwards.
5. Cross-functional teams don’t work well
GitLab doesn’t do cross-functional teams. Teams are composed of people that perform a similar role. A team manager is someone who has experience with that role. This way the manager is able to assess results, coach, and give career advice, which is very important.
6. Focus on the output of employees, not the input
Good remote workers are focused on results. Especially for managers, it’s important that they don’t focus on the input of people – how long they worked or things like that – but rather focus on the output. Focus on the input is not healthy in any company, but especially with remote work you have to let it go. No one’s looking over your shoulder to check whether you’re on Facebook or not, and it’s fine if you are as long as you deliver the work to a reasonable degree.
7. To be a good manager, you have to quickly identify and remedy underperformance
GitLab hires people who are capable of being managers of one. But in instances where someone is underperforming, managers have to identify it, have a conversation, and take remedial action. Here’s GitLab’s process for dealing with underperformance.
8. Be quick with recognition
GitLab has various kinds of employee recognition. For quick recognition, there’s a #thanks channel on Slack where people can celebrate their colleagues’ work. There are also $1,000 discretionary bonuses and GitLab tends to be very high velocity with those. Recognizing employees and doing it quickly is really important.
9. Put customer-reported issues on a level playing field with internally reported issues
The issue tracking process in GitLab doesn’t distinguish whether the issue reporter is a user, a customer, or a team member. If an issue comes from a user or customer, it’s probably because they care a lot about what you’re building. So, every feature request, everything GitLab team-members work on is out there on a level playing field. GitLab tends to have a lot more interaction with customers than other companies.
Watch the full interview below:
Visit this page to read the transcript of the interview.
About the guest author
Sunil Kowlgi is the founder of Outklip, a video platform for remote work.
Photo by Brett Zeck on Unsplash
“9 lessons from @gitlab on building a distributed company” – Sunil Kowlgi
Click to tweet