The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

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 gigabit in private networking, node balancers, a 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/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute.  

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, PagerDuty, and custom webhooks, you can fix the errors before they become a problem.   Go to python podcast dotcom/tidydata   today and get started for free with no credit card required. Your host as usual is Tobias Macy. And today, I'm interviewing Quinn Slack about his experience managing a fully remote company at Sourcegraph and useful tips for remote work. So, Quinn, can you start by introducing yourself? Yeah. Hi, Tobias, and hi, everyone. I'm Quinn Slack. I'm the CEO and cofounder of Sourcegraph. We build universal code search. So if you are a developer  

[00:01:46] Unknown:

and you work with tons of code, tons of devs, tons of complexity, then you have 1 search bar to go that lets you find and fix anything across all of your code, across all repositories,   languages,   including Python, of course, all versions, all code hosts, and so on.   And do you remember how you first got introduced to Python? It was 1 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 1 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 Sourcegraph, which is a search engine for code this time. And back then, you know, that Python project was, just general web search. 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.  



[00:02:54] Unknown:

And I'm wondering if you can start by giving an overview of the overall team structure at Sourcegraph in terms of the sort of breakdown of what the roles are and how you manage those remote responsibilities?  

[00:03:07] Unknown:

At Sourcegraph, 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 2 hires, and they were both remote. 1 of them in South Africa, 1 of them in Arizona.   And from then until about a year and a half   And from then until   about a year and a half ago, we continued 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 asynchronous communication,   not relying on shoulder taps.  

And so there were people who were remote at Sourcegraph who I felt like I was closer to than even people in the office. People that, you know, I had built an even closer personal connection to,   people who I felt like I communicated more frequently with who were 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 wanna come into 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 in I'm forced you know, I'm 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 wanna 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 Sourcegraph   is   working from the same kind of setting. And to the extent that we still had some practices that didn't fully give remote people full, you know, contributions,   that definitely  

[00:06:06] Unknown:

forced us to fix that. I wouldn't say it fixed it, but it forced us to fix them. And do you have much history prior to your current company of working remotely or is this something that you you have been discovering as you went, as you continue to build out the product in the company?  

[00:06:20] Unknown:

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 could build that kind of personal connection and you could be productive   from anywhere.   I worked 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 and the world that you could be productive. And I also do believe with remote work,   the tech industry is adopting it more and more,   but we are relative latecomers   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   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.  



[00:08:00] Unknown:

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, 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  

[00:08:26] Unknown:

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 1 of those half remote companies,   you're at a disadvantage if you wanna   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 a 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 loved 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 gonna 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 gonna be, you know, missing career opportunities because everyone is in that same boat. Yeah. It's interesting because  

[00:10:15] Unknown:

particularly in the tech field, there have been a number of different cycles of people saying, oh, all 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   of 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 work inside 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. Yeah. You know, I haven't thought about the cyclical nature of this. What do you think caused the previous  

[00:11:20] Unknown:

cycles going   from positive toward remote to not positive back to positive?  

[00:11:25] Unknown:

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 1 negative experience, maybe 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 of companies who have had great success of building completely remotely. So places like Zapier and GitLab, and, Automatic who have written about it a lot, or Basecamp. And so that's helping to   make it more viable. So there's more material to point to and more experiences to point to of 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 those 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   sure that they maintain those 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. We have learned a lot from GitLab.  



[00:13:22] Unknown:

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 is not that different from what it takes   to do any kind of other work well from both an individual point of view, but, you know, 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 give people context. You need to make it so there are communication practices   communicate is by standing up, walking over to a teammate, and tapping them on the shoulder, well, people are not gonna get a lot of stuff done, and it's not gonna 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 8 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 improving it right when you feel that pain. So   1 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. And in terms of  

[00:15:55] Unknown:

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 onto sort of suboptimal paths? Well, we want people to  

[00:16:16] Unknown:

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 1 of our managers saying, I would like more visibility to 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 has asked for mentorship or has asked for someone to check-in. But if it's someone who is not confident with a 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 at Sourcegraph 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, you know, post screenshots, post PRs early. But in general,   for software development,   I would   reject the idea that people need visibility in all these projects. Because in the end, what we care about is results,   and you don't need visibility   while the work is going on to get results in the end.  



[00:17:49] Unknown:

And 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 early 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. This is really tough and I think it's tough for any organization, not just for remote.  

[00:18:24] Unknown:

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's tough. 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 and more through email, actually, which I wanna 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   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've 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, stopped checking their email. But developers,   you know, I I totally get why. If,   it is 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 could 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 wanna 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 to write down the correct things and know more so that people aren't drowning in, writing? Another 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,  

[00:21:14] Unknown:

whether it's for 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? This is huge.  

[00:21:34] Unknown:

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 1 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, 1 thing we recently introduced is requiring   certain code coverage increases on every PR. And, you know, they can be waived, but we don't have to get any exact policy. As soon as we introduce a process like that, developers are gonna 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 making 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 helped us.  



[00:24:02] Unknown:

And 1 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 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. I think if you're a developer deciding, do I spend my precious hours  

[00:24:39] Unknown:

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 gonna 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 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, 1 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 Git repositories.  

Highlighting that is really nice social proof. It shows that the team cares about this, and even if you didn't write docs 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 in the last week. This 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 kinda backfired, and it showed actually a lot of people were, because those percentages were 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 it when I was in high school, we're using it to, good results at Sourcegraph.  



[00:26:17] Unknown:

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. 1 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,   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 have the comments, then you could reimplement 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  

[00:27:09] Unknown:

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 1 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 if 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  

[00:28:17] Unknown:

that that is such an obvious motivation for having very strict 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 dog food it to increase the throughput of your development teams and increase the  

[00:28:41] Unknown:

Well, Well, 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 1 looks kinda weird, and it was written 6 years ago by someone who's no longer with the company, so maybe I won't trust that. But this 1 is actually written by the code owner, and it was 2 weeks ago.  

And that 1 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 in 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 benefited 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.  

[00:30:47] Unknown:

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 approach is 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  

[00:31:10] Unknown:

very well. It's it's always hard to know. Different people have different appetites for meetings. The 1 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 5 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 2 ways. 1 is we have regular water cooler   chats, where totally on their own, teams of people that happen to be in the same general time zone will 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   a 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 1 at a lunch feels every lunch needs to have an agenda. We cannot talk about anything for more than 5 minutes, and   that's, an important source of new ideas and and bonding.  

[00:33:27] Unknown:

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 approach that compensation structure for people who are so widely distributed. This is really difficult.   Answer. I know that there's nothing that   will satisfy everybody.  



[00:34:08] Unknown:

I know that there's nothing that will satisfy   everybody.   I really respect GitLab 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 a 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, 1, that's just how we operate, and 2, we want to help out other companies that are facing the same decision. But this is something we are 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. And going to the individual scale now, there are a lot of elements that go into  

[00:35:58] Unknown:

the   team interactions   when everybody is 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 be be 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 Workday   or within your team for ensuring that you do get that focused work time in and you're able to be effective while also still maintaining a healthy balance with the rest of your life? I think this really depends on the company. But any company you're at, I think you as someone who's working remote,  

[00:36:50] Unknown:

you need to advocate for what is best for   you because everyone at your company is gonna be on a slightly different schedule,   and that's okay. And you need to figure out what works best for you. So if that means   taking 2 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 3 PM   and hanging out with your kids, putting them to sleep, and then coming and working a little bit after that, that's okay.   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 gonna understand, I I think, for the the kinds of companies that, our listeners   are gonna 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've experienced that for how to deal with that kinda 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 gonna love that. They're gonna smile,  

[00:38:31] Unknown:

and don't try to hide that from your team. They take joy in getting to work with other great people, and your family is a part of that. So don't try to hide that. 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 So it it's definitely something that you do need to have. So it's it's definitely something that you do need to have. So it's it's   it's   So it 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 1 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. Yeah. Definitely.  

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? 1 other concept  

[00:39:44] Unknown:

we found useful is the idea of feeling the pain. And that 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 1 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 feature is 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 gonna do the right things in response.   And it's just all the more 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 sourcegraph.com,   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?  



[00:41:14] Unknown:

And that's been a helpful way for us to communicate. Yeah. Making sure that you provide the context in 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  

[00:41:44] Unknown:

necessary. 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  

[00:41:54] Unknown:

when something is just an idea versus when something is important or else I'm gonna waste a lot of people's time. 1 other element of the overall employee experience and employee life cycle 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? Our number 1 worry when we went all remote and we were talking to a lot more people that had never been remote and trying to hire them to our all remote team was, you know, will this given person  

[00:42:40] Unknown:

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 wanna be all remote, then obviously they're not gonna be a good fit. And we have not seen anyone   lie or claim, oh, yes. I'd love all remote, 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 are all remote with respect to most of the people at the company that you work at once you have a lot of locations.  

[00:44:02] Unknown:

So, you know, none of this is new really. And 1 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.  

[00:44:26] Unknown:

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 3 or 4 really high quality days with them. And some of that time is going around and exploring a new city. Some of that time is, 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   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. Are there any other aspects of your experience of  

[00:45:26] Unknown:

managing a remote team or working remotely yourself or the overall topic of distributed workforces that we didn't discuss that you'd like to cover before we close out the show? 1 final thing is time zones.  

[00:45:37] Unknown:

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 time zone 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 place, 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 1 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 are different people at different times of day, so you will get to see your teammates  

[00:46:31] Unknown:

with a lot more energy or in a goofier mood and things like that. And that's pretty fun to see too. Alright. Well, for anybody who wants to get in touch with you or find out more about where 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 note taking 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 built in flexible sync capabilities. And so I've been testing that out. It 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? I have loved reading the book Skunk Works by Ben  

[00:47:18] Unknown:

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  

[00:47:32] Unknown:

that no 1 thought were possible when they were in the drawing board. It's been an awesome book, highly recommended. Alright. I'll have to take a look at that. 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. Thank you.   Thank you for listening. Don't forget to check out our other show, the data engineering podcast at data engineering podcast.com   for the latest on modern data management.  

And visit the site of pythonpodcast.com   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 host at podcastinit.com   with your story.   To help other people   find the show, please leave a review on Itunes and tell your friends and coworkers.