Quinn Slack of Sourcegraph on Moving to Fully Remote and Zoomcations

Transcript

• 00:00 Shane: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture podcast.
• 00:09 I'm sitting down across distance with Quinn Slack from Sourcegraph.  Quinn, welcome. Thanks very much for taking the time to talk to us today.
• 00:16 Quinn: Thanks Shane. It's great to be here.
• 00:18 Shane: Probably a good starting point is who's Quinn and who's Sourcegraph?
• 00:22 Quinn: I'm Quinn. I am a programmer, I love code, and I started a company called Sourcegraph. Our goal is to get code search to every developer in the world. It is so useful when you're coding, it makes you way more productive and it lets you find usage examples, lets you fix things across all of your code. And we are growing quickly. We have a lot of customers and you can just get a little Google-like search box across all of your code. It's that simple.
• 00:52 Shane: Cool.  Now were put in touch because you're doing some pretty interesting things with the way you run Sourcegraph and some of the changes you've made. We're in the middle of the working remote, suddenly remote from any of us because of COVID-19.
• 01:09 But you actually made the deliberate transition from being in person to being a remote organization earlier in the year. Have you got some thoughts about that and thinking of our audience who have been thrown into this situation, some advice, or maybe some mistakes that they can avoid?
• 01:25 Quinn: Well, we are an all remote team and we're about 50 people now, all around the world and we did go through this transition a little earlier to all remote. So I want to try to give tips and things that we're doing that are new, because everyone is talking about remote these days. So we'll try to keep it to that.
• 01:45 But just for some background, we started the company and our very first people to hire, they were remote in South Africa and Arizona, my co-founder, and I were in California. So from the beginning we had built up some of the muscle, but then we had a traditional in-person office in San Francisco, all the traditional stuff that you'd expect from a tech startup office.
• 02:05 And as we grew, we were about half and half remote. We had this sense that the best people were not all in the Bay area. And we knew that because we had amazing people from all around the world, and we wanted to become more and more remote, but we weren't quite ready to take the plunge to going all remote.
• 02:25 And so near the end of 2019, we moved to remote first, which is the idea that on any given day, you wake up and you can decide to come into the office if you want, and if you don't want to, that's totally fine. And there is no expectation whatsoever in either direction. And we thought that's great. But there were two problems for that, and I think that as companies start to return to work in the middle of the pandemic, a lot of companies are going to be in position and feeling the same two problems that we felt then.
• 02:56 So this is a caution from our experience.
• 03:00 The first problem is that if you say it is okay to be remote, it is okay to work from home or wherever, well, a lot of people, they want to stay employed. They want to be seen as hardworking, and they think that means showing up in the office. So, if it is optional and if there's any sense among employees that they should be there, if managers tend to show up more, then optional doesn't actually mean optional. It means let's cause a lot of stress on every single employee and make it so that they talk to their friends and partners about how they don't know if they're supposed to actually know that means they should be in or not. So that was tough.
• 03:41 And what I saw happening is even though we said remote first, people were coming into the office and I would see them in there and I'd say, you know, Hey, you know, what, what made you decide to come into the office today? And they didn't have a good answer.
• 03:55 And as I dug into it, I found the other problem that we were experiencing when we were remote first. And that is you have an office that is sized for the whole team when only half the team shows up on any given day, it feels awkward. It feels weird. It feels like a disaster movie and half the population got wiped out and you're walking through this empty city.
• 04:17 Desks are empty and intellectually, everybody knows the reason why Sally's desk is empty is because she is super productive at home and she's doing great. Intellectually, you know that, but it doesn't change the fact that it feels weird to look around and like half of the desks are empty and you can just not get over that feeling. You feel awkward. You talk about how it feels awkward with other people on the team, and then that is another thing that causes people to want to come into the office. More than is optimal for their productivity and happiness. They don't want other teammates to have that awkward feeling of a zombie movie just happened at the office.
• 04:57 So we were feeling those two things and I just felt this is not working in this in between state.
• 05:03 So that is when we decided let's go all remote, and we talked about it as a team. There were some people that had concerns about it. There were some people who felt that it could make it harder for us to bring on junior people and train them up and that is absolutely a valid concern. There were some people who would miss the comradery of the office.
• 05:23 We talked about it and we agreed as a team that it was the right move and that we would work really hard to mitigate those two problems, to build the comradery, build the bonds with our team and to make sure that we could bring on junior people and help train them up.
• 05:40 So we needed to be really disciplined and explicit about doing that.
• 05:43 So on January one, 2020, we became all remote. Our office lease expired in mid February, and we have been all remote ever since. And it has been just a continual learning effort. How do we build the muscle to operate efficiently as a remote team?
• 06:01 Shane: Some of those challenges, what did you put in place to overcome them?
• 06:04 Quinn: On training up junior people, the most important thing is to be really clear about what the requirements are to be really clear about who will train them, who will mentor them and in a way it is so important to be clear and to be disciplined about doing it. And it being all remote has been for us, a forcing function to be disciplined about that, to not just expect people to come in with more junior experience and to learn by osmosis. We need to actually identify who is going to take 25% of their time and 25% of the points that they otherwise could assign toward doing new work, to train up junior people.
• 06:45 And I would imagine that we should have been doing that when we were in person, but we weren't, there was no forcing function. So being all remote really cuts through a lot of the BS and is a forcing function to do the things that we should be doing anyway. And we might be doing if we were a 500 person company, but that we weren't doing at the time when we were, you know, a 30, 40 person company.
• 07:09 So, you know, I don't have any specific advice on how to overcome that from an all remote point of view, other than just the standard best practices and that if you don't do that, you're going to feel a failure, way more quickly in an all remote setting, which fail fast is good.
• 07:21 Then on building team camaraderie, we took all the money that we were spending on the office and we explicitly said, we're not trying to go all remote as a way to save money. We're going to take that same amount of money, and maybe even more, and use that on team travel budgets, use that on team bonding budgets, and also when people travel and meet up with each other, of course, this was pre pandemic.
• 07:44 When they meet up, make sure to get that quality time, make sure half the time, half the days that we are in person with the team are spent visiting the zoo, going to a sporting event, you know, going to restaurants and not just working in a coworking space and you're just staring at your office.
• 08:00 Build that quality time and what I have found from building these bonds with our remote team personally, is there are people that are halfway across the world where I feel closer to them. I know more about them than people that were in the same office, because I spent that quality of time. I was having dinner at their house, you know, or I invited them over to my house when they were in San Francisco.
• 08:22 And we had that quality time, that can beat out hours, spent working, you know, 10 feet away from someone and only talking to them at the water cooler.
• 08:30 Shane: What's been hard?
• 08:31 Quinn: Well, communication is hard and again, as we learned with training junior people, everything is hard in a business. It's just being all remote makes you feel the pain, makes the hard things hard, faster, and makes the failures more apparent. Which is very helpful.
• 08:49 So for communication, the thing that we have done that is by far, the most helpful thing is to have a handbook, a comprehensive handbook that describes how the company operates. It's as though, if you could write code for everything we do as a company, then that's this, except you can't write code, and so it's a set of markdown files and a get repository and every function of the company, every team within the company, every process we have, we strive to document it in the handbook. So if you go to the Sourcegraph handbook, but which by the way is public, then you can see this.
• 09:25 You can see for our engineering team, you can see what are all the teams inside of that. What is their mission? What are the responsibilities of each role? What are the roles that we're hiring for? How do we hire, if someone wants to hire for new role, how do we do that? If you need to restore our site, after someone accidentally deletes the production database on Google cloud, how do you do that?
• 09:46 These processes are all documented.
• 09:49 And then the key thing is. This is not some Polish handbook that one person maintains, every single person at the company is responsible for maintaining this and we actually check that. And it's not, you know, you get punished if you don't update it, but if you don't have to it, then we ask why, you know, why are you not trying to go through these processes?
• 10:10 You know, maybe everything is just perfect for you. And if you want to change something in the company, you don't call a meeting. You don't chat about it in Slack or email or whatever. You change the markdown file to what you would like it to be, and you submit a pull request, and that is the proposal, when you want to change how the company works.
• 10:29 Writing things down in this way has been so tremendously valuable for our efficiency and for our ability to work together as an all remote team with 50 people scattered in most time zones all around the world.
• 10:44 Shane: How do you make it safe to put forward, perhaps controversial ideas?
• 10:51 Quinn: You're right. There are some things that every company needs to do that can sound kind of weird when you write it down. One key thing a company needs to do is determine how much to pay people. Another thing is when someone is not the right fit for the team, how do you part ways with that person?
• 11:09 And we are all adults here. We know these things happen, and we think that most people, certainly people that we would like on our team, they appreciate these things being written down. And so we have those types of things documented salary bands. We have our standards documented around how do we determine pay, what percentile we have chosen to pay regardless of location. I know a lot of companies choose to adjust compensation based on location, but we've choosen to pay independent of location and we target a certain percentile for each function and for each role, based on our compensation studies. That in the end is very simple and we document it.
• 11:52 For the process on leaving Sourcegraph. If someone wants to leave Sourcegraph, or if we don't think that someone is the right fit, we have that documented in the handbook and, I'm not going to lie, it felt weird. It still feels a little weird to have that written down, but it feels refreshing.
• 12:07 It takes a load off of our shoulders. It takes a load off of every manager's shoulders and every single person on the team. They know that we have a process for this. And so when you are an employee at a company and you make a small mistake, you know, sometimes, I've been there, I worry, you know, is tomorrow the day that I'm going to get fired, that's not a good feeling. And I actually think that writing the process down in a way, where all your other processes of the company are too, writing that down, helps people understand how the company thinks about performance and how the company thinks about when someone is not performing well. You know what that looks like.
• 12:45 And obviously, you know, it's Sourcegraph, and I think in most companies making a single mistake does not mean you're going to be fired tomorrow, but most companies don't have that written down anywhere. And we do have that written down somewhere. So it actually can provide a nice level of clarity.
• 12:59 There are some other things that we write down that also people are surprised by.
• 13:03 For example, we write down all of our quarterly goals. And these are in the OKR format objectives and key results that Intel and Google use. They're public, anyone can see them, now we do redact some of the actual numbers around revenue and things like that, but you can see what everyone at the company is doing, what all of our goals are.
• 13:25 And we frequently get emails from people we know, and people we don't know, saying, Hey, by the way, I think you accidentally made some of these pages public, you might want to check on that. And of course, we intend them to be public, but what this means, so communication in a company is difficult. I think anyone has experienced this thing where you can say something 10 times, 20 times a hundred times you can write it down, but still not everyone gets the message. And that is just fundamentally hard.
• 13:56 We have made communication better, not perfect, but better because everyone at Sourcegraph knows that all these things are in one place. It's a GIT repo with markdown files. It's searchable, it's on the web. You can search it on Google if you type in Sourcegraph and then some policy into Google is probably going to show up. And so there's one place to look for it, and if it's not there, then it either means we don't have a process for it. Or, you know, I guess maybe you type in the wrong keyword and there's not, you know, some set of secret documents. There's not some other random folder of Google docs that has a bunch of other processes. It's in one place.
• 14:30 So I believe we have achieved an outcome that a lot of companies don't have where every single person at Sourcegraph can pull up our goals are okay, ours in five seconds or less. And just that if you can do that, you will make hitting those goals significantly more likely to happen.
• 14:47 Shane: Let's explore OKR's - are they just fashionable or are they really useful?
• 14:51 Quinn: They are fashionable, and they are useful. I think the name OKR, it makes it sound worse. When we have our company meeting every Monday, we have a brief summary of our progress on OKRs, but each time I make a point to say these are our OKRs.
• 15:08 OKRs are goals that are in a tree format. And that's what I think the nice thing about OKRs is.  There is a tree, so that each person if they're working on some leaf node of the tree, they can walk the way back up to the high-level outcome that what they're doing is going to help with. So, you know, maybe calling them tree goals would be better.
• 15:30 I personally would prefer that because I don't like jargon, acronyms, like, OKRs.
• 15:35 Shane: And how does that translate down to the work that I'm doing today,  to the code I'm about to write, to the test cases I want to build, to the marketing we want to do?
• 15:46 Quinn: There's always going to be a gap between the quarterly goals and the results that we're looking for as a business and what someone is doing on any given day.
• 15:55 And if there's not a gap, then it actually means that you are micromanaging, that the goals are too fine-grained and that you don't have the agility to change things. You know, the goals might be guessing at the implementation of something. I mean, in the extreme case, when you're setting your goals for the quarter, why don't you just do all the work and just paste it in that doc,  that's clearly absurd.
• 16:17 So there's always going to be a gap, but that's why you hire smart people. That's why you give them information and all kinds of contexts about the business and you tell them, here's the outcome we want,  here's how we're going to measure it. And then in the end, you want them to figure out the best way to do that.
• 16:32 You don't want them to translate exactly into what someone is doing, but when they are doing that task, you want the goals to give them motivation so that they know how what they're doing is going to help the business, help their team, why it's important, what other things are important. You want all that motivation and being connected to the team. And that does come from the OKRs or three goals as again, I prefer to call them.
• 16:58 Shane: All right. So you got this in the publicly searchable repository, everyone's aligned with it. We're working completely remotely. Now time zones are offset,  you were saying you've got people all around the world. How do you tackle that, just the simple synchronization across time zones?
• 17:17 Quinn: The first way to handle the timezone problem is to admit that you will not be able to handle the time zone problem and to build the systems so that you don't need to, so that you can be productive even without that.
• 17:30 And again, I'll come back to this point. This is not really a different problem from if you're all in the same office because let's say everyone is in the same time zone in the same office. It's not the case that everyone is going to be able to synchronously work on the same things. You are still going to block. You could be sitting next to someone and you're working on something with them and then something else comes up, maybe they get sick. Maybe they get pulled onto another project, and you have to set it up so that you're not gonna block on that person indefinitely, but with all remote, the problems are the same, but you fail faster and you fail much more painfully. If you don't build the muscle, the systems to overcome this.
• 18:06 So move to asynchronous communication, move to write down things more, move to encode the next step for someone when you give them comments. For example, if something is 90% of the way there, and you're asked to approve it, write down what we'll get the other 10% in a very clear way and say, if you do those things, I trust you, it's approved.
• 18:25 And those are the kinds of things that would make any business operation, even if you're all in the same office, more efficient and you'll do them as all remote and then that's going to get you a big part of the way toward feeling like time zones are not an issue.
• 18:38 What people also don't talk about is the beauty of time zones. The idea that you can do a bunch of work, you can go to family dinner, you can hang out with your family, go to sleep. And when you wake up progress got done while you were sleeping. How magical is that? And you pick it up and you can just go. It's a magical feeling. It makes you connected to your team and to the planet and just feel global in a way that's really cool and mind blowing.
• 19:08 Shane: Leveraging that time. 
• 19:10 With all remote, one of the things that I know some people have struggled with, is actually getting out of work mode. When we were chatting earlier, you spoke about Zoomcations - do tell?
• 19:26 Quinn: A Zoomcation is a week when you are working, but you are not in any meetings whatsoever. I think we need this.
• 19:35 So there are three modes that you're in.
• 19:37 You are either working, you are on vacation and that's where you shouldn't be connected at all, and hopefully somewhere sunny, having fun. And then a third thing, which is new, which is this Zoomcation. You do not accept any meetings, you cancel all of the meetings for the week and you are as strict with that as you would be if you were on the beach somewhere,
• 19:56 But you're still working, you're getting deep work done. I don't know of any other companies that do this, you know, clearly, there are some companies that try to have no meetings days, but those they're not really enforced. So we're trying this and the early signs are quite good, of course, it's very popular with people, but in general, my philosophy on vacation and what I've seen at source graph is they're actually very good, and I'm not saying that because we're not trying to work hard.
• 20:25 We work hard at Sourcegraph and that's important. And I am a human and I love vacation and being on the beach as much as anyone else, but vacation serves a really important work purpose, in that if somebody knows that they are going to be away from work for one, two, three, four, five weeks during the course of the year, and they are not able to jump in Slack, to jump in an email, too, you know, pull up their laptop, then they're going to build the code, they're going to build their team. They're going to build the business processes. So that they are all robust to their temporary absence. And that's a good thing, that's removing single points of failure. You're going to automate your deployment or automate that backup process if you know that while you're going to be on vacation for three weeks, those are all good things.
• 21:14 And also when somebody is gone on a vacation, it gives people on their team, a chance to step up, and that is such an important time for other people in the company to understand. Well, you know, who else can we promote? Who needs support? How can we help develop more people? If someone is always just keeping their claws in a certain process, then you don't get that time to build up the robustness and to build up that bench of other people.
• 21:39 And I think this applies just as much to the Zoomcation idea, where you get a little bit of preview of that, and you also get to see what happens when you are working, but not in on everything.
• 21:52 So this actually just came up, just yesterday, someone on our team proposed going on a zoom, cation but said that they would still join in on some of the meetings because they wanted to. Now, I love that, I take that person at face value and I believe that they do want to join in the meetings because I think we have a pretty awesome team and we laugh a lot in the meetings. But I actually said, no, you're not allowed to. I totally understand that the sentiment is good, but if you say you're going to do that, then everyone else thinks, well, you know, we're not that strict about Zoomcations.  Other people are going to see you modelling that behaviour and they're actually not going to take a fully effective Zoomcation.
• 22:30 And also it is really useful for that person, in their absence, to see what it's like to have to consume the meeting recording and the meeting notes as a way of finding out what happened. If those meeting recordings or notes are bad, that will be a very direct way for them to learn what needs to improve. Because by the way, it's not just them consuming those meeting recordings and meeting notes, it's other teams. Other people in the company and that feeling, the pain of those things being bad is the only way that they're going to get better.
• 23:01 So vacations are such an important business tool, it's not something that the business does just because otherwise, you know, the team would get really unhappy, they would, but it also is such an important business tool.
• 23:13 Shane: If I’m on a Zoomcation and I'm writing code, how do I get feedback on the quality of my code?
• 23:20 Quinn: Well, there are two ways. Sometimes you'll be on the more in-depth project that's not as involved with someone else or you carve it out in advance. And so, the interfaces between you and other parts of the code or the team, you agree on them in advance. And then you can just go heads down for a week. Or sometimes you just communicate asynchronously, and we need to have asynchronous communication be good because we cannot expect that you will always be able to synchronously communicate with people.
• 23:49 We have people in all time zones, we have people that travel to a different time zone. We have people that have to miss a meeting here and there, and if that blocks progress, then that's really bad for us anyway. So you just work asynchronously.
• 24:03 Shane: Quinn, if people want to explore this further and continue the conversation, where do they find you?
• 24:09 Quinn: I'm on Twitter as SQS. And if you want to see our Sourcegraph handbook, which is the entire code behind how the company operates as markdown,  then just go to our website, click on handbook, or just type in Sourcegraph and then some crazy internal policy or some goal and it's probably gonna show up on Google because it's totally public.
• 24:29 And if you see typos or clarifications, then click edit this page and we'd love to get the pull request from anyone listening.
• 24:38 Shane: Thanks so much.
• 24:39 Quinn: Thank you. 

Mentioned

• Sourcegraph
• Sourcegraph handbook
• OKRs
• Quinn on Twitter