Moving to Remote Development (and Work)

0:00:05 Hi, and welcome to the A16Z podcast. I’m Doss, and in today’s episode, Jason Warner,
0:00:12 the CTO of GitHub, talks with A16Z General Partner David Yulovic about the best and worst
0:00:18 practices of remote development and, more broadly, remote work. Shelter and place orders have more
0:00:23 companies making the move to remote faster than ever. So is this our new normal? And is it the
0:00:29 future of work? In this hallway-style jam, the two discuss the tools and strategies for communication
0:00:35 and alignment, what does and doesn’t work, from demos to burn down charts, and end on some reflections
0:00:41 given the current crisis. They begin, however, by talking about where location does, or maybe we
0:00:48 should say doesn’t come in. I’ve been a remote executive now for just over 10 years, and I myself
0:00:53 have never lived in San Francisco. I wonder how many people list their location on LinkedIn as the
0:00:59 San Francisco Bay Area, but don’t actually live here. I’m sure it overcomes the Silicon Valley bubble
0:01:04 bias of everyone having to be here, which I guess is what we’re talking about today. I think my career
0:01:08 would look very different if I didn’t put San Francisco on at one point. That’s really interesting.
0:01:14 I wonder if that’s going to change in the future. I hope it does. I really do. You can get more
0:01:19 efficiencies in your business. You can have better access to talent. And Silicon Valley has a bias
0:01:25 towards them being the best of the best. But the world has moved on from that. And I think what
0:01:30 you’re going to find too, and I think we will find this in time in this next decade, is that
0:01:36 the access to talent is the only game that really matters in the next 10 years.
0:01:41 The aperture will open for roles that previously people thought couldn’t possibly be done remote,
0:01:46 that this particular role had to be in the office. And then now, of course, that role is working
0:01:50 because it’s remote by definition because we’re in this moment in time. Jason, what are the dynamics
0:01:55 that you’re observing, I think both in this moment in time and then more broadly?
0:02:01 So I think the most common thing that I’ve seen when people try to go distributed and remote as a
0:02:09 company is that some of the worst human behaviors or tendencies tend to get amplified. So as an
0:02:15 example, if you are a person who is prone to gossipy type of stuff, you might seek out more
0:02:21 gossip. If you’re prone to anxiety and you worry about your job, someone not replying to you in
0:02:27 an instantaneous basis might give you heartburn. However, the worst one is micromanagement. If
0:02:33 you’re a boss who micromanages people when you’re in the office, it gets amplified 100 times remote
0:02:41 because you tend to “want to check in to see how things are going” or reopen decisions. Typically
0:02:46 to think about what the behavior mechanism of micromanagement is, it’s lack of either transparency
0:02:52 inside of trust. So figure out which one of those it is and fix that. How you fight that as a tendency
0:02:57 is you really have to clear up your lines of communication. What are you doing for why? How
0:03:02 are decisions being made and ratified? Who has the decision-making authority? How are we tracking
0:03:07 progress? Do you have the right structures, meetings, cadence, or updates that you need
0:03:12 to feel confident that things are moving in a direction? I think the ability to go
0:03:17 to a remote workforce for me as a leader means the ability to hold people accountable who aren’t
0:03:21 directly in front of me and know how to communicate over various communications mediums that don’t
0:03:26 involve just walking over to their desk and annoying them, which is manager 101. Sometimes
0:03:31 when you see somebody face-to-face all the time, you can write off that quick one-line email that
0:03:34 might be a little bit snarky or they might misinterpret because you’re going to see them
0:03:38 the next morning. But when somebody’s working remote, you start to put more context around
0:03:43 things and you start to say thank you and please, you can’t just see them in the morning and say,
0:03:47 “Oh, hey, sorry about that email last night.” I found that to be one of the most interesting
0:03:52 transitions for me personally. I got a lot better about communication in a remote company,
0:03:58 distributed company, really fast. And as you said, more context, a little bit more empathy
0:04:03 about how we read. And next thing you know, you have a whole bunch of autonomous leaders
0:04:07 emerge out throughout the company. Something I want to advocate for when people think about
0:04:12 distributed work is the types of communication channels that they need. Basically, if you’re
0:04:17 going to optimize for the fullness, you’re going to want three. But if you have to choose one,
0:04:23 choose async memorialized communication. So we will always have email. That will never go away.
0:04:27 And I don’t consider that part of the tool discussion. That just is. However, when I say
0:04:30 async memorialized, I mean things where you basically ratified decisions and threads and
0:04:35 you’ve locked them and they will stay there as your institutional memory. So that’s the first.
0:04:41 I think the second one is video calls. And then the third one, which is the one that most people
0:04:47 reach to first is something like Slack or IRC or any of those things. I think that should be your
0:04:52 third. That should be the optimization that you have and you never treat it as institutional memory.
0:04:55 I don’t think those tools are set up to be institutional memory. Backscroll is the worst
0:05:02 way to go find out the context to a conversation. I do think that you can use it for in real time,
0:05:07 slight communication between a couple of different people. But then once the decision’s made in that,
0:05:10 it should be ratified and memorialized in a different system.
0:05:15 I agree completely with the memorializing sort of in situ and the tool that you’re using. So if
0:05:19 it’s code and product decisions, maybe that’s in GitHub. And one of the things that’s been
0:05:25 interesting to observe over the last few years is that many, many tools, especially SaaS tools,
0:05:30 they’ve sort of been including more and more multiplayer support. But what we’ve observed is
0:05:34 that they’re actually adding more and more of the collaboration into the tool themselves. So for
0:05:41 instance, people that use Figma, they are commenting and talking about the Figma files directly in Figma.
0:05:46 Now, as it moves over to marketing and product marketing and other people in the organization,
0:05:50 away from the designer and into engineering and other aspects, all that comment history of like,
0:05:54 how did the design end up the way it is? Or why did we make this decision the way we did?
0:05:59 Is in that file and it stays there forever. And that’s super powerful. The downside is people
0:06:04 sort of have more places to look for commentary and things. The good thing is that the metadata is
0:06:10 now sticking around with the content itself, which is quite powerful. One comment about Slack that
0:06:15 I’ve observed with the companies that I work with that are distributed is that Slack ends up becoming
0:06:20 a notification mechanism for them. So, you know, obviously it has that water cooler like capability
0:06:25 that a lot of people use to talk about things real time and sort of synchronously. But it also
0:06:30 takes on this notification mode where all these tools where things are being memorialized or
0:06:35 being discussed sort of in situ, then get sort of centralized back into Slack for people that are
0:06:39 sort of just boy years and want to know what’s happening but aren’t maybe engaged in the day to
0:06:45 day. I have seen the exact same thing, which is Slack in particular is it’s a pinch point,
0:06:50 essentially every other system flows into it, updates it, then goes back out. And then people
0:06:56 stream all that stuff together. Just as basically GitHub and Slack can become platforms for exchange
0:07:02 of information, I imagine you’re going to see a lot of new tools emerge and basically say, okay,
0:07:08 hit this button, it’ll sync to X, Y or Z system. In fact, this may seem like a subtle point,
0:07:13 but turns out to be an important point that collaborating and discussing and working through
0:07:18 something in one tool is not the same as memorializing a decision in a way that
0:07:21 the organization can sort of keep that memory of it and make it easily accessible.
0:07:27 When you memorialize a decision, it only counts if everyone else knows about it. The other thing
0:07:31 is when things start to get memorialized, it allows new people to get up to speed more quickly. And so
0:07:36 that ends up being sort of a tailwind that just benefits all future people that join the company.
0:07:42 And so as these tools are creating sort of the collaboration inside the individual tools as
0:07:48 opposed to outside the tools, I do think it actually becomes more important to define where
0:07:53 decisions get memorialized, whether it’s in sort of like a wiki page inside of GitHub or
0:08:00 Confluence or Notion or whatever it is. So my approach has typically been you can choose Y tool
0:08:06 or Z tool if you want to do your local development practices, whether it’s tracking story points
0:08:11 or using Kanban style or so if you’re choosing Trello or Asana or something like that and you
0:08:14 want to track your stuff locally for your team there and you want to experiment with it. I’m
0:08:19 not going to stop you from doing that. However, the organizational institutional memory is going to
0:08:24 live in X. You can do yours locally and then you have to actually memorialize decisions or all those
0:08:29 things in the system of record. And that’s how we’re going to know what’s going on. I find that
0:08:34 works better as organizations get larger. If you’re smaller, I usually just say we’re all going to
0:08:39 live in X. Sorry, we’re not going to entertain other tools at this point. When people ask me about
0:08:44 habits of remote companies and I said, well, they’re just really habits of great companies.
0:08:50 And I want everybody who logs in in the morning to know exactly what they’re working on, why and
0:08:55 for whom. And that starts at the top and starts with context communication. And then you have to
0:08:59 have the swing all the way back up is are we actually doing it? Are we making progress? Are
0:09:03 things actually advancing? And the mechanisms by which you achieve those things are going to make
0:09:09 you a great company, distributed or co-located. And if you think about another aspect of leadership
0:09:14 in general is everybody in the organization is making the set of decisions that only they can
0:09:18 make. So if you’re the CEO, there’s a set of decisions that nobody else in the company can
0:09:23 make only you can make them. So you do, you make those decisions. And then every other decision
0:09:27 that somebody else can make is delegated to that person and et cetera, et cetera, all the way down.
0:09:33 But that only works if you are transparent enough and sophisticated enough with your
0:09:37 mechanisms to say, I’m going to make these decisions. Here’s our goals. Here’s our
0:09:40 measures. Here’s how we’re going to measure progress, all that sort of stuff at each one
0:09:45 of those levels. I paid attention to a project on GitHub called Home Assistant. And they’ve now
0:09:51 incorporated a ton of sort of automation, not just around is this code fitting a certain code
0:09:56 formatting policy, but also they now have these mechanisms like does this fit with our values?
0:10:00 And somebody has to sign off on that for the issue to get closed. Does this support all the
0:10:05 internationalization that we’re looking to do? And somebody who’s approved elsewhere quote unquote
0:10:09 in the organization has to sign off on that. And the issues get sort of redirected. And there’s a
0:10:14 bunch of bots that coordinate and facilitate all this. And so the mechanism of working in a
0:10:19 distributed way is being facilitated by technology in a way that I’ve never seen before. And I really
0:10:24 think that was driven by the open source community as you embrace source code revisionary kind of
0:10:28 paradigms and apply the dollars on the things that anybody can do a poll request and have it
0:10:34 reviewed and evaluated and considered or being able to fork the organizational code to improve it.
0:10:40 That feels like it breaks down these weird hidden power structures that sometimes can
0:10:44 emerge in very old or very large established corporations, which is basically like, hey,
0:10:48 we need to go do this. You’re like, oh, the only person who touches that bit of code or can make
0:10:53 that decision is X person. And you have to talk to the right people to go find out who that person
0:10:59 is. Instead, open source has basically built mechanisms for that. When you put an issue into
0:11:05 GitHub and it has this keyword into it, somebody automatically gets tagged who is responsible
0:11:09 for that. And then they’re notified and they have to go comment on the issue and have
0:11:15 discussion about it. I think the feedback loop mechanism of lowercase a agile is incredibly
0:11:20 important, which is it’s the only time that I’m going to find out how things are going is when
0:11:26 it’s released or at the end of a sprint or at the end of a quarter, the classic project management
0:11:31 red, green, yellow type of approach as probably not the right mechanism. So I’ve just introduced
0:11:37 a couple of different things. One is for remote stuff, obviously you want to have somebody responsible
0:11:42 for updating the progress of various projects, products or whatever across the organization,
0:11:47 particularly the ones that are interdependent upon other teams or organizations. The other is I like
0:11:54 to do review meetings now. And in those meetings, I’m getting updated on very large or ambitious
0:12:00 projects on a regular basis. And particularly I’m trying to edit in that meeting, not author.
0:12:05 So it’s really a time for me to either course correct or get updates. I also like the organization
0:12:12 to feel the same sort of progress. So I ask teams to give regular updates to the organization on a
0:12:19 weekly, bi-weekly or at most at absolute most monthly basis. And I ask them to do a write up
0:12:24 with a video demo of the progress that they made in that time period. I have not personally found
0:12:30 things like burn down charts to be that effective. I just think we as an industry are not great about
0:12:34 estimating progress. I agree. Things like burn down charts are sort of useless because they get
0:12:39 gamed, but just demoing very, very regularly creates those loops and those opportunities for
0:12:44 people to course correct and edit. I personally love demos. I get excited by them. I think the
0:12:47 organization gets excited by them. And I think there’s a forcing function. If you do it on a
0:12:52 regular time interval, you have to think a little bit of like, okay, how are we actually going to
0:12:59 showcase progress here? Because one of the worst habits I’ve seen of very large engineering teams
0:13:03 or large scale engineering efforts, large scale, maybe infrared ones or operating system ones is
0:13:10 to say we can’t actually demonstrate progress for months, which we all know from the way that
0:13:16 software can be written is that is never true. So the job now becomes how do you actually demonstrate
0:13:21 progress in a shorter amount of time? But also this is not just an engineering thing. It can be all
0:13:24 parts of the organization. So when people are listening to this podcast and they’re saying,
0:13:29 oh, that’s great for demoing some code or, you know, a new UI somebody built. It’s absolutely not
0:13:34 just for that. It’s for anybody in the organization. I’ve been lucky that superhuman Rahul Vora, the
0:13:39 CEO, lets me sometimes sit in on like their Friday demo sessions and afternoon demo sessions.
0:13:42 And they do a really nice job because you’ll even see the recruiting team come in and say,
0:13:46 hey, look, this is how we’re changing how we’re doing recruiting or this is how we’re changing
0:13:50 how we’re sourcing. I’ve seen the marketing team talk about how they’re thinking about some of the
0:13:55 growth of the business. So it really goes way beyond engineering. It’s a moment about celebrating
0:14:00 wins. It’s not a moment of critiquing. There’s other venues and channels and much more smaller
0:14:05 settings and directed settings. That is an incredibly important point. You know, we’re
0:14:10 currently in an environment where you can’t meet candidates face to face. And then just long term,
0:14:13 there’s going to be lots of situations where you’re interviewing wanting to hire somebody
0:14:17 who just it’s impractical to meet face to face. Are there things that you do to make sure that
0:14:22 you’re really doing a good job interviewing? Is this a non-issue? Is this an actual issue?
0:14:28 Yeah. Given that I’ve been doing this for a while, I find that it’s not so much about remote or
0:14:31 co-located. It’s actually about interviewing. And we’re just not that great at interviewing in
0:14:36 general. But for some reason, we have a better sense when we’re able to see someone in person.
0:14:41 So what I really say is it’s incredibly important that if you’re going to communicate to somebody,
0:14:46 you do it over video. And you can read the body language and you can have all those conversations.
0:14:51 And I’ve learned over the last 12 years of doing this to raise my voice at the right time,
0:14:56 to use the right intonation. If I’m on video, I overexpress with my eyes and my face and things
0:15:00 of that nature because you’re trying to send signals. And then I guess the other piece is
0:15:06 really, do you have to do things to make sure that the person being interviewed is prepared for a
0:15:10 remote style interview, maybe new for a lot of people? I just talked to a couple of different
0:15:16 companies and they had literally never talked to a candidate outside their physical building
0:15:23 until just recently. And here’s just some really tactical recommendations for this. One is, I think
0:15:28 from an interview process perspective, have a singular person who owns that candidate’s interview
0:15:32 process. If it has to be handed off to multiple people, it’s going to fall apart and get worse.
0:15:38 Once you have that ownership, identify what the days will look like, how it’s going to get done,
0:15:44 try to get to the conclusion as quick as possible. I think candidate experience from, “Hey, I’m
0:15:50 interested to yes/no decision.” If that lags, it’s an indicator of poor process. One small
0:15:57 recommendation, I see that a lot of companies do one-on-one interviews with candidates. And over
0:16:04 my career, I’ve really disliked one-on-one interviews except for executives. And I’ve
0:16:09 recommended that you at least go in two-to-one with candidates in interviews. And the reason why
0:16:14 is that if you look at interview processes, it’s about context sharing your experience with the
0:16:18 candidate with others. And this weird mechanism happens where you’re trying to say, “I liked
0:16:23 them. I did not like them for these reasons.” But you can’t corroborate any of that with somebody
0:16:28 else. I’ve always found that when you have at least two people from the same company interviewing
0:16:32 a candidate, it can go back and forth. It changes the interview process entirely and you get much
0:16:36 better results. Let’s also not forget the last most important part of interviewing, which is
0:16:40 references, which obviously can happen in a remote environment and often do. Maybe with the
0:16:43 exception of engineers where you really want to make sure that they can code and write code,
0:16:48 I think references are as important and oftentimes more important than even the interviewing.
0:16:51 There’s a lot of people that are great at interviewing that are just not great at doing
0:16:55 work and working with. And there’s actually a lot of people that are bad at interviewing that are
0:16:59 great to work with and do great work. And so references are often the way that you cut through
0:17:03 that and find out the truth. It’s less important for individual contributors,
0:17:08 but for people that are going to manage other people, the references have to be glowing.
0:17:12 I do like to give projects to people, very lightweight ones, but the project is not to critique
0:17:18 the style or code necessarily. It’s really to get to the way that they’re thinking, particularly
0:17:24 when it comes to senior folks. However, I still think it’s more about interviewing and we’re just
0:17:30 not that great at the ability to identify good talent. When you’re hiring engineers, I tend to
0:17:34 ask them to break down problems. I ask them to see if they can help me work through why they
0:17:41 made decisions. I like to see how much ownership they’ve taken on projects. And I don’t mean ownership
0:17:47 that they were given and then ran with ownership that they’ve more seen inherently implicitly and
0:17:52 then made explicit via their actions. We’re in the midst of a crisis that nobody who is currently
0:17:56 living has really ever experienced before. It’s both acute from a health standpoint.
0:18:01 It’s a massive shift for people economically and creates a lot of uncertainty. It may be a
0:18:05 lot of shifts for people in terms of the viability of the company that they work for or the changes
0:18:09 that a company might work for to survive. And it’s very hard to know what people’s personal
0:18:15 situations are. I got an email actually yesterday that there’s two executives and both of their
0:18:21 spouses actually work in emergency rooms. And I can’t really even imagine what it’s like in that
0:18:26 household where they have kids at home and their spouses on the front lines in the emergency rooms.
0:18:30 And so I think in this moment in time, you just have to give people a lot more latitude, a lot
0:18:35 more leniency, a lot more flexibility. If they’re new to the organization, you have to give them
0:18:39 forward credit for what you expect out of them when things are normal. And if they’ve been with you
0:18:44 for a long time, you certainly owe them the latitude and ability to be flexible and different
0:18:49 people cope in different ways. And I just think that managers and leaders who have been in a mode
0:18:53 of we got to grow or we got to hit our deadlines, we got to hit our numbers, all that stuff is on
0:18:57 pause right now. This is a good moment for lots of people to figure out, are they spending their
0:19:02 time on the right things? You’ve had this really, really focused growth mindset. You’ve been focused
0:19:07 on growth that is the only priority. And you can use this moment in time to say, is our product
0:19:12 roadmap the right product roadmap? If we know that the top line may not grow the way we had
0:19:16 expected it to, would we change our product priorities? Would we build something more exciting
0:19:21 or interesting or different? So just really pause and think about what are the priorities
0:19:25 for me while my day job is investor and meeting with startups and companies. And I’m doing a lot
0:19:29 of that because we’re open for business and we’re investing. I’ve spent a lot more time as both a
0:19:34 career counselor to friends, a lot more people reaching out, trying to figure out how do they
0:19:38 lead their teams. Yeah, this is not business as usual. We are not living in business as usual
0:19:43 times. As the venture community talks about, Hey, think about this time period over the next
0:19:50 whatever it is, year 18 months or 24 months. And what’s the scenario look like if your ARR
0:19:57 drops by a third or two thirds or whatever and start modeling those? Well, right now in unprecedented
0:20:02 times, I say the same thing about productivity. What does it look like when you’re at two thirds
0:20:08 productivity or 50% or then a one third of what you expected and start planning for some of those
0:20:16 scenarios? You know, the way that I’ve approached this at work is to say, one, take care of yourself.
0:20:23 Two, let’s talk openly about what’s possible and what’s not possible right now. And three,
0:20:27 understand why the work would or wouldn’t be important in the context of everything else
0:20:33 that’s happening. And I personally have a career and philosophical principle about what I do is
0:20:38 I try to run to the point of highest leverage. And I’m in a very interesting privileged position
0:20:43 at GitHub is that I run the office of the CTO. It’s a small staff at this point. And we’ve entirely
0:20:47 focused on COVID efforts. We’ve got some data scientists, we’ve got engineers, and they’ve kind
0:20:50 of said, you know, what right now is pause on some of the more exploratory work that we’re doing,
0:20:58 we want to go lend some effort and hands over to these in a personal story. But in 2009, my wife,
0:21:04 she’s a GP, a doctor, and she was at Mayo Clinic, and she got sick. We think it was H1N1 with
0:21:10 pneumonia, and she was intubated in the ICU for six days and in the hospital for 10. And here we
0:21:15 are, we’re finding ourselves in an epidemic that looks a lot like what she got. And we were young
0:21:20 and we had one kid and we realized that our life had been an autopilot for a little while. We didn’t
0:21:25 like it. And it caused us to have that moment where we reflected and said, are we actually doing
0:21:32 what we want to be doing? And we changed our life a little bit, we went to Australia. And I would
0:21:38 encourage everyone to use these moments to personally reflect on if your life is on autopilot.
0:21:39 Thanks, Jason. Thank you.