Summary
More of us are working remotely than ever before, many with no prior experience with a remote work environment. In this episode Quinn Slack discusses his thoughts and experience of running Sourcegraph as a fully distributed company. He covers the lessons that he has learned in moving from partially to fully remote, the practices that have worked well in managing a distributed workforce, and the challenges that he has faced in the process. If you are struggling with your remote work situation then this conversation has some useful tips and references for further reading to help you be successful in the current environment.
Tidy Data is a monitoring platform to help you monitor your data pipeline. Custom in-house solutions are costly, laborious, and fragile. Replacing them with Tidy Data’s consistent managed data ops platform will solve these issues. Monitor your data pipeline like you monitor your website. It’s like pingdom for data. No credit card required to sign up. Go to dataengineeringpodcast.com/tidydata today and get started with their free tier.
Do you want to try out some of the tools and applications that you heard about on Podcast.__init__? Do you have a side project that you want to share with the world? With Linode’s managed Kubernetes platform it’s now even easier to get started with the latest in cloud technologies. With the combined power of the leading container orchestrator and the speed and reliability of Linode’s object storage, node balancers, block storage, and dedicated CPU or GPU instances, you’ve got everything you need to scale up. Go to pythonpodcast.com/linode today and get a $100 credit to launch a new cluster, run a server, upload some data, or… And don’t forget to thank them for being a long time supporter of Podcast.__init__!
Announcements
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
- When you’re ready to launch your next app or want to try a project you hear about on the show, you’ll need somewhere to deploy it, so take a look at our friends over at Linode. With 200 Gbit/s private networking, node balancers, a 40 Gbit/s public network, fast object storage, and a brand new managed Kubernetes platform, all controlled by a convenient API you’ve got everything you need to scale up. And for your tasks that need fast computation, such as training machine learning models, they’ve got dedicated CPU and GPU instances. Go to pythonpodcast.com/linode to get a $20 credit and launch a new server in under a minute. And don’t forget to thank them for their continued support of this show!
- You monitor your website to make sure that you’re the first to know when something goes wrong, but what about your data? Tidy Data is the DataOps monitoring platform that you’ve been missing. With real time alerts for problems in your databases, ETL pipelines, or data warehouse, and integrations with Slack, Pagerduty, and custom webhooks you can fix the errors before they become a problem. Go to pythonpodcast.com/tidydata today and get started for free with no credit card required.
- Your host as usual is Tobias Macey and today I’m interviewing Quinn Slack about his experience managing a fully remote company and useful tips for remote work
Interview
- Introductions
- How did you get introduced to Python?
- Can you start by giving an overview of the team structure at Sourcegraph?
- You recently moved to being fully remote. What was the motivating factor and how has it changed your personal workflow?
- What is your prior history with working remote?
- team practices for visibility of progress
- impact of remote teams on how code is written and organized
- reducing review burden by writing clearer code
- structuring meetings when remote
- points of friction for remote developer teams
- benefits of being fully remote
- incentivizing documentation
- compensation structure
Keep In Touch
Picks
- Tobias
- Quinn
- Skunkworks by Ben Rich
Closing Announcements
- Thank you for listening! Don’t forget to check out our other show, the Data Engineering Podcast for the latest on modern data management.
- Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes.
- If you’ve learned something or tried out a project from the show then tell us about it! Email hosts@podcastinit.com) with your story.
- To help other people find the show please leave a review on iTunes and tell your friends and co-workers
- Join the community in the new Zulip chat workspace at pythonpodcast.com/chat
Links
- Sourcegraph
- Quinn’s Python Search Engine
- Sourcegraph Employee Handbook
- Gitlab
- Gitlab Handbook
- Zapier
- Zapier Guide To Remote Work
- Automattic
- Automattic Blog On Distributed Work
- Comments Showing Intent
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
Click here to read the raw transcript...
Tobias Macey
0:00:13
Hello, and welcome to podcast dotnet, the podcast about Python and the people who make it great. When you're ready to launch your next app, I want to try a project you hear about on the show, he leads somewhere to deploy it. So take a look at our friends over at linode go to hundred gigabit and private networking node balancers. So 40 gigabit public network fast object storage and a brand new managed Kubernetes platform all controlled by a convenient API, you've got everything you need to scale up. And for your tasks that need fast computation such as training machine learning models, or running your ci and CD pipelines. They've got dedicated CPU and GPU instances. Go to Python podcast.com slash linode. That's Li n o d today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of this show. You monitor your website to make sure that you're the first to know when something goes wrong, but what about your data? tidy data is the data ops monitoring platform that you've been missing. With real time alerts for problems in your database ETL pipelines or data warehouse and integrations with slack pager duty and custom web hooks, you can fix the errors before they become a problem. Go to Python podcast.com slash tidy data today and get started for free with no credit card required. Your host, as usual is Tobias Macey, and today I'm interviewing Quinn slack about his experience managing a fully remote company at source graph and useful tips for remote work. So Quinn, can you start by introducing yourself?
Quinn Slack
0:01:36
Yeah. Hi, Tobias. And Hi, everyone. I am Quinn slack. I'm the CEO and co founder of source graph, we build universal code search. So if you are a developer, and you work with tons of code, tons of devs tons of complexity, then you have one search bar to go that lets you find and fix anything across all of your code across all our repositories languages, including Python, of course. All versions, all code hosts and so on.
Tobias Macey
0:02:03
And do you remember how you first got introduced to Python?
Unknown
0:02:05
It was one of the first languages that I used. And I remember, back in college, I took a whole summer off. And I was working at some campus jobs all to fund what I was doing for most of the hours, which was writing a Google like search engine from scratch in Python. I still have the code. It's up on my GitHub. It's one of my fondest memories of just writing a lot of Python code in the California summer. And I guess it kind of foretold what I am building now with our team at source graph, which is a search engine for code this time and back then, yeah, that Python project was just general web search.
Tobias Macey
0:02:42
And so as you mentioned, you have been building out the source graph company and the product and I know that recently you went to being completely remote from being a remote friendly organization. And I'm wondering if you can start by giving an overview of the overall team structure source graph in terms of Have the sort of breakdown of what the roles are and how you manage those remote responsibilities.
Unknown
0:03:06
At source graph. We have about 35 team members total, and we're growing quickly. But we started out in, I think, in 2014, we made our first two hires, and they were both remote, one of them in South Africa, one of them in Arizona. Fantastic, folks, and they are still with us today. So from the very beginning, we had remote team members. And from then until about a year and a half ago, we continue to hire a lot of great people remotely, but we also had an office in San Francisco. And what I saw is that we were doing remote Well, we were doing the things that you need to do such as writing stuff down, having a synchronous communication, not relying on shoulder taps. And so there were people who are remote at source graph who I felt like I was closer to than even people in the office people that are You know, I built an even closer personal connection to people who I felt like I communicate more frequently with who are remote. And, you know, I've seen a lot of other companies go remote, I've seen some, you know, go partially, but that led us toward actually emphasizing hiring more people remotely. And of course, you know, it's no shock to anyone. But there's a ton of smart people that do not live in the San Francisco Bay Area. So we continue to grow our team get fantastic people all around the world. And it got to a point where we had this cool office in San Francisco, and it was great to see people in person, but I knew personally because I'm a developer by background that, you know, sometimes that intense focus that is hard to get in an office is really valuable. And I felt that people were coming into the office more than really was optimal. So we had a decision to make do we continue to have an office and hire remotely or do we then go Remote first where the default assumption is, even if you're based in San Francisco, you choose on any given day, whether you want to come to the office or not. And so we did that we went to remote first. That was an improvement, people liked it, people were able to be where they felt most productive on any given day. But even then, I definitely felt people were coming into the office more than was optimal. They felt like they needed to not in a bad way not and I'm forced into I'm forced to do this, but in a way where they didn't want their other teammate to come into the office and feel that it's kind of empty. So they would want to come in and be a good teammate, which is really good sentiment and I felt the same way. But that wasn't globally optimal. So that's why we decided to finally go all remote. It also has the benefit of putting everyone on a level playing field. So you know, every single person at source graph is working from the same kind of setting and to the extent that we still had some practices They didn't fully give remote people both, you know, contributions that definitely forced us to fix that. I wouldn't say fixed it, but it forced us to fix
Tobias Macey
0:06:08
them. And do you have much History Prior to the your current company of working remotely? Or is this something that you have been discovering as you went as you continue to build out the product and the company,
Unknown
0:06:19
no formal history with this kind of remote work. But you know, of course, when I was coding back in, you know, when I was younger, I was doing it from home. And that was certainly not an office setting. And I was able to meet people on IRC and you know, work on coding projects with them. So I knew that you can build that kind of personal connection and you can be productive from anywhere. I work somewhere where the job is mostly travel for about a year. And I've got to see that with people scattered all around the US in the world that you can be productive and I also do believe with remote work. The tech industry is adopting it more and more But we are relative late comers to remote work, a lot of professional services firms, a lot of consulting firms, a lot of accountants and lawyers. They have always been remote and in many cases even work from home. And they know that works well for them. So this is not some revolutionary new idea that tech companies are pioneering. It's something that works in a lot of different industries, and has been proven out in a lot of different industries. So that was my background coming into it. It certainly it didn't seem like a crazy idea to me, and I personally understood how I would love it and how a lot of other people would love it. The thing that I was worried about is would it work for a company at scale? Would it work, not just with our developers, but also our customer engineers, our marketing folks, our sales folks. And there was another point where some of our first hires on sales were remote and that worked extremely well. And so seeing that we had another function of the company be successful remotely. That was really important.
Tobias Macey
0:08:00
So you mentioned that your first hires were remote. I'm wondering what were your original motivations for actually creating an office at all? And what your ultimate decision was to going back to being fully remote rather than being partially remote or remote? First? Well,
Unknown
0:08:16
I don't think we thought about it enough when we were starting the company, and we did the default approach, which was get an office wherever we were located, and try to hire people there. And if there's someone great, then we'll hire them remotely. I think a lot of companies are in that position. That's a great way to go. There's nothing wrong with that. But having seen just the tremendous number of amazing folks all around the world that we were able to hire remotely, it made sense for us to go all in because I think if you are one of those half remote companies, you're at a disadvantage if you want to hire the best remote people because they love to be at a company where they are a first class citizen where everyone is remote. So if you are in that position, I would recommend you think about should we be really deliberate? And should we actually go 100%. And if it's working for you right now, if it's still fairly early, or if you think that the team will go along with it, then I definitely recommend making that switch. We did it. And it has worked out for us. There were actually a few people on our team. So developers who were a little worried they love coming into the office in San Francisco, and they were worried that they wouldn't build that personal connection with their team in the same way, or they wouldn't have the same career advancement opportunities. Now, of course, with COVID, and everyone experiencing this, I think people are not going to have that same concern as much. But at the time, that was something that we were worried about, and we wanted to make sure that that went smoothly. As it turns out, the same people that expressed those concerns, were actually the first ones to take advantage of the flexibility with location moving to different states moving all around the world. So I think they were able to overcome that worry, and we've done I think a pretty good job of having clear tracks to grow. As a manager to grow as an engineer, no matter where you're located in the world, and becoming all remote removes any kind of worry that people might have, where if you're remote, you're going to be, you know, missing career opportunities, because everyone is in that same boat.
Tobias Macey
0:10:13
Yeah, it's interesting because particularly in the tech field, there have been a number of different cycles of people saying, oh, I'll work is going to be remote and distributed, and then going back to all work needs to be done in the office. And then yeah, it seems that there are these different cycles of the sort of general consensus of what is the best way to do work and how prevalent remote work is going to be. And every time it feels like we're at the tipping point, it seems that companies go back to saying, Oh, no, we need to have everybody in the office. And I don't know if maybe that's just a factor of the growth cycles of the sort of influential companies in the industry, or if there are other factors at play, but it's definitely something that I've seen a few times and I've worked remote a few times myself, and I can definitely relate to what you were saying as well of first class citizenship. People who are remote because if you have a cadre of people who work outside of the office, and then a small group of people who are getting beside the office, it's hard to be able to maintain the same degree of connection throughout the team for those people who are in the office versus remote.
Unknown
0:11:14
Yeah, you know, I haven't thought about the cyclical nature of this. What do you think caused the previous cycles going from positive toward remote to not positive, back to positive?
Tobias Macey
0:11:24
I don't have any sort of hard evidence to it. But my intuition is just that there are sort of cycles of people saying, Okay, let's experiment with it. And then some people have one negative experience may be somebody who's higher up or could be a matter of different management having issues with maintaining visibility and control over the people who work for them. And so they then push back against remote work rather than trying to push through that initial discomfort and figure out what are the actual optimal practices and now there have been a number of companies who have had great success of building completely remote So places like St. Pierre and get lab and automatic who have written about it a lot or base camp. And so that's helping to make it more viable. So there's more material to point to and more experiences to point to have things going well, but it's definitely also a matter of the individual makeup of the team where some people feel more comfortable in an office environment, being able to do the shoulder taps, as you mentioned, and being able to have that face to face time or water cooler time, which is much harder to do naturally in a remote environment, you need to be much more conscientious about it. And so some people don't want to put that extra effort and extra rigor to make sure that they maintain the same degrees of relationship. Yeah, makes sense. And in terms of your own work of being remote, what are some of the ways that you have approached that in terms of making sure that you do have good practices in place? Are there any other companies that you've looked to for advice or inspiration or have you been just sort of doing it through means of communication within your team to Figure out what are the useful practices? I know that you have a fairly comprehensive Handbook of some of the approaches to ensuring that your remote work is successful. But I'm wondering what you're drawing from for being able to figure out what are those social norms and technical tools and things like that for being able to make sure that everything continues to run smoothly.
Unknown
0:13:19
We have learned a lot from get lab. They also have an extensive handbook online that talks about all of the processes and norms that they've put into place to make remote work work really well for them. And we've done our part. We also, as you said, have a handbook online that talks about how we do this. And that's all been helpful, but really what it takes to do remote work well, it's not that different from what it takes to do any kind of other work well, from both an individual point of view, but also a management point of view with any kind of large organization once you get over a handful of people. You need to share the vision you need to get people context, you need to make it. So there are communication practices that are not just shoulder taps. Because even if everyone is in the same office, if the way that you communicate is by standing up walking over to a teammate and tapping them on the shoulder, well, people are not going to get a lot of stuff done. And it's not going to be a good place to work. So you need to have a way to make all that information accessible beforehand to the right people, you know, as much as possible, you don't have to be perfect, and you need to do that whether you're in person or remote. And in remote, I think in a way you actually feel the pain. If you don't have that, well running, you feel the pain more quickly. And so therefore, you're able to learn more quickly, you feel the pain where you know, now you have to wait eight or 12 hours or 24 hours for an answer because someone's in a different time zone and you feel that pain really acutely. Whereas if you're all in the same office, you can kind of suffer through poor communication practices a little bit better and it prevents you from improved It right when you feel that pain. So one of the reasons why we don't feel that being remote is any kind of detriment to our productivity is because we feel all the things that we do to make remote effective, we would need to be doing anyway or we should be doing anyway. So the additional cost that you can attribute solely to being remote as a development team seems quite small. Sometimes it's if our systems didn't work, and the information I need is not written down and the person that I need it from is asleep, or they might be doing something else during their day because remote tends to come with more flexibility. Sometimes that means I have to wait a little bit more time. But you know, that cost even that that is exactly what makes us get better next time. So even though we feel the cost a little bit there, and I could attribute that to us being remote, it is just such a good force for us getting continuously better.
Tobias Macey
0:15:52
And in terms of your role as somebody who is running the business and managing the team. What are some of the Useful practices that you have found for being able to maintain visibility into the progress that's being made and ensuring that all of the work is staying on the right track, or that people aren't drifting off on to sort of sub optimal paths.
Unknown
0:16:13
Well, we want people to know what the goal is know why that's important and know that they are responsible for getting it done. And that includes raising their hand asking for help when they need. So if I feel personally that I would like visibility into some project, or if I see one of our managers saying, I would like more visibility and do a certain project. My first question would be, why do you want visibility? Do you not trust that person to own that? Do you not trust that person to raise their hand if they need help? And if so, you know, maybe there's a valid reason maybe that person who's doing the work is asked for mentorship or is asked for someone to check in but if it's someone who is not caught With the person who owns it getting it done, then that's a red flag, it's something that we need to overcome, maybe it means the goal wasn't set appropriately, maybe it means that person isn't the right person to own that task. So visibility in itself, it's not necessary. Now, sometimes I love visibility into things that are going on a source graph, because we're doing a lot of cool things. And I like to see how this new search feature is coming along. And that's totally different. That's something that we also do to share knowledge on the team serendipitously, which is post screenshots post prs early, but in general, for software development, I would reject the idea that people need visibility and all these projects because in the end, what we care about is results and you don't need visibility while that work is going on to get results in the end. And
Tobias Macey
0:17:49
another aspect of remote work in particular is an increased need for effective communication which can take part in many fashions you mentioned sort of posting prs or To get some feedback and posting screenshots of progress being made, but what are some of the other communication practices that you have found to be most useful and most effective to make sure that everybody is involved, who needs to be and making sure that issues arise early and that everybody is on the same page?
Unknown
0:18:18
This is really tough. And I think it's tough for any organization, not just for remote, the thing that we strive for is to have a single inbox for all of the tasks now, for most companies, and for us, right now, this is pretty far from reality. You wake up and you have a bunch of slack notifications, you have a bunch of emails, you have a bunch of GitHub notifications that didn't come through email, you've got some Google Docs, notifications, and all of that stuff. And so what that means is, you know that you have a lot of inboxes, you know, that your teammates have a lot of inboxes and you don't have confidence that they would have seen this thing that you did, so we're trying to do more than through email, actually, which I want to call out, because slack is an amazing tool for Team chat. And people might think that slack is synonymous with remote work. Even though it's a great tool, it's not the silver bullet to remote work, you need to have confidence that when you do something, when you communicate something to a team member, that you expect them to know that they're going to see that and slack doesn't give you that assurance, we really only found email is the way to get that assurance. Email is the common denominator for everyone. Everyone knows how to use it, every kind of tool can always route things to email. So, it is what we are trying to do to use more and more as that single inbox and that is the the you know, first thing you need to establish and then you need to establish an expectation that people will go through that some developers after several years of using slack have you know, stop checking their email, but developers you know, I I totally get why if it is different Difficult to be an effective developer if you have so many different inboxes pinging you all the time. And so we've seen our devs actually absolutely love when we are going more to email. So that's the first thing. Another thing is, as I said, eliminate the shoulder tap, there's no way that you can completely stop the need to ask someone a direct question. But every time that happens, ask yourself, how could we have made it so that would have been unnecessary? How could we have created a system so that that information would have been written down in advance? How can we create the incentives for the person with that information to have already published it? And that is the hardest part about managing any kind of organization, I think with respect to communication, because you don't want to overdo it. You don't want to have people document write down everything because that can just slow down you know, everything. So, you know, how do you create the right incentives for people that write down the correct things and no more so that people aren't drowning in writing
Tobias Macey
0:20:59
and others thing too is that documentation can be effective, but it's useless if nobody reads it. And if nobody knows where to find it, then it's essentially wasted effort. And so what are your practices for ensuring that documentation whether it's for a specific elements of code, or architectural documentation or sort of design reviews or just discussion on company best practices? How do you approach organization of all that material to make sure that it's easily discoverable and that it gets surfaced at the appropriate time for people who need it or as it's being produced?
Unknown
0:21:32
This is huge. The most important thing is we need developers to trust that our documents are not wrong are not out of date. And that's a really strong guarantee to provide. It is costly in terms of time to provide so we have designated some places to be the source of truth for information they need to be up to date. They cannot be wrong, and some other Places, it's just, you know, scratchpad scratch documents. That was a snapshot in time for us. Google Docs, every Google Doc is just a scratch pad. It's ephemeral. So no one expects to go on our Google Drive, find a Google Doc, and see that completely up to date. Anything that is in our Handbook, which is a markdown repo on GitHub, any, anything that's in our public documentation, and anything that's in a very small number of explicitly designated Google Docs, those are our sources of truth. And those need to be up to date. So for example, if we have a development practice around, you know, one thing we recently introduced is requiring certain code coverage increases on every PR, and you know, they can be waived, but we have to get an exact policy. As soon as we introduce a process like that developers can have questions like, why are we doing this and that information needs to be in our handbook as quickly as possible. And it's just really bad if developers go and see That is not in our Handbook, because that just makes them lose confidence in that handbook as the source of truth as being up to date. So if you can take a tiny portion of all the writing that you do and say anything that goes here, we just need to commit really heavily to make this correct and up to date, then people are going to trust that, and people are going to understand that there's a high cost to moving a document from ephemeral land, you know, some random plan to this permanent place. And they are going to write sparingly when they put it in this source of truth location. So that's been working well, for us. It's, you know, absolutely true that we don't update everything perfectly. But everyone understands. We need to strive for that. And then at the same time, you can write all you want in these random Google Docs, because it's just a snapshot in time. It's just a scratch pad and you're not saddling yourself with this burden to keep this up to date forever. That's really They help us.
Tobias Macey
0:24:01
And one of the things with developer documentation is that everybody agrees that it's a good thing. But it's also difficult to keep it up to date. And it can often be seen as sort of a last resort or the last step in a process, which means that it frequently gets cut in order to make sure that something gets out the door. And what are your practices for incentivizing that type of documentation or ensuring that the code is communicating effectively for the people who are working on it so that it cuts down on that overall cycle time of questions being asked and answered?
Unknown
0:24:35
I think if you're developer deciding do I spend my precious hours today writing documentation, the main thing that causes you to write that documentation is if you know people will benefit from it. If you know you're going to help your team. So the more you think that people are actually going to use the documentation you write, the more likely you're going to write it. So if we have a handbook, if we have a set of documentation that everyone knows they use all the time and they see the team using all the time, then that is a huge boost in the motivation to write docs. And the second thing is, I will boost that even a little more. So every company meeting every week, one of our slides is going through all the people that wrote docs, whether in our handbook or anywhere else, you know, basically any markdown file in any of our get repositories, highlighting that is really nice social proof, it shows that the team cares about this. And even if you didn't write Doc's in any given week, you see that a bunch of other team members did. This actually came from something way back when in high school when I was growing up, they would put these posters on the wall, saying, you know, X percent of people at this high school drank alcohol and the last week is called social norms, marketing, I guess. And the point at the time was, you know, most people are not drinking. Now, of course, it kind of backfired. And it showed actually a lot of people were because the percentages are fairly high. But this idea of communicating what everyone else is doing when you want to achieve an end to show that this is a common practice, it's quite effective. And even though it certainly backfired back when I saw when I was in high school, we're using it to good results, that source graph.
Tobias Macey
0:26:16
And then another element of communication within the development team is the way that the code is structured the way that you approach the actual writing of the code and the descriptiveness of the code there. One of the things that I've seen before that I think is a good idea, but I admittedly haven't fully put into practice myself is something called comments showing intent, where you write the code comments not to discuss the what or the how, but the overall intent of the code with the idea being that if you stripped out all of the actual code and just had the comments, then you could re implement it in any language and still have it produce the same intended outcome. But I'm wondering what have you found to be the impact of remote teams on the way that code is written and organized? And some of the best practices for reducing the review burden in terms of how to approach that code definition and how to construct the prs.
Unknown
0:27:08
I think that's a great tactic for writing better comments. I think what helps people write better comments in the end is if they think the teammates will use it, and if they have felt the pain from lack of comments and other people's code, and one great way to make people feel that pain is if they come across code, and they need help with it. And if we're in a remote team, they know they can't just get up and tap a teammate on the shoulder. You know, that's bad anyway, but they could do it if we were all in the same office. So someone has felt the pain of reading through someone else's code without comments. And lacking that understanding as a result, they're going to understand better why comments are important. So there's nothing there's no kind of formal, you know, methodology around writing comments that can substitute for someone having viscerally felt the pain from lack of comments beyond that. code review is really important. We have a pretty strict code review process. It is way any line of code is read and maintained way more times than it's written. That is really clear, we actually demonstrate that with our product. And that that is such an obvious motivation for having very strict
Tobias Macey
0:28:20
code review. And you mentioned the use of your product in terms of being able to do some of this analysis of the benefits of code review, what are some of the other ways that you've been able to dogfood it to increase the throughput of your development teams and increase the visibility and effectiveness of everybody being able to stay on the same page and work together and reduce bugs and things like that,
Unknown
0:28:41
while you want to reduce shoulder taps? You want to give everyone the ability to answer questions that come up while they're coding on their own. And do it by consulting the code instead of getting up and tapping someone on the shoulder. So this code search gives you that ability. you as a developer, when you're coding and you get stuck, you know, for example, what's the right way to call this internal API, you can search for it, you can see how everyone else at your company has called that API, you can then see, well, this call here, this one looks kind of weird. And it was written six years ago by someone who's no longer with the company. So maybe I won't trust that. But this one is actually written by the code owner, and it was two weeks ago. And that one looks like a representation of our current best practices. So you've been able to find out best practices, even though they weren't documented anywhere, because who would have known to document this specific thing and make it discoverable to you and just the right way, but you were still able to find that information. That is why code search is awesome. In the same way that Google web search is great if you don't have you know, a room of experts who know everything about every topic in the other room to go ask. The second thing that code search does is it creates more of those instances where you bet from someone else having written things down, you benefit from when you're debugging some piece of code. You pull it up in code search and you're looking through the code and you see a comment there. That helps answer your question. And that's just another tally in your internal kind of scorekeeping, where Wow, comments are helpful. Next time you are writing code, you will think back to that moment when your teammate wrote that really helpful comment. And that's motivation for you to do the same and pay it forward to the rest of your teammates. So you know that if you write comments, because code search makes it so all your team can find and get answers from code directly, when you write comments, you know that people are gonna be more likely to actually benefit from them in the future, and therefore you're gonna write more of them, you're gonna write better comments.
Tobias Macey
0:30:46
And another element of communication within a company environment is the dreaded meetings, which can sometimes be a waste of time or can also be a valuable way to spend time and make sure that everybody is on the same page. And I'm wondering what your approaches to how to structure meetings when remote versus being able to get everybody in the same room at the same time. I don't know if we do this
Unknown
0:31:09
very well, it's it's always hard to know different people have different appetites for meetings. The one thing we found is really important is to not try to be so hyper efficient. There's a world in which you could imagine, in a remote organization, every single meeting beforehand has a clear agenda. Everyone has reviewed every single doc and given all their feedback about all the points and so discussion is five minutes per topic. If it takes more, you know, cut it off. That seems nice in many ways, and that probably is how most meetings should occur. But when you are remote especially, you need to leave time for the brainstorming the random chats, the high level discussion the serendipitous interactions between people. So this We do this in two ways. One is we have regular water cooler chats were totally on their own teams of people that happen to be in the same general timezone, we'll just set up time and just chat usually just about life or, you know, fun things, someone built a keyboard with a bunch of LED lights, things like that. And the second thing is we need to leave time 30 minutes or an hour every other week or something like that, to just talk about the high level ideas that people have in certain feature areas in our product. Like what have people thought about cool ideas for making our code search better? How could we take code intelligence and make it so you can find usage examples across all open source repos better, these high level ideas that are not in anyone's mind, in a state where you could really carefully document them and write down all of the ideas you need to bounce things off other teammates and it's really important that you say that is okay. You don't need to have every single conversation 100% buttoned up, it's okay to chat. And it's okay to brainstorm just in the same way that you would if you and your teammates go out to lunch and just chat about cool things on your mind. No one at lunch feels every lunch needs to have an agenda. We cannot talk about anything for more than five minutes. And that's an important source of new ideas and bonding.
Tobias Macey
0:33:26
And another aspect of managing a remote team is the idea of compensation structure where if everybody's in the same geographic region, you can try to optimize for cost of living within that city. And there are a lot of different discussions that go on about scaling compensation based on what that cost of living happens to be or keeping it flat so that regardless of where you live, you can either have the benefits of having more income versus what your expenses are, or somebody who wants to live in the city is making that their choice. I'm wondering what your thoughts are on how to do it. approach that compensation structure for people who are so widely distributed.
Unknown
0:34:03
This is really difficult. And we're trying to figure out how to do this. We don't have an answer. I know that there's nothing that will satisfy everybody I really respect to get lab for posting their philosophy around this. They do pay people different amounts based on where they are. And they document why. And their argument roughly, is, if we were to pay everyone the same amount, regardless of whether they live in a really high cost of living location or low cost of living location, then our team would be virtually all people living in low cost of living locations, because if you're in a high cost, living location, it wouldn't be a competitive salary. And that's an argument. There's the fairness argument and just the weirdness argument on the other side. So these are the things that we're grappling with. The thing that we want to do is when we find something that's the right choice for our team, we want to write it down. We want to put it in our handbook because one that's just how we operate and too, we want to help out other companies that are facing the same decision. But this is something we're working on right now. And it is really difficult. Of course, you also have issues like if someone is in a high cost of living area, and they move to a low cost of living area, do you reduce their salary? Now, in speaking with my friends who work in other industries, they say, Well, yeah, of course, that's obviously how it works. But to people in tech, that just doesn't feel normal. So there's all kinds of things. There's all kinds of edge cases that tech companies will need to figure out and that we'll need to figure out to make this work. We have 35 people now, and anything would have worked to this point. We don't need to have some really formal rule around this up to this point. But it's clear that for our next you know, 50 team members that we hire, we need to figure this out
Tobias Macey
0:35:51
and going to the individual scale. Now. There are a lot of elements that go into the team interactions. When everybody's remote, but there's also the aspect, particularly if you're working from home and not from some sort of office location of how do you structure your life? How do you structure your day to make sure that you are able to focus and get some sort of optimized work time in and being able to maintain some level of sanity. And this is something that's top of mind for basically the entire globe now because of the current pandemic, but what have you found to be some of the useful practices and useful advice that you have taken advantage of for being able to structure your own work day or within your team for ensuring that you do get that focus work time in and you're able to be effective while also still maintaining a healthy balance with the rest of your life? I
Unknown
0:36:42
think this really depends on the company, but any company you're at, I think you as someone who's working remote, you need to advocate for what is best for you. Because everyone at your company is going to be on a slightly different schedule. And that's okay. You need to figure out what works best for you. So if that means taking two hours in the middle of the day to go ride horses, like someone on our team does, if that means going for a run in the middle of the day, if that means taking off at 3pm and hanging out with your kids, putting them to sleep and then coming in working a little bit after that, that's okay. It's some companies I'm sure would not allow that. But I think it's really important to communicate what makes you most effective. And if you're communicating in those terms, then everyone on the team is going to understand I think
Quinn Slack
0:37:30
for the kinds of companies that our listeners are
Unknown
0:37:35
going to be at, there's some other things around, you know, helping your family understand what it means to work from home, working from home is not hanging out at home. So being clear and communicating with your partners with, you know, your kids and so on. I have an 11 month old daughter so I'm not yet feeling the thing where you know she wants to come and knock on the door and hang out with me. If she does that right now, it seems amazing. And it seems like a ton of fun. But I know that it'll get in the way. And I don't know what to do with that. As with most things in parenting, I think I any plans that I have about how to deal with that now, I would have to throw out immediately. So I would defer to other people who have experienced that for how to deal with that kind of dynamic. I will say, though, that your team, they're all people. And if you have, you know, your kids in the room during a meeting, they're going to love that they're going to smile, and don't try to hide that from your team. They take joy and getting to work with other great people and your family is a part of that. So don't try to hide that.
Tobias Macey
0:38:38
Yeah, somebody who has worked remote on a few different occasions and somebody who has kids, I can second your point that any plans that you make are invalidated as soon as your kids decide that to be the case. It's definitely something that you do need to have some manner of sort of diligence and let them know what are the expected boundaries but don't be concrete in What they are, and be sure to allow some flexibility in your day so that if there's some sort of, to your kids life altering moment or something that they deem is being important and worth your time, you know, make sure that you take advantage of that. Because that is one of the benefits of being able to work from home is spend more time with your family. But as you said, you also have to make sure that you provide some structure so that you don't get too carried away and spend all of your day hanging out with your family and not getting any of your actual work done.
Quinn Slack
0:39:27
Yeah, definitely.
Tobias Macey
0:39:29
And so what are some of the other useful pieces of advice or useful references that you have looked to as you continue on this journey or any other advice or topics that you think we should cover before we start to close out the show,
Unknown
0:39:42
one other concept we found useful is the idea of feeling the pain and that means there's a lot of communication going on when you're remote and it's over text. For example, some team is trying to build a new feature that relies on our main site being really fast for this One operation, and they've told that team Hey, you know, it'd be nice if this thing were faster. That team that's responsible for making that thing faster. They don't know how important that is. And so if I'm in a meeting or I see something, and the team is trying to build this new features, really feeling pain from the site not being fast in this way that they need, they probably haven't shared that pain enough. They haven't made the team that's responsible for maintaining the main site, they haven't made that team feel the pain and understand just how important it is. So even though you might ask someone something, and it's just over text, they can't read your facial emotions, they can't see, you know, all of you in a room trying to debug something. So you need to make other teams feel that pain and you know, that sounds negative. Maybe there's a better way that we could phrase it, but it's the idea of people will only learn when they feel the problem themselves. If the problem is so distant from them, then they're not going to do the right things in response. And is this all the way are important when you're on a remote team. So a lot of times I'll ask someone, you know, does the team that's running source Skype comm? are they feeling that pain as well? And if not, how can you communicate to them so that they know that, you know, that's a big pain. And that's been a helpful way for us to communicate?
Tobias Macey
0:41:16
Yeah, making sure that you provide the context and all of your different communications is absolutely a requirement. Because as you said, if you don't have the facial expressions, or the sort of implied context of being in the same office together, it can be easy to lose the importance or possibly ascribe too much importance to something that is intended as just an offhand remark. So making sure that you provide the context and the specifics of what you're looking for is absolutely necessary.
Unknown
0:41:43
Yeah, totally. And as CEO I've had a lot of times when I've said something and people ascribe way more weight to it than I intended. So it's important that I communicate when something is just an idea or when something is important, or else I'm gonna waste a lot of people's time.
Tobias Macey
0:42:00
One other element of the overall employee experience and employee lifecycle that we didn't touch on yet is the hiring process. I'm wondering what you have found to be some useful practices or useful tools for ensuring that the interview process and the onboarding process is effective for people who are new to the company or making sure that you are all in alignment in terms of what you're looking to gain from that employee and what that employee is looking to gain from their opportunity with the company.
Unknown
0:42:28
Our number one worry when we went all remote, and we were talking to a lot more people that have never been remote and trying to hire them to our own team was, you know, will this given person actually work well, remotely. And what we found works is really simple. We asked them Do you want to work in an all remote company and we've never seen someone get this wrong. I think people have a pretty good sense of whether this is what they want or not. And some people who've ended up being fantastic. In all remote, were hesitant, but they were open about that and they were willing to try it out and that's fine. If someone is saying no, I don't want to be all remote, then obviously they're not going to be a good fit. And we have not seen anyone lie or claim Oh, yes. I love all the remotes when they actually don't because, you know, what's that gonna get them. So that worry actually ended up being much less important than we thought. Otherwise, for interviews, we do them all remote. Most new people we hire, we've never met those that we have met, we probably met them at some conference or something. So this is actually a fairly easy part of the process, especially with, you know, it's not that different from, I guess, all of being remote. It's not that different from a company that's gotten really big and has offices in San Francisco and Chicago and New York. Most companies at a certain point, they become all remote you effectively are all remote with respect to most of the people at the company that you work at once you Have a lot of locations. So you know, none of this is new, really.
Tobias Macey
0:44:03
And one other common practice for remote teams is the idea of having an annual or a quarterly gathering where everybody goes usually to the central office headquarters for people who are partially remote or to some location for places that are all remote. And I'm wondering what your thoughts are on the benefits of that, or cases where that might be suboptimal?
Unknown
0:44:25
Yeah, that's been amazing for us. The really cool thing is, you can actually build more camaraderie with team members, where you might meet them once or twice a year and spend three or four really high quality days with them. And some of that time is going around and exploring a new city some of that time is you know, working together really closely. You can be closer to that kind of person than someone that you just see in the office every day and have casual interactions with so being deliberate about getting people together about having quality time for the team. That is really important. And I think that can to actually be better than a year of casual interactions with someone in the office, I've felt that personally where there's again, people who are remote team members on my team, where I feel closer to them than people who are in the office sitting 10 feet away from me every single day. And that's a really cool thing to know. And that gives me confidence that we can maintain these really strong team bonds as we grow.
Tobias Macey
0:45:22
Are there any other aspects of your experience of managing a remote team or working remotely yourself or the overall topic of distributed workforces that we didn't discuss the you'd like to cover before we close out the show,
Unknown
0:45:35
one final thing is time zones, you can choose to be all remote but only in a certain time zone. I think the natural tendency is to open that up and expand. You might even have team members who start out in the timezone and move. So if you are an all remote company that spans multiple time zones, that gets a little bit trickier. You of course need to have asynchronous communication, but what I would recommend is keep in mind That with a lot of different time zones in play, some people are waking up really early, some people are staying up really late. And if you aren't, then it means you're forcing everyone else to do the same. So, model the right behavior, you know, make sure that for several of these meetings, you are the one who is joining at an inconvenient hour, that is a good way to show you are empathetic, and it's good way to, you know, share some of the sacrifice. You also people are different people at different times of day. So you will get to see your teammates with a lot more energy or in a goofier mood and things like that. And that's pretty fun to see, too.
Tobias Macey
0:46:36
All right. Well, for anybody who wants to get in touch with you or find out more about what you're working on or follow along with the work that you're doing. I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the pics and this week I'm going to choose a new notetaking app that I just found out about that I've been testing out for the past day or so. It's called Joplin and it's intended to be an open source replacement for Evernote with some people. Built in flexible sync capabilities, and so I've been testing that out seems to be pretty well structured and a good way to try and organize your thoughts and keep track of things. So definitely worth taking a look at that. And with that, I'll pass it to you, Quinn, do you have any picks this week,
Unknown
0:47:14
I have loved reading the book skunkworks by Ben rich, it is about the facility that built a lot of amazing planes for the military. And in the end, it's about managing an engineering team that built amazing things at immense scale that no one thought were possible when they were in the drawing board. It's been an awesome book highly recommended. Alright, let's take a look at that.
Tobias Macey
0:47:39
Well, thank you for taking the time today to join me and share your experience of building and managing a fully remote team. It's definitely something that is incredibly relevant for the majority of the population today. So I'm sure that there's going to be some useful pieces of advice from that. So thank you for your time and your efforts. And I hope you enjoy the rest of your day.
Quinn Slack
0:47:59
Thank you. You
Tobias Macey
0:48:03
Thank you for listening. Don't forget to check out our other show the data engineering podcast at data engineering podcast comm for the latest on modern data management and visit the site at Python podcast comm to subscribe to the show, sign up for the mailing list and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts at podcasting a.com with your story. To help other people find the show, please leave a review on iTunes and tell your friends and co workers
