Season 1 Episode 2 May 20, 2020

How to Make Remote Work, Work


We dig into why DEV is a distributed company, and what the pros and cons are of remote work, with Sophie DeBenedetto, senior software engineer at GitHub, and author of the post, "My Long Distance Relationship With GitHub Transitioning to Remote, Async Work," and Mac Siri, senior software engineer at DEV.


More companies are considering going fully distributed, and with the COVID-19 pandemic, more and more people are experiencing working remote for the first time. Although there are a lot of benefits to remote work, it's not all flowers and sunshine. We speak with Sophie DeBenedetto, senior software engineer at GitHub, and Mac Siri, senior software engineer at DEV, about how to make being distributed work for you.


Ben Halpern

Forem - Co-founder

Ben Halpern is co-founder and webmaster of DEV/Forem.

Jess Lee

Forem - Co-founder

Jess Lee is co-founder of DEV.


Sophie DeBenedetto

Sophie is an engineer at GitHub where she works with a super talented group of people to build the tools that power the development cycles of teams around the world. She is a former graduate of and teacher at The Flatiron School and has a passion for coding education. That passion, plus her love of Elixir, has also led her to become a maintainer of Elixir School, a free, open-source Elixir curriculum. Historically she is a cat person but will admit to owning a dog.

Mac Siri

Mac Siri is a Senior Software Engineer/Open source maintainer at DEV Community. He enjoys maintaining, improving, and expanding DEV's Editor experience and functionality.

Show Notes

Audio file size





[00:00:00] SD: It just pushes you to grow and change so much faster because you’re not really able to hide, you’re not able to avoid accountability, and you’re not able to kind of obscure the questions that you might have or that you’re too afraid to ask.


[00:00:23] BH: Welcome to Dev Discuss, the show where we cover the burning topics that impact all of our lives as developers. I am Ben Halpern, cofounder of Dev.


[00:00:30] JL: And Jess Lee, also a cofounder of Dev. Today, we’re joined by Sophie DeBenedetto, a senior software engineer at GitHub, and Mac Siri, a senior software engineer at Dev. Thank you both so much for joining us.


[00:00:41] SD: Yeah, thanks. I’m really happy to be here.


[00:00:43] MS: Thanks for having me.


[00:00:44] JL: So Sophie, you’re currently working at GitHub and you wrote a great piece all about transitioning to remote work. The piece is titled “My Long Distance Relationship With GitHub, Transitioning to Remote Async Work”. Before we jump into your experience working remotely for GitHub, can you talk a little bit about your background before you were at GitHub?


[00:01:01] SD: Yeah, absolutely. So I’m still super new to GitHub. I’ve only been here like three, maybe going on four months. So before that, I was working at the Flatiron School, which started out as a software engineering intensive program, a bootcamp. We had just a couple of in-person courses here in New York and in recent years has grown to an online offering. We do data science, we do UI/UX design, we do all kinds of things. So I’d been working there. When I first joined their engineering team, I joined as an individual contributor. Both around about the time I left I had been in an engineering management role for a while, working with a couple of our different engineering squads. Before that I was at another company, but before that I was actually at the Flatiron School. So I’m a repeat Flatiron School offender or whatever you want to say. I used to work on the education side of things. A couple of years back, I was teaching, and I was writing curriculum. And back before that, I was a student at the Flatiron School. Yes. I graduated from there. So yeah, obviously I like it. I have many good things to say about it. I’ve participated in many forms of Flatiron engagement, and yeah, that’s where I’ve been in and out of for quite a while.


[00:02:12] JL: Awesome. I am also a bootcamp grad. So had you worked remote in any of your previous jobs before GitHub?


[00:02:19] SD: So not at all in the way that GitHub does it. Of course, I’ve worked from home and I thought that that was what it meant to work remote, but this is absolutely my first experience with a remote first organization and at such a large scale as well.


[00:02:36] JL: So can you tell us what you do at GitHub now?


[00:02:38] SD: Yeah, so I’m a senior software engineer at GitHub. I work on our insights team, which is actually a very new product that we’re still developing and I don’t think it’s generally available yet. It’s available to some of our enterprise customers and it’s a really interesting platform, basically it provides insights into how a team works and how it performs. And it’s very much focused on helping individual engineering teams and technical and business leaders figure out what works for their team and what doesn’t. So we’re absolutely not at all about things like stack ranking developers, which is bad and scary and more about empowering teams to set productivity and sort of working style goals for themselves and measuring themselves against those goals. For example, one of the insights that I’m a really big fan of that we expose is we actually have this really cool chart of viewing who views whose pull requests and who reviews whose pull requests the most. So it’s this really interesting look at what shape collaboration is taking on your team. And sometimes it reveals really positive patterns. Sometimes it reveals, “Oh no, these two people like only review each other’s PR.” It’s like, “Why is that?” It’s been really cool and really exciting.


[00:03:46] BH: Cool. I can’t wait to use that.


[00:03:47] MS: Yeah. That picture sounds both exciting and terrifying.


[00:03:51] SD: Yeah, my thoughts exactly.


[00:03:53] JL: Yeah. We definitely have suspicions of who gets the most PR sent to them and all of that. So this’ll be cool to see the actual data.


[00:04:00] SD: It’s definitely interesting because it shows you, I mean, if you think about it, there are sort of anti-patterns and code smells amongst our collaboration behavior just as much as there is within our actual code and this is something that would actually expose and help us iterate on some of that stuff.


[00:04:15] BH: I wonder if we need that more as a remote organization because it’s harder to get an intuitive sense of how people are working and what their flows are like. Mac, so you’ve been with Dev since before Dev was actually a company.


[00:04:27] MS: Yeah.


[00:04:28] BH: Can you share a little bit about your journey with us?


[00:04:30] MS: Before this, I was working as a shipping coordinator, work got a little boring. I learned how to script and then I joined the bootcamp, App Academy, and then, yeah, Peter, Ben hired me. Very early on, we worked on Argo.


[00:04:45] BH: Yeah. That was our old product.


[00:04:46] MS: It was a communication platform in the very early days. I remember sharing environment keys in GitHub README into the very bare bones and it was a lot of fun to work on, and I was really sad that we had to lay it to rest, moving to Dev. Of course, that was very exciting.


[00:05:00] BH: So when we first started working together, Dev was based in Flatiron New York, East 20th Street, all in one office, and now we're a fully distributed company, seven times zones. What was that like coming with us through that journey, Mac?


[00:05:18] MS: That was so bizarre. I still remember the days where I’m less than a feet away from Ben and Peter basically, and I can tap on the shoulder whenever I need help with anything. It’s definitely interesting to see your team grow and then suddenly having to move completely remote because our teammates are from across continents and communication style changed over time with writing messages in GitHub and pull requesting issues. We are more and more verbose than ever back in the day when pull requests, the title, so that doesn’t tell you what the work can be done on and the body is just nothing and now here we are writing long close to essays, describing why we do certain things. We used to ship things to production so fast. We lack CI back in a day. We lack proper tests. Our competence and our code base is improved so much over this whole time.


[00:06:12] JL: Something I want to point out during our transition from in-person to fully distributed is that for a little while, we call ourselves remote friendly, which meant that we like encourage people to work from home when they felt like it, but no one really took advantage of that. And then we became remote first. So Sophie, I’d love to hear what being at a remote first company is like versus, I mean, from our experience just fully distributed.


[00:06:37] SD: Yeah. That’s a really great question and I think I too came from a company that tried to be remote friendly, although now looking back, I’m wondering how successful we were at that. We encourage people to work from home. We had to work from home Wednesdays and of our maybe 40 some person engineering team, we had two people that will work full time remote and not based in New York. And I really feel for those people now, man. I really think we did not fully accommodate them and integrate them into a majority in-person team. But I think the difference that I’m starting to understand between remote friendly and remote first is it’s not just about physically where you are. It’s not that, “Oh, well, now I’m in my living room and they’re in their living room.” So we’re all talking on Slack and hopping onto Zoom. It’s that the communication, it’s not synchronous anymore, right? Just because you can shoulder tap someone on Slack or hop into a Zoom call doesn’t mean that all of the communication and the planning and the coordination and collaboration on work is still happening in real time. When you have people all over the world, you have people in different time zones, and so you have to foreground like an asynchronous working style, and that is something that I’m still struggling to kind of understand and internalize and see what that looks like in the day to day.


[00:07:57] JL: Totally. It’s been a struggle for us too. And we recently grew our team quite dramatically by doubling in size the past quarter and we finally codified some of our values and principles and one of our principles that is meant to help us guide our day-to-day decision making is to commit to async. And so that’s questioning whether or not we really need to coordinate across five different time zones and get everyone on a call or if we can use our existing tools like GitHub and like move something to an issue and have the conversation there. So yeah, I really resonated when you mentioned the async, because that’s not something that people think of and I think some companies, if they are a remote company, but they’re fully based in the US, it can kind of get away with just being synchronous and remote and I think a lot of times the async part just gets forgotten.


[00:08:46] BH: When we look at the conversation right now going on, obviously a lot of people in tech are rapidly going remote right now due to the pandemic. So this is really an industry worldwide issue right now as much as ever. And a lot of the conversation, in the tech ecosystem for folks not really sure what to expect is all about collaboration software, like Zoom and real time and all that stuff. And I think as companies that really embrace this asynchronous stuff realize that it’s not about the tools or the synchronous capabilities or just mimicking what you do in person. It’s about adopting workloads that account for what is the best way to work when everyone’s in a totally different context, everyone’s taking their own approach to their workday, and obviously working their own hours.


[00:09:41] JL: Going back to when we were in that remote first like limbo for us. So Ben used to be in New York, like myself, but then he moved upstate and it was really a moment where we started really committing to being remote, but we had an office in Dumbo for a while. And Mac, you were basically the last person to leave that office. And I recall like even being a little concerned just about going remote because I know that you enjoy going to the office and having that schedule. So would you mind sharing just your experience about going remote and maybe some of the challenges that you faced or some of the positive surprises that you have from working from home now?


[00:10:18] MS: Yeah, I remember that pretty clearly. I am a creature of habit. I really enjoy my commute in the morning, and I enjoyed pairing before sitting down and doing work in the office. So for roughly two months, I was alone in my team, in the office, and it was a very Zen moment for me. I find that I get distracted very easily working from home. I could not get into my Zen moment. It’s mostly because my mornings are very slow and I find it very difficult to mimic that at home to tell myself, “Don’t do work, “for 40 minutes after I wake up, and I go into this very self-destructive behavior of being online early and ending my day really late but also not being productive at the same time. What I’m given, like time constraint, I use my time more wisely when I do go into the office because it takes me an hour and an hour back home. I think it’s really just the way I’ve been since birth, spending time to go to school and coming home and suddenly you’re told that you don’t have to go anywhere anymore and do work at home. Now at first, I was very excited for it, of course, but I found it immediately. I use a tool to track how productive I am every day and it is [00:11:30] so much because I work from home. It took me about five months to figure out what works for me. And ultimately, I wish I figured it out sooner, but it took process, it took time, a lot of online readings. I do better work when I’m surrounded with people who are also doing work. I lift weights better when the gym's full and packed. Parks and Recreation, there’s an episode where they move people around the office and Tom was moved to work in the middle of nowhere on a different floor, and his boss said, “Tom only works well because he wants to impress other people.” I found that very funny when I first watched it, but now I feel like I can relate to that. I’m basically that. So I figured out that I should be going out. I joined WeWork for a little bit before [00:12:19] took over, of course. I try to be outside two or three times a week. And when I’m at home, I learned to disconnect at six and I changed my schedule around when I want to finish my day.


[00:12:30] JL: Sophia, in your post, you mentioned that you were kind of romanticizing the idea of working remotely before you had a remote job. Did it live up to what you’re expecting aside from the Async portion?


[00:12:43] SD: It’s so much harder than I expected it to be and I think it’s for exactly the reason that you were just mentioning, Mac Siri, it’s that you’re now accountable kind of only to yourself. I mean, of course, not only to yourself, you’re accountable to your team and you’re accountable to your business, but every minute it’s up to you. And there’s really nothing more terrifying than actually being in charge of yourself. So while on the one hand, I honestly do love being at home and I think all the things that I looked forward to, being able to have a more flexible schedule, being less stressed out by the commute. I don’t know about you guys, but commuting in New York just really bums me out. It’s incredibly stressful, being able to have that flexibility, being able to spend time with my dog, being able to spend time with my partner, being able to kind of do other things in my life and have a little bit more freedom and flexibility to do that is all wonderful, but I also feel this like weight on me, this little imposter syndrome, like demon keeps popping up like, “No one’s watching you.” Like, “How will anyone know that you’re actually good at this job?” Like, “Are you even contributing?” So what I find myself doing is pushing myself way harder than I think sometimes is really helpful for myself or for my team. When there is no place to go at 6:00 PM, there’s no like, “Well, if I don’t leave now, it’s going to take me such and such an amount of time to get home.” There’s always one more thing that you can kind of convince yourself to do if you’re feeling unsure of how you’ve contributed and how productive you’ve been. So having to sort of get comfortable with that insecurity and having to figure out for yourself what productivity looks like in a given day, in a given week, it’s an enormous responsibility. And I think that I didn’t realize that that was going to happen. I didn’t take it as seriously. I didn’t know that there’s going to be this extra challenge involved.


[00:14:28] MS: Yeah, I can definitely say right now I’m like coming up on eight hours of work today and I still have things I’d plan to get done that I haven’t done yet and it’s actually probably a good reminder that I can probably do that tomorrow. A lot of days you think like, “Oh, I’ll just push this another half hour, another 45 minutes.” And before you know it, you’ve been working all day.


[00:14:51] SD: All day, all night because you don’t see all of your colleagues getting up and putting their shit away and putting on their backpack and saying, “Hey, are you going to come down with us?” Like that type of accountability is not there. So I think it’s easy to push yourself too hard. Absolutely. And I think it’s an individual struggle for sure. It’s something that each of us has to come to terms with and get comfortable with as an individual, but I think it also has to do with how challenging it is to do things like sprint planning and project planning when you are remote first and when you are async. That’s been a real challenge to kind of see and adjust to and GitHub is starting to actually see and understand where this planning happens, how prioritization is getting decided, what kind of work is being done to spec out a certain project, how I can plug in and how we can, as a team, share responsibility for delivering on our goals when we’re not all in the same place at the same time. Letting that kind of planning and that sharing of responsibility unfold in an asynchronous manner. Leveraging written tools like user pull requests or project boards is very new to me. I think it’s something that’s very difficult for teams to get right. I think even the most experienced remote first async team is going to always kind of struggle to walk the right line between independently plugging away at one’s work and figuring out how to plan and collaborate together. And I think that definitely contributes to individual struggles to kind of figure out and evaluate one’s own productivity.


[00:16:23] JL: The topic of overworking is something we discuss pretty regularly at Dev, at least amongst the leadership. I’m curious if you feel if GitHub has done anything super helpful to help their employees not reach that burnout, overworking point, like I’ll describe it as like 24/7.


[00:16:42] SD: So the first thing I’ll say is that the GitHub organization overall is so supportive of people’s individual needs. And I think one of the things I’ve been especially struck by lately with everything going on in the world with COVID-19 is the way that the organization has adapted and adjusted to the needs of its members, especially as people are dealing with, homeschooling or their own health or even just stress like everyone from the absolute highest up, our CEO down to your individual manager is working really hard to make sure that the messaging is there and the tools are there for people to take the time they need to take care of themselves. And I think that just characterizes the tenor or like vibe, if you will, of the organization overall. My coworkers, I think demonstrate pretty good practices and I’ve got to kind of push myself to adhere to them as well like setting their schedules in their calendar and putting things in there. Like Jim, like, “Put the time that you’re going to the gym on your calendar and no one will bother you and it’s totally fine for you to do that at whatever time you’ve decided to go or like pick up kids from school, this, that, and the other thing.” So I think it’s kind of baked into the habits and practices of the overall org. And I think I’m just trying to, I’m trying to get with the program. It’s tough too because I’m somebody that always just likes to have a million things to do and then paired with like, “Oh, I’m new and I want to make sure that I’m contributing and doing a good job.” All of that stuff is pushing me to push myself, but I think the organization, my team, my manager, have all been very supportive and demonstrated how people can and should take time to take care of themselves.


[00:18:29] BH: Jess, do you want to talk about some of the challenges we face as employers, as managers, trying to get some of this stuff right?


[00:18:35] JL: Something that most people probably don’t think about is taxes. We work with a PEO to handle our payroll, so it makes life very easy, but there are moments when we’re hiring from people across all 50 states and abroad, and we just have to be on top of all of the tax requirements from different states. And another con is that a lot of the literature out there about taxes and building a company just assume that all of your employees work in that same state. So it’s still very new. And so there just really aren’t that many resources right now. And of course, time zones can be difficult. We went from everyone being on the East Coast of the US to now being across seven time zones and it’s impossible to get everyone in the room without stretching somebody. And so something that we had changed when we grew the team was have all hands once a week, whereas in the past we used to have two meetings where we gathered the entire team and now we just have one and all hands meeting we have now is rotated across three different time zones so that everyone will probably miss one meeting, but that way we can have coverage across all the different time zones and that no one is like constantly put out and having to jump on like an 8:00 PM call.


[00:19:53] BH: I’d say some more challenges as well as managers are to make sure that we’re getting enough rest. I think we tend to stretch our schedules to make sure that we can meet with everybody. Some folks are going to be more online right in the early morning for us. Some folks will actually be starting their days like later at night and it’s certainly not impossible for us to meet with everybody and not spend really long days. But if we don’t really plan ahead and plan around it, we can find ourselves really stretching to make sure we sort of coordinate well and touch base with people. And in our day to day, we’re mostly async, and it’s not really a thing, but as managers, there’s just different times when you might want to get in touch with people and we sort of have to stretch ourselves and it’ sort of a work in progress and kind of almost like Sophia was saying about sort of stretching yourself to impress. As managers, we want to make life easy for everyone on our team as opposed to making everyone adjust to us sometimes. And it really can be a stressor over time if you’re doing it too often for too long. For me, that’s one of the little things of managing a bunch of folks across different time zones is just thinking about everyone and making time for them and just being on top of it all.


[00:21:10] JL: How do you all run retrospectives at GitHub? Because that was something that we were trying to figure out. We operate on a six-week project cycles, but we still want to have that place for feedback and collaboration without just getting everyone in the room.


[00:21:25] SD: Do you guys aim to do your retros at the end of your six-week project cycle?


[00:21:29] JL: Yeah, that’s how we’ve been doing it.


[00:21:31] SD: So I mean, there definitely isn’t a one size fits all that I’m aware of, at least retro style or guide at GitHub because it’s just such a big organization and there are so many different independent departments within our engineering work. My team also does retros not on a weekly cadence. We do them, actually, I think we’re struggling a little bit because now that you’re asking this, I’m like, “Oh my goodness! When was the last time we had a retro?” We do them, I think we had started doing them once a month, then we wanted to do them once every two weeks, and now I think we may have forgotten to schedule the next one. But we do conduct our retros in person. So those are like a synchronous kind of touchpoint within the cadence of our development cycle. And we use GitHub project boards for our retros, just like we use them for all of our other kinds of sprint planning and agile activities. And the GitHub project board is super similar to, if you’re not familiar with it, it looks like Trello or it looks like Pivotal. There are swimlanes, and I think we do things like, I’m going to get the exact column names wrong, but you get the idea, happy, sad, puzzling, maybe action items and then we do sort of like a period of silence where people are contributing their items as cards within a swimlane and then we upvote them. There’s a facilitator, not from a team member, but from a TPM, which is a Technical Project Manager, which is a separate department within the GitHub engineering org that kind of comes in and helps facilitate and kind of handle development cycle, life cycle rituals. So I’ve also really enjoyed working with, this is not at GitHub, but at Flatiron, the RemoteRetro app, as well as the So really anything in my experience where people are able to contribute cards to a board and a facilitator can kind of aggregate and review and guide a conversation through those cards within topics. We haven’t done, anywhere in my experience, a retro that isn’t synchronous. That’d be something I’d be curious to hear people’s thoughts on because I feel like as much as we want to sort of lean into asynchronous communication and lean into asynchronous work styles, I think when it comes to feedback and when it comes to performing a retrospective on a cycle of work, I think there are some things where you kind of just have to be in person and having these conversations, but I’d certainly be curious to hear your guys’ thoughts on that particular question.


[00:23:54] JL: So we did attempt to do a fully distributed async retro for our most recent project cycle. And we basically sent out a survey for people to share their thoughts and then that was posted publicly amongst the team. And I had this grandiose idea of people commenting on each other’s posts to like engage and have that element of it. But that didn’t really happen. And so what I ended up doing was going through all the surveys, pulling out the most common topics, and then just dropping it in Slack and having people vote through there. And then for our next all hands, we discussed some of those topics in-person synchronously. So yeah, I think it really is a balance. Like I mentioned, not everyone can make it to our all hands, so not everyone got to participate, but hopefully they got to participate in the written portion and that people got to like read their feedback from that.


[00:24:50] BH: Yeah. Given that not everyone can participate in our all hands just by design, it ends up being a bit of a synchronous, asynchronous mashup where some people get to participate more synchronously sometimes, others more asynchronous. We get to kind of discuss some of the asynchronous feedback with the people who are there and then sort of loop in the other folks afterwards, and because it’s different people every time, it’s kind of an interesting dynamic. I think like understanding that some people are going to be more asynchronous some of the time and some people are going to be more synchronous.


[00:25:24] JL: If I could find an eloquent and concise way of updating our commit to async principle, it’d probably be something like, “Commit to async, but don’t be afraid of synchronous communication,” just to capture that spirit.


[00:25:38] SD: I’m actually really glad you said that because I feel like, at least within my team, I think sometimes we’re trying to be so vigilant to foreground async that we resist sync even when it is appropriate or helpful. We just kind of have internalized like async good, sync bad. Nothing is black and white like that. So I think one of the questions that I’ve been thinking more about lately is, “What does collaboration look like when async is the priority?” Does that mean that you don’t collaborate? Absolutely not, but sometimes it’s easy to fall into that mindset that like async, therefore, means like independent, and I think that’s like a false equivalency that we need to really push back against.


[00:26:17] BH: Do you want to talk about some of the main benefits of working async, working remote? We’ve sort of covered a lot of the challenges, but I don’t think we’ve given enough credit to kind of how great some of it can be and why we as an organization did it in the first place and why GitHub did this.


[00:26:32] SD: Yeah. So I would say that the ways that I’ve been challenged and the ways that I have grown as a team member, a collaborator, and also as an engineer, just in the past couple of months alone, have been truly astonishing to me. And I think it’s the kind of like push that I just wouldn’t have gotten in an in-person environment. And I don’t mean to say that like, “Oh, you’ve got to work remote if you really want to grow.” But you kind of can’t hide the things that you’re confused about when you have to write down all your questions in a public forum. You can't hide behind the fact that you’re a little bit unsure about a certain approach or you’re not totally clear on how something works or you don’t want to take ownership for something. It really forces you to take ownership for projects. It forces you to expose all the questions that you have publicly and clearly articulate them. Otherwise, you really have no hope of being able to deliver on what you’ve committed to. And then just that act of writing and kind of taking that step to put out there what you don’t know and what you need help with, it forces you to have a deeper understanding. And this is something that I also thought a lot about as a teacher because we would actually require not just encouraged, but require our students to produce a certain amount of technical blog articles before they graduated. There’s really no better way to learn something than having to explain it in writing and having to sit there with your thoughts and really think it through and then having to expose it for feedback and potentially criticism. It just pushes you to grow and change so much faster because you’re not really able to hide, you’re not able to avoid accountability, and you’re not able to kind of obscure the questions that you might have or that you’re too afraid to ask.


[00:28:10] JL: Mac, what are your favorite parts about being remote?


[00:28:13] MS: So I used to try to answer all Slack messages immediately. The immediacy of, yeah, it’s just the way I am and being told that we are async gives me the confidence to mute my Slack or close it without feeling any shame and I can focus on my deep work more enjoyably. And it’s good to know that our teammates understand that I will get back to them when I can. It doesn’t mean that wait till tomorrow, but it will still be on the same day, of course, when I finished my work.


[00:28:48] JL: Ben, I know there are a lot of companies around the world who are very skeptical of being remote. Can you speak to some of the positives from the company’s perspective?


[00:28:57] BH: We were pretty big on this idea right from day one. We knew it wasn’t very practical as we were just sort of figuring stuff out, and we were all based in New York to really try to do this from day one, especially since we really have no idea what you’re doing on many fronts and trying to go fully distributed. Async would have been quite a challenge in its own. But the product we’re building is a distributed asynchronous communication tool. It’s global. We really wanted our style to reflect that same ideal and we have such a diverse candidate pool. Whenever we look for new folks to join our team, we’re not fighting over this condensed pool of people who might be able to kind of work for your company or like the six people in the city that really share that skill. We don’t really feel like we’re constrained like that. We don’t have to spend money on an expensive headquarters and we get to give that back in terms of being more liberal with our expenses policy in general, in terms of equipment, travel for conferences, et cetera. That’s kind of where we put that budget that otherwise might’ve gone towards rent and stuff like that. We also sort of get some niceties of basically like 24/7 coverage by default in terms of people online to find out if the site’s down. We don’t have entire uniform coverage in terms of permissions, in terms of who might be able to actually look into any issues and stuff, but we don’t have to rely blindly on automated tools to wake us up in the middle of the night if there’s something wrong. So there’s kind of a lot of benefits that just make it more efficient, more scalable, more resilient, and we were pretty bought into the idea that if you can make it work, this is the future. It’s been really great to sort of lean into this stuff.


[00:30:43] JL: So GitHub is obviously a huge, wonderful tool to facilitate remote and async work. But Sophie, what other tools do you use that has helped your workflow and your team?


[00:30:53] SD: So I think GitHub really is the answer. I mean, I’m obviously biased to say that, but we do try at every turn to leverage the tools that we are building and maintaining ourselves. So we use issues to house planning discussions and technical research spikes and discussions over technical implementation. We use GitHub project boards to manage our iterations. We have like a current iteration board and a backlog board and different swimlanes within those boards. We use GitHub project boards for our retros as well. We take advantage of a little system that we’ve kind of cooked up called like tracking issues. So we’ll label an issue as a tracking issue and then that issue will get sub tasks linking out to other issues, which if you’re familiar with JIRA, you might think like Epics and Tasks. So I think as a team and as an organization, we very much just try to use GitHub for what we’ve designed it to do, which is enable diverse and distributed teams to collaborate effectively. Beyond that, of course we use Zoom and of course we use Slack. I am also personally a really big fan of Notion, and I will talk your ear off about Notion if you let me. Notion is just like a really great, it’s sort of everything tool. It does project management, it does note taking, it tables and databases, and it’s becoming more powerful by the day, in my opinion. So I kind of use that to take my own notes and help me organize my thoughts and my different areas of work. Not that our project boards can’t really do that, but sometimes just helpful to have your own notes and feel like you’re summing up your day or starting off with a nice list of to-dos in the morning. But yeah, honestly, mainly it’s GitHub.


[00:32:23] JL: Mac, you mentioned using a tool to track your time. Are there other tools that you use?


[00:32:28] MS: My personal note-taking/list tool is Dynalist, which is a very dynamic tool generating note-taking app. And I would say that GitHub project is probably my recent favorite in terms of keeping track of what the team is up to and what other teams are. What I think about going from a team of 4 to 5 to 22 is that I used to know every PR that’s merge into the code base and now I’m losing touch with that. And it’s good to get a good idea of what’s going on with the other teams with GitHub project. I think the time tracking, I suggest everybody gives time tracking a try. You mostly download and just let it set and forget it and at the end of the week you’ll get a report to see how productive you are at a particular time of the day and what day of the week and it makes you think about, “Maybe I should do most important work at that time,” as opposed to when you should just wake up right away. So I found out that I’m more productive toward four to six o’clock at the end of the day and that trend stop being the case in the summer. So depending on a season, you may not be productive the same day of the week every single week.


[00:33:40] BH: That’s interesting. In terms of tools to contribute to this conversation, I think it’s also really important to be deliberate about how you use tools, especially as a team. There’s definitely a lot of people saying that you should definitely not use Slack if you’re looking to be asynchronous because it forces the synchronous conversation. And I would say that like the way we use Slack in combination with GitHub and Notion and sort of the way we use it all I think has worked fine and I wouldn’t give up the ability to have this more sort of quasi-synchronous drop a quick kind of thought element where you can kind of like get an idea out there without having to commit it to a whole GitHub issue, which maybe sometimes seems a little bit like higher mental bandwidth in order to sort of come up with that asynchronous workflow. So I’ve been happy just with our principles of committing to async while also maintaining a tool set which could otherwise trap you into synchronous work, but I think it has worked for us the way we use it.


[00:34:40] JL: I will admit that I have fantasized about just removing Slack from our organization altogether for a week and seeing just what happens. I’m very curious how we’ll lean into different tools in which ways and whatnot. But to your point on being deliberate about how you use your tools, something that I’ve really enjoyed the way that the Dev team has worked is that whenever we are working on a shared document, so say we’re hosting a change blog post about a new feature, we would bring that into Google Docs and have the collaborative elements there. And then once everything is finalized, we move it into Notion as our like source of truth and that just comes from most people on the team feeling like Notion collaboration and like that. Their like commenting system is not as easy to use as Google Docs, but just having that shared understanding makes it a lot easier for people to find the information that they need.


[00:35:54] BH: Okay. Let’s move to a segment where we ask our audience, you, for comments related to this episode.


[00:36:00] JL: So the question we asked this week was, “Do you have a remote work or remote co-working space horror story to tell?”


[00:36:08] BH: So the first comment we got was from user Delev Dev. Well, recently, my brother and I split rooms. So I put my bed, set up tools in my room, and while my wardrobe was still in my brother’s room, mind you, he’s a tech lead. So one night I was getting ready to shower. I take off almost all my clothes, walk into his room to get my PJs. The man was video conferencing a potential candidate to his company. I’m not sure if I’ve provided enough incentive for him to join.


[00:36:37] JL: Not safe for work. Sophie and Mac, do either of you have a horror story to tell?


[00:36:42] SD: I don’t have a horror story so much as like the positioning of my computer and my work from home environment is sometimes a little strange. So I don’t have my own office in our apartment. I just kind of set up every day at the kitchen table, which is fine, like I have a desk chair and I have a little stand for the laptop and all my nice ergonomic things. But my partner is an artist and she’s been working on this enormous canvas that basically takes up the entirety of the living room wall that is right behind exactly where my camera puts me. And the painting, it’s not that it’s NSFW, but it is a bunch of horses and my head ends up positioned like directly in front of this enormous horse butt. Sometimes I sort of remember and like move a little bit or I’ll make a disclaimer, like, “LOL! Look at this horse butt behind me.” But sometimes not and I’m just like if you’re feeling tired or I’m just like over it, I’m like, “I don’t care. Y’all are going to be wondering what the heck is behind my head, but I’m used to it.”


[00:37:41] JL: That’s awesome.


[00:37:42] MS: My house, the wall is pretty thin, the door is very thin and my room is right in front of the bathroom. So if my family member is home and if they flush, my mic is very sensitive, it might come through to my Zoom call, very embarrassing. I use push and talk so I try to mute myself as soon as possible, but occasionally it’s slipped.


[00:38:07] JL: Okay. So Lee Wynn wrote in and they said, “Well, this week I was hosting a really crucial, at least in my mind group, video conference call with lots of important people. Anyway, the call lasted 30 minutes. One minute and one of my kids sends a mega print job to our wireless printer, which is 10 inches from my head on a shelf. And I basically had a brain seizure as I carried on talking and what sounded like a machine room with paper endlessly shooting off the shelf behind me. They kept printing for like 10 whole minutes. FacePalm.” That was her comment, and I personally have never experienced anything like that. But when Lee mentioned their children, I don’t know if any of you have seen it, but do you remember that BBC News interview where this person’s talking on camera in their home office and then their toddler just comes like waiting in.


[00:39:00] MAN: What will it mean for the wider region, I think one of your children just walked in. I mean…


[00:39:00] JL: And then like two seconds later, somebody else like runs in and like drags the child by the like legs and out the door.


[00:39:11] MAN: I would be surprised that they do. Pardon me. My apologies.


[00:39:22] MS: I remember that very clearly.


[00:39:23] BH: Yeah. That’s like the classic remote work horror story of our pop culture.


[00:39:27] JL: You’re like streaming live, so God knows how many people.


[00:39:30] MS: Without kids, I think my equivalent is our dog, Ruby, who sometimes just really thinks it’s her time to get fed and will not be very quiet about it.


[00:39:42] JL: Oh yeah. I’ve heard Ruby many times. Do either of you have any advice for folks who have just found themselves working from home, even though that’s not their norm?


[00:39:52] MS: My siblings are working from home for the first time ever, and then they found out that their managers don’t really trust their productivity at home. They need to clock in and clock out. It’s bizarre to be relying on email to be emailing your manager that you are online and it went to sign off and when you’re going for lunch. I don’t really have a solution for it, but I definitely told my brother that you don’t have to be very strict about when your lunch is going to be. As long as you get your work done and you make sure that your manager knows that it is being done on time, you don’t have to be so strict about when to be on and when to be off. But of course, that’s different with everybody.


[00:40:35] SD: In a similar vein, I think it’s important to find a source of stability for yourself, whether you’re someone that’s going to put a lot of pressure on themselves to work a lot or whether you’re someone that’s going to struggle with productivity because I do this too, I sit down and then I opened Twitter and then I don’t know what time it is when I maybe actually go back to that project board. Identify what it is for you that’s going to make you feel like there’s kind of a stable cadence to your week, and it doesn’t even have to be something that is part of the work you do for your paid job. It could be that you’re reading a certain book or taking a certain course and kind of weaving that into the steady pace of your week. I think just finding something that you can rely on and look forward to is just going to help you pace out your days, parcel out your time and just be kind to yourself and not too down on yourself when you’re evaluating and struggling with your own productivity in any direction.


[00:41:31] BH: Sophie, Mac, thanks so much for joining us.


[00:41:34] JL: Yeah. Thank you both so much.


[00:41:35] MS: Thanks for having me.


[00:41:35] SD: Thanks for having me. It’s been so fun.


[00:41:46] JL: I want to thank everyone who sent in responses. For all of you listening at home, please be on the lookout for our next question. Also, we’d love it if you could dial into our Google Voice. The number is +1 (929) 500-1513 or email us a voice memo so we can hear your responses in your own beautiful voices. This show is produced and mixed by Levi Sharpe with editorial oversight by Peter Frank and Saron Yitbarek. Our theme song is by Slowbiz. If you have any questions or comments, email [email protected] and make sure to join our Dev Discuss Twitter chats on Tuesdays at 9:00 PM Eastern, or if you want to start your own discussion, write a post on Dev using the #discuss. Also, please rate and subscribe to this show on Apple Podcasts.