The a16z Show - Moving to Remote Development (and Work)

Episode Date: April 15, 2020

From agile project management to asynchronous collaboration, development teams have pioneered many of the tools and best practices for remote work. However, new shelter-in-place orders have more organizations moving to remote development -- and remote work -- often quickly and without a lot of time to plan.Will remote work be our new reality, even after the current pandemic? And if so, what are the current technologIes and practices that support organizational communication and alignment for distributed teams, development and otherwise? In this hallway-style podcast, Jason Warner, the CTO of GitHub, and a16z General Partner David Ulevitch cover how working from home is evolving our software as well as how we use it -- from communication tools and best practices to interviewing and hiring when you can’t see someone face to face.  Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Hi, and welcome to the A16Z podcast. I'm DOS, and in today's episode, Jason Warner, the CTO of GitHub, talks with A16Z general partner, David Ullovich, about the best and worst practices of remote development, and more broadly, remote work. Shelter and place orders have more companies making the move to remote faster than ever. So is this our new normal? And is it the future of work? In this hallway-style jam, the two discuss the tools and strategies for communication and alignment, What does and doesn't work, from demos to burn down charts, and end on some reflections given the current crisis. They begin, however, by talking about where location does, or maybe we should say, doesn't come in. I've been a remote executive now for just over 10 years, and I myself have never lived in San Francisco. I wonder how many people list their location on LinkedIn as the San Francisco Bay Area, but don't actually live here. I'm sure it overcomes the Silicon Valley bubble bias of everything. everyone having to be here, which I guess is what we're talking about today.

I think my career would look very different if I didn't put San Francisco on at one point. That's really interesting. I wonder if that's going to change in the future. I hope it does. I really do. You can get more efficiencies in your business. You can have better access to talent. And Silicon Valley has a bias towards them being the best of the best. But the world has moved on from that. And I think what you're going to find, too, and I think we will find this in time in this next decade, is that the access to talent is the only game that really matters in the next 10 years. The aperture will open for roles that previously people thought couldn't possibly be done remote, that this particular role had to be in the office.

And then now, of course, that role is working because it's remote by definition because we're in this moment in time. Jason, what are the dynamics that we're observing? I think both in this moment in time and then more broadly. So I think the most common thing that I've seen when people try to go distributed and remote as a company is that some of the worst human behaviors or tendencies tend to get amplified. So as an example, if you are a person who is prone to gossipy type of stuff,

you might seek out more gossip. If you're prone to anxiety and you worry about your job, someone not replying to you in an instantaneous basis this might give you heartburn. However, the worst one is micromanagement. If you're a boss who micromanages people when you're in the office, it gets amplified 100 times remote because you tend to, quote, unquote, want to check in to see how things are going or reopen decisions. You know, typically if you think about what the behavior mechanism of micromanagement is, it's lack of either transparency inside or trust. So figure out which one of those it is and fix that. How you fight that as a tendency,

is you really have to clear up your lines of communication. What are you doing for why? How are decisions being made and ratified? Who has the decision-making authority? How are we tracking progress? Do you have the right structures, meetings, cadence, or updates that you need to feel confident that things are moving in a direction? You know, I think the ability to go to a remote workforce for me as a leader

means the ability to sort of hold people accountable who aren't directly in front of me and know how to communicate over various communications mediums that don't involve just walking over to their desk and annoying them, which is, you know, manager 101. You know, sometimes when you see somebody face to face all the time, you can sort of write off that quick one-line email that might be a little bit snarky or they might misinterpret because you're going to see them the next morning. But when somebody's working remote, you start to put more context around things and you start to, you know, say thank you and please, since you can't just see them in the morning and say,

oh, hey, sorry about that email last night. I found that to be one of the most interesting transitions for me personally. I got a lot better about communication and a remote company, distributed company, really fast. And as you said, more context, a little bit more empathy about how it will be read. And next thing you know, you have a whole bunch of autonomous leaders emerge out throughout the company. Something I want to advocate for when people think about distributed work is the types of communication channels that they need. Basically, if you're going to optimize for the fullness, you're going to want three. But if you have to choose one, choose async memorialized communication.

So we will always have email. That will never go away. And I don't consider that part of the tool discussion. That just is. However, when I say async memorialized, I mean things where you basically ratify decisions and threads and you've locked them and they will stay there as your institutional memory. So that's the first. I think the second one is video calls.

And then the third one, which is the one that most people reach to first, is something like Slack or IRC. or any of those things. I think that should be your third. That should be the optimization that you have and you should never treat it as institutional memory. I don't think those tools are set up to be institutional memory. Backscroll is the worst way

to go find out the context to a conversation. I do think that you can use it for in real time, slight communication between a couple of different people, but then once the decision's made in that, it should be ratified and memorialized in a different system. I agree completely with the memorializing sort of in situ in the tool that you're using. So if it's code and product decisions, maybe that's in GitHub.

One of the things that's been interesting to observe over the last few years is that many, many tools, especially SaaS tools, they've sort of been including more and more multiplayer support. But what we've observed is they're actually adding more and more of the collaboration into the tool themselves. So for instance, people that use Figma, they are commenting and talking about the Figma files directly in Figma. As it moves over to marketing and product marketing and other people in the organization away from the designer and into engineering and other aspects, all that comment history of like, how did the design end up the way it is? Or why did we make this decision the way we did is in that file and it stays there forever. And that's super powerful. The downside is people sort of have more places to look for commentary and things. The good thing is that the metadata is now sticking around with the content itself, which is quite powerful.

One comment about Slack that I've observed with the companies that I work with that are distributed is that Slack ends up becoming a notification mechanism for them. So obviously it has that water cooler-like capability that a lot of people use to talk about things real-time and sort of synchronously. But it also takes on this notification mode where all these tools where things are being memorialized or being discussed sort of in situ, then get sort of centralized back into Slack for people that are sort of just voyeurs and want to know what's happening. but aren't maybe engaged in the day to day. I have seen the exact same thing, which is Slack in particular, is it's a pinch point, essentially. Every other system flows into it, updates it, and then goes back out, and then people stream all that stuff together.

Just as basically GitHub and Slack can become platforms for exchange of information, I imagine you're going to see a lot of new tools emerge and basically say, okay, hit this button. It'll sync to X, Y, or Z system. In fact, this may seem like a subtle point, but turns out to be an important point that collaborating and discussing and working through something in one tool is not the same as memorializing a decision in a way that the organization can sort of keep that memory of it and make it easily accessible. You know, when you memorialize a decision, it only counts if everyone else knows about it. The other thing is when things start to get memorialized, it allows new people to get up

to speed more quickly. And so that ends up being sort of a tailwind that just benefits all future people that join the company. And so as these tools are creating sort of the collaboration inside the individual tools, as opposed to outside the tools, I do think it actually becomes more important to define where decisions get memorialized, whether it's in sort of like a wiki page inside of GitHub or confluence or notion or whatever it is. So my approach has typically been, you can choose Y tool or Z tool if you want to to do your local development practices, whether it's tracking, story points or using Kanban style or so if you're choosing Trello or Asana or something like that,

and you want to track your stuff locally for your team there and you want to experiment with it. I'm not going to stop you from doing that. However, the organizational institutional and is going to live in X. You can do yours locally and then you have to actually memorialize decisions or all those things in the system of record. And that's how we're going to know what's going on. I find that works better as organizations get larger. If you're smaller, I usually just say, we're all going to live in X. Sorry, we're not going to entertain other tools at this point. When people ask me about habits of remote companies, and I said, well, they're just really habits of great companies. And I want everybody who logs in in the morning to know exactly what

they're working on, why, and for whom. And that starts at the top. It starts with context, communication. And then you have to have the swing all the way back up is, are we actually doing it? Are we making progress? Are things actually advancing? And the mechanisms by which you achieve those things are going to make you a great company, distributed or co-located. And if you think about another aspect of leadership in general is everybody in the organization is making the set of decisions that only they can make. So if you're the CEO, there's a set of decisions that nobody else in the company can make. Only you can make them. So you do. You make those decisions. And then every other decision that somebody else can make is delegated to that person and et cetera, et cetera, all the way down.

But that only works if you are transparent enough and sophisticated enough with your mechanisms to say, I'm going to make these decisions. Here's our goals. Here's our measures. Here's how we're going to measure progress, all that sort of stuff at each one of those levels. I pay attention to a project on GitHub called Home Assistant. And they've now incorporated a ton of sort of automation, not just around. Is this code fitting a certain code formatting policy? But also, they now have these mechanisms like, does this fit with our values? And somebody has to sign off on that for the issue to get closed? Does this support all the internationalization that we're looking to do? And somebody who's approved elsewhere, quote unquote, in the organization has to sign off on that.

And the issues get sort of redirected and there's a bunch of bots that coordinate and facilitate all this. And so the mechanism of working in a distributed way is being facilitated by technology in a way that I've never seen before. And I really think that was driven by the open source community as you embrace source code revisione kind of paradigms and apply them to all these other things that anybody can do a poll request and have it reviewed and evaluated and considered or being able to fork the organizational code to improve it. It feels like it breaks down these weird hidden power structures that sometimes can emerge in very old or very large established corporations,

which is basically like, hey, we need to go do this. You're like, oh, the only person who touches that bit of code or can make that decision is ex-person, and you have to talk to the right people to go find out who that person is. Instead, open source has basically built mechanisms for that. When you put an issue into GitHub and it has this keyword, into it, somebody automatically gets tagged who is responsible for that. And then they're notified and they have to go comment on the issue and have discussion about it. I think the feedback loop

mechanism of lowercase A agile is incredibly important, which is it's the only time that I'm going to find out how things are going is when it's released or at the end of a sprint or at the end of a quarter. The classic project management, red, green, yellow type of approach is probably not the right mechanism. So I've just introduced a couple of different things. One is for remote stuff, obviously you want to have somebody responsible for updating the progress of various projects, products or whatever, across the organization, particularly the ones that are independent upon other teams or organizations. The other is I like to do review meetings now. And in those meetings, I'm getting updated on very large or ambitious projects on a regular basis. And particularly,

I'm trying to edit in that meeting, not author. So it's really a time for me to either course correct or get updates. I also like the organization to feel the same sort of progress. So I ask teams to give regular updates to the organization on a weekly, biweekly, or at most, at absolute most monthly basis. And I ask them to do a write-up with a video demo of the progress that they made in that time period. I have not personally found things like burn down charts to be that effective. I just think we as an industry are not great about estimating progress.

I agree. Things like burn down charts are sort of useless because they get gamed, but just demoing very, very regularly creates those loops and those opportunities for people to course correct and edit. I personally love demos. I get excited by them. I think the organization gets excited by them. And I think there's a forcing function. If you do it on a regular time interval, you have to think a little bit of like, okay, how are we actually going to showcase progress here? Because one of the worst habits I've seen of very large engineering teams or large-scale engineering efforts, large-scale maybe infra ones or operating system ones, is to say we can't actually demonstrate progress for months, which we all know from the way that software can be written is

that is never true. So the job now becomes how do you actually demonstrate progress in a shorter amount of time? But also, this is not just an engineering thing. It can be all parts of the organization. So when people are listening to this podcast and they're saying, oh, that's great for demoing some code or a new UI somebody built, it's absolutely not just for that. It's for anybody in the organization. I've been lucky that superhuman, Rahul Vora, the CEO, lets me sometimes sit in on like their Friday demo sessions and afternoon demo sessions. And they do a really nice job because you'll even see the recruiting team come in and say, hey, look, this is how we're changing, how we're doing recruiting or this is how we're changing how we're sourcing. I've seen the marketing team talk about how they're thinking about some of the growth of the business. So it's It really goes way beyond engineering. It's a moment about celebrating wins. It's not a moment of critiquing. There's other venues and channels and much more smaller settings and directed settings. That is an incredibly important point.

You know, we're currently in an environment where you can't meet candidates face-to-face. And then just long-term, there's going to be lots of situations where you're interviewing wanting to hire somebody who just, it's impractical to meet face-to-face. Are there things that you do to make sure that you're really doing a good job interviewing? Is this a non-issue? Is this an actual issue? Yeah, given that I've been doing this for a while, I find that it's not so much about remote or co-located. It's actually about interviewing. And we're just not that great at interviewing in general.

But for some reason, we have a better sense when we're able to see someone in person. So what I really say is it's incredibly important that if you're going to communicate to somebody, you do it over video. And you can read the body language and you can have all those conversations. And I've learned over the last 12 years of doing this to raise my voice at the right time, to use the right intonation. If I'm on video, I over-express with my eyes and my face and things of that nature because you're trying to send signals. And then I guess the other piece is really do you have to do things to make sure that the person being interviewed is prepared for a remote-style interview, if they may be new for a lot of people. I just talked to a couple of different companies and they had literally never talked to a candidate outside their physical building until just recently. And here's just some really tactical recommendations for this.

One is, I think from an interview process perspective, have a singular person who owns that candidate's interview process. If it has to be handed off to multiple people, it's going to fall apart and get worse. Once you have that ownership, identify what the days will look like, how it's going to get done, try to get to the conclusion as quick as possible. I think candidate experience from, hey, I'm interested to yes, no decision. If that lags, it's an indicator of poor process. one small recommendation. I see that a lot of companies do one-on-one interviews with candidates. And over my career, I've really disliked one-on-one interviews except for executives. And I've recommended that you at least go in two-to-one with candidates in interviews. And the reason why is that if you look at

interview processes, it's about context sharing your experience with the candidate with others. And this weird mechanism happens where you're trying to say, I liked them. I did not like them for these reasons. But you can't corroborate any of that with somebody else. I've always found that when you have at least two people from the same company interviewing a candidate, you can go back and forth, it changes the interview process entirely, and you get much better results. Let's also not forget the last most important part of interviewing, which is references, which obviously can happen in a remote environment and often do. Maybe with the exception of engineers, where you really want to make sure that they can code and write code, I think references are

as important and oftentimes more important than even the interviewing. There's a lot of people that are great at interviewing, that are just not great at doing work and working with. And there's actually a lot of people that are bad at interviewing that are great to work with and do great work. And so references are often the way that you cut through that and find out the truth. It's less important for individual contributors. But for people that are going to manage other people, the references have to be glowing. I do like to give projects to people, very lightweight ones, but the project is not to critique the style or code necessarily. It's really to get to the way that they're thinking, particularly when it comes to senior folks. However, I still think it's more about interviewing

and we're just not that great at the ability to identify good talent. When you're hiring engineers, I tend to ask me to break down problems. I ask them to see if they can help me work through why they made decisions. I like to see how much ownership they've taken on projects. And I don't mean ownership that they were given and then ran with ownership that they've more seen inherently, implicitly, and then made explicit via their actions. We're in the midst of a crisis that nobody who is currently living has really ever experienced where it's both acute from a health standpoint. It's a massive shift for people economically and creates a lot of uncertainty.

It may be a lot of shifts for people in terms of the viability of the company that they work for or the changes their company might work for to survive. And it's very hard to know what people's personal situations are. I got an email actually yesterday that there's two executives and both of their spouses actually work in emergency rooms. And I can't really even imagine what it's like in that household where they have kids at home and their spouses on the front lines in the emergency rooms.

And so I think in this moment in time, you just have to give people a lot more latitude, a lot more leniency, a lot more flexibility. If they're new to the organization, you have to give them forward credit for what you expect out of them when things are normal. And if they've been with you for a long time, you certainly owe them the latitude and ability to be flexible

and different people cope in different ways. And I just think that managers and leaders who have been in a mode, and we've got to grow or we've got to hit our deadlines, we've got to hit our numbers. All that stuff is on pause right now. This is a good moment for lots of people to figure out, are they spending their time on the right things? You've had this really, really focused growth mindset.

You've been focused on growth that is the only priority. And you can use this moment in time to say, is our product roadmap, the right product roadmap? If we know that the top line may not grow the way we had expected it to, would we change our product priorities? would we build something more exciting or interesting or different? So just really pause and think about what are the priorities? For me, while my day job is investor and meeting with startups and companies,

and I'm doing a lot of that because we're open for business and we're investing, I've spent a lot more time as both a career counselor to friends, a lot more people reaching out, trying to figure out how do they lead their teams. Yeah, this is not business as usual. We are not living in business as usual times. As the venture community talks about, hey, think about this time period over the next whatever it is, year, 18 months or 24 months. And what's the scenario look like if your ARR drops by a third or two thirds or whatever and start modeling those? Well, right now, in unprecedented times,

I say the same thing about productivity. What does it look like when you're at two-thirds productivity or 50% or then a one-third of what you expected and start planning for some of those scenarios? You know, the way that I've approached this at work is to say, one, take care of yourself. Two, let's talk openly about what's possible and what's not possible right now. And three, understand why the work would or wouldn't it be important in the context of everything else that's happening. And I personally have a career and philosophical principle about what I do is I try to run to the point of highest leverage.

And I'm in a very interesting room privilege position. Hub is that I run the office of the CTO. It's a small staff at this point. And we've entirely focused on COVID efforts. We've got some data scientists. We've got engineers. And they've kind of said, you know what, right now it's pause on some of the more exploratory work that we're doing. We want to go lend some effort and hands over to these. And a personal story, but in 2009, my wife, she's a GP, a doctor, and she was at Mayo Clinic, and she got sick. We think it was H1N1 with pneumonia. And she was intubated in the ICU for six days. And in the hospital. And for 10. And here we are, we're finding ourselves in an epidemic that looks a lot like what she got. And we were young and we had one kid and we realized that our life had been on autopilot for a little while. We didn't like it. And it caused us to have that moment where we reflect and said, are we actually doing what we want to be doing? And we changed our life a little bit. We went to Australia. And I would encourage everyone to use these moments to personally reflect on if your life is on autopilot.

Thanks, Jason. Thank you.