 All right, should we go ahead and get started? All right, sounds good. OK, hello, everybody. Thank you for taking the time to come join this session today. My name is John Chan. I am a engineer at Stack Overflow. And today I'm going to be talking to you about building a remote engineering culture. Before we actually get started, a show of hands, how many of you are developers here? Or code. Oh, very good. So I'm assuming most of you know what Stack Overflow is. Yes? If you don't and you're an engineer, you probably should find out because it'll help you a lot. How many of you are hiring managers? Any of you? How many of you think about recruiting engineers? OK. And one last show of hands, how many of you work at a company that is at least partly remote? That means there's somebody full time that is working remotely. All right, good. There's a good, decent number of you. All right, so let's get started here. Oh, there we go. OK, now I can just start it. All right, let's get started. So a little bit more about me. This is my TLDR. So like I said before, I've been working at Stack Overflow. I am what is called the marketing engineering lead. That means I lead a team of engineers, designers, as well as marketers, thinking really about growth and re-engagement across the company and what people really think of the Stack Overflow brand. Another thing that I want to mention is that I'm also the founder of Bento. And I think a lot about tech education and how to democratize learning how to code for pretty much all people. And the other things that I sort of want to mention here too, I'm also the head of diversity and inclusion partnerships at Stack Overflow, and also the creator of Descartes.io. So with all of these different things, I'm going to be drawing on my experiences, thinking about how to build engineering teams, and also thinking about how we can continue to do engineering in a way that's distributed. So we're going to be talking mostly about three things today. The first is really why remote. So we really believe at Stack Overflow that remote work is the future of talent. There are so many different advantages to having a remote team, and I'm going to be going over a few of them with you today. Two is how we do it. At Stack Overflow, we really think that remote is part of our DNA. There are a lot of different things that we do to make remote possible from the very beginning of Stack Overflow, and I'm going to share a few of those ideas with you here as well. And the last thing is more of a shift here, and that's really about something that I call extreme remote. So I've personally taken our remote policy at Stack Overflow to an extreme, and I'll give you a look into what it's like to be nomadic at Stack Overflow. That means traveling full-time while I'm working at Stack Overflow full-time as an engineer. So I'll give you a peek of what that's been like too. At the very end, we'll have five minutes for questions, and of course, if you have any more questions afterwards, I'll be telling you how to get in touch with me, and I'll be sticking around for the conference for more questions if you have them. All right, let's dive in. So first, why remote? So when it comes to remote work, there's really two things that really boil this down to. There's a lot of different advantages to being remote, but it really comes down to two things in my mind. The first is really when it comes down to talent. You know, having a remote workforce really gives you access to really amazing talent. And the other thing, the other half of that coin here is that it also makes your workforce resilient to change, and I'll tell you more about what that means in a bit. The second thing that I wanna highlight here is around productivity. You know, one of the big myths about remote work and actually having a remote engineering culture is that it's not productive. How can you be productive if you're not altogether sitting at the same place? Well, we actually think that when remote is done well, it can actually make you more productive as an engineering team. And it really comes down to flexibility and autonomy. And those two things in combination will really enable your remote workforce to be really productive. There's two references here, two blog posts that I wanna mention. The first is on working remotely, and this really talks about the origins of our remote sort of culture from one of our co-founders, Jeff Atwood. And the other one is why we still believe in working remotely. It's sort of as a follow up to that blog post by our VP of engineering, David Fullerton. So if you wanna find out more about these topics later on, I'm gonna be distributing these slides later. Go ahead and take a look at those blog posts. So the first thing, one of the two things that I was mentioning, first is talent. So the first thing, and I think a lot of you, especially the ones that have sort of raised their hands about hiring engineering, engineering talent is really rare. At Stack Overflow, we do a lot of research about understanding what the developer landscape is like. And what we find is that there's only one programmer for every five jobs that exists. There aren't enough programmers to fill all the jobs, including the ones that you have open positions for. And that means that it's a really, really competitive landscape when it comes to hiring engineering talent. So what you wanna do if you wanna be remote is that you can help diffuse the competition. Restricting your talent to people who only live up to then say 50 miles of you of a physical location that you have is really restrictive. If you start thinking about hiring remotely, you can dramatically increase that pool if you want. Now the other side of that coin, right? And in addition to sort of expanding your pool, is that it's really great for the individuals too. You can get access to a lot of untapped talent. There is amazing engineering talent in areas where you probably wouldn't think would be a great place to actually be an engineer. Because, you know, not every place is San Francisco and Silicon Valley and New York City and Singapore and all these different places where there is a concentration of jobs, you would be missing out on all the engineering talent if you only restricted yourself to those physical locations. So being that opportunity for those people in those more remote areas is gonna be huge. It gives you a huge competitive advantage to actually getting that talent. Now the last thing here is that it helps you be resilient to change. How many of you know somebody that has to change a job because either their spouse had to move or they had to move back to family? Anybody? Right. So imagine, you know, if you were in a really good job, a great engineering team and suddenly you had to move back because of family or something else, being in a remote engineering culture means that you don't have to leave your job. So it makes your workforce really resilient to change as well. So this second half of this, productivity. We really think that the productivity here, especially when it comes to the individual and remote teams, comes down to flexibility and that translates into high-performing teams. So being remote, that means that you give people the ability to optimize how they can be productive as an engineer. You really give them the flexibility to figure out when can I be most productive. Now one of those things that we think is going to make engineers really productive is this idea of a private office. How many people sort of work in an open space in an engineering room like Cubicles? Sometimes it's a little hard to concentrate, right? So you sort of hear people in the background and you end up putting headphones on and then you just blast music. That doesn't really help a lot. But what's really nice about being remote is that you automatically get a really nice private office. It's at your home. We really think and really believe that programmers need uninterrupted time periods so that they can concentrate and work on code. Having a private office being your home is really, really helpful if you're in a remote culture. The other thing here, too, is that your time is better spent. Remote means that you get a really, really short commute. That means you just roll out of bed and start working if you want to. And the other really nice thing there, too, is that you get flexible hours. You get a lot more control over when you actually work and figure out when you are most productive, when you get to work remotely and not be tied to a desk that you have to get in at nine and leave at five. And the last thing here, and this is more from the management perspective, but that helps you, it forces managers to think about managing towards results as opposed to what we call butts and chairs. It's really easy to delude yourself into thinking that as long as you're spending eight hours a day that you're actually getting work done. It's probably no secret to anybody that if you're spending all that time in an office, maybe some of that time is spent on Reddit or Hacker News or something else like that and not necessarily coding all the time. So instead of trying to force and think about productivity as being something where it's just people putting in time, you can think and really focus on results instead. So really when it comes down to it, why remote? Remote is flexibility. That's really what the really big advantages here are, not just for hiring managers and people looking to build engineering teams, but also when it comes to trying to make your engineering teams really productive, too. So how do we do it at Stack Overflow? First, before we actually dive in it then, I wanna give a little bit more background onto what Stack Overflow is like. The first thing is that we're pretty big and we're kind of everywhere. We're just at around 300 people with our three physical office locations in New York City, in Denver, both in the United States and in London and the UK. Overall, we are 25% remote. That's engineering, sales, marketing, everybody, but for engineering specifically, we are overwhelmingly remote. 70% of all of our engineering team is considered remote and that includes PMs, designers, SREs, and developers, too. The other thing here is that we're very, very much distributed across the entire world. We have people in Asia, we have people in Europe, in the United States, in South America. Pretty much every major continent that you can think of, we might have somebody or have some sort of presence there. The other thing that I wanna mention here is that we really started remote, too. Our co-founders, Jeff Atwood and Joel Spolsky, actually started the company on different parts of the country in the United States and our first few engineers were in different cities as well. Remote is something that we sort of began with and it's been part of our DNA ever since. So when it comes to how we do remote at Stack Overflow, these are the different things that we think about. The first is people, right? We really believe that remote is a people-centric problem. These are the things that we look for in people and how we set those people up for success in a remote work environment. The second thing that I wanna talk about is culture. So remote can only really be done well when everyone is bought into it. You know, what are the unspoken and sometimes the spoken rules about how to make remote work across the company when not necessarily somebody like a manager is there to enforce it. Making it part of the culture keeps everyone on the same playing field and the same level. And I'll talk more about that in a bit. The third part is about communication. And this is probably the thing that is talked about the most when it comes to remote is, well, how can you keep everybody informed about everything that they need to know if they're not in the same place? You know, keeping everyone informed is already tough regardless of whether you're remote or whether you're in a physical location, but it's even tougher if you're talking about remote. So these are the different tools that we use and the philosophy that we take to communication. So let's dive in. The first of three parts is people. And we really think that finding and enabling people to be remote is the groundwork for that culture. I think that splits out into two major things here. The first is hiring and the second one is onboarding. When it comes to hiring, really think that you can hire for remote. And we want people to shift, they're thinking away from thinking about managing people that should be managed in a physical location and thinking about how to manage accountability and really focus on hiring right instead. Now the second part to that, once you actually get those right people, how do you actually set them up for success? And that really has a lot to do with onboarding. So onboarding is already difficult to do at any company, but remotely it's even harder. So setting people up for success remotely is extremely important and particularly important because there's a lot more culture and a lot more education to be done. So one of the references here that I sort of want to point out is Joel Spose's Guerrilla Guide to Interviewing. That'll give a lot of context about how we think about hiring developers and that'll also give you good insight into what we look for for developers overall, but also for things specifically related to remote. So hiring, hire instead of manage. It's really funny because whenever I talk to people about remote, especially other founders or people that are running engineering teams, one of the very first things that they think about is, well, I can't do remote because I need to make sure that I can keep people accountable for the work that they need to get done, right? What you might hear people say is that, well, I can't possibly have people, developers that are outside of the office because I need to be able to check up on them on a regular basis. And in many ways, when you're thinking about that and you're thinking of the questions around that issue, it's sort of the wrong question to be thinking about and when we think about it this way. So instead of thinking about this as a management problem, well, how do I make sure that I can keep people accountable when they're not in the office? You think about, are you getting the right people for the job and the positions that you want instead? You can't be looking over everyone's shoulder all the time. So instead, what we think that you need to do is that you have to try and find people that work well remotely. Now, what does that actually mean? When we think about remote, there's sort of two kinds of people that I think about. Sort of put yourself in this position. If you were going to be working from home, say, without anybody around you, none of your coworkers there, what would you end up doing? Would you be the kind of person that would be like, oh, well, I have all this free time, I can go play video games all the time if I wanted to or do something else instead? Or there are some other kinds of people that would be really anxious if they didn't do anything, if they weren't being productive and they knew that they had to be. Those are, you know, you can put people somewhere on a spectrum on that. And what we're really looking for and what we think works really well for them out is trying to find those people in this category instead, the people that would be anxious if they weren't being productive when they knew that they needed to be, even when there's nobody else around them to tell them to do that. And the way that we sort of talk about that quality is that we say that those kinds of people get things done. Has anyone heard of this sort of phrase, smart and gets things done when it comes to hiring? Anyone? Alright, a few people. So, Joel Spolsky, our CEO, wrote a whole book about these two things and it's really the core of that blog post that I was referencing earlier is that when it comes to the way that we hire developers at Stack Overflow, it really boils down to those things. People that are smart and that they get things done. And when it comes to remote, it's really, really important that they get things done because what that means is that we're looking for people who are self-starters. People that are proactive. People that are entrepreneurial. The kind of people that would be anxious in a really lax environment where they didn't do anything. They want to be able to do things. What we notice when it comes to people that are working remotely is that we actually find that they work much more sometimes than the people that are actually in physical locations. And we actually screen for that kind of characteristic when it comes to those people that want to work remotely. Now, the last thing I will say here too is that we know we still also have physical offices. As I said before, not everybody works great in remote, but that doesn't also mean that we don't want them to, right? For those people who aren't great at remote, we also provide the option of them going into a physical location. I'm typically based out of our New York headquarters, but I also work remotely pretty regularly, especially when I'm traveling, like I am now. So it's really about letting people choose and supporting their decisions instead. So the second thing, onboarding. So now that you find those people, if you find the people that get things done, you really need to make sure that you set them up for success as well. It's not enough to sort of just hire them and then forget about them. Once you find those good people, you really need to educate them on the culture and really familiarize them with the tools. You need to make sure that the infrastructure and the culture is really there to help support those people that want to be remote. Now I'm going to mention a few things here. The really big thing here is called Stack University. So we have this onboarding program where all engineers go through. It takes about six to eight weeks and it really consists of a lot of different things, mostly three. The first is remote meetings. So this is when you sort of talk to each of the team leads on the engineering side, when you talk to people that understand different parts of the code base, pushing code. So we are trying to get every single engineer that comes to Stack Overflow to push code on their first day all the way to production. And they also work on what's called a graduation project where they actually take a feature that they want to prototype, work on it, do it for two weeks and then they actually demo it at the end to the rest of engineering. And the last, of course, is reading docs like you would see in a lot of other onboarding scenarios too. Now what's really interesting about Stack University is that we've also designed it so that it's completely remote and able to. It doesn't matter whether you're in a physical location or whether you're in a remote location because even for the things like remote meetings, those things are going to be happening with people that are all across the world. You actually can't do the onboarding without also being inundated in the culture. So the third part of this is also having a remote mentor. So when it comes to thinking about remote work, one of the really big things is understanding, well, how can I build relationships if I'm just alone in my house or traveling instead? So having a remote mentor, someone that can walk you through that first six to eight weeks is really important to us too because it gives you a first taste of what it's like to build a meaningful work relationship in a completely remote environment. And this is still the case also whether you're in a physical location or if you're in a remote location, there's really no difference here. Now the last thing here besides sort of the education portion of this is around equipment. We really, really believe that if you need something to get your job done, we will buy it, right? We wanna give you the best equipment that money can buy. Now every person that's at Stack Overflow that's remote, they get a headset so that you can have video calls just the way that anyone else would so that you're in a quiet environment. You get a standing desk, an ergonomic chair and you even get a high speed internet subsidy so that you get a home office that's very, very similar to the things that we would get in a physical location in New York, Denver or in London. We really wanna make sure that people feel as though they're on the same playing field and that they're really set up for success and things aren't getting in the way of making sure that they feel like they're part of the company even though they're not in a physical location. So this is really the big takeaway here. When it comes to thinking about people and remote it really starts with thinking about those people. It's really, really, really hard to try and do remote after their fact, right? It really needs to start with who are you letting into the door and how do you set them up for success so that they understand the culture and the education around all the things that we do when it comes to remote. All right, next, culture. What's the philosophy that drives remote here? And these are sort of the, when you talk about culture you sort of think about what are the rules that are sort of out there? The unspoken ones and even the ones that are repeated that make people do things in the absence of others. So culture is actually gonna be something that's really, really important to us when we think about remote. And again, there's two things here that I really wanna emphasize. The first is that everyone is remote. It's very important that we think of ourselves as a remote first company. It's really, really important that we make everyone feel like they're on the same level whether or not they're in a physical location or if they're remote instead. And the second thing about the culture here is that we really focus on empowerment. We really, really believe that it's important that you can do your work independently of many other people. Because if you really think about it, if you were dependent on a lot of other people to do your work, say that I can't push to production unless I have someone else actually take a look at it but you're in a different time zone from that and you have to wait five hours, that will make your cycles very, very slow. It'll make remote working a nightmare. So empowering those engineers is really key here. So one of the references that I wanna point out is a blog post that I wrote called Empowerment Organizations that really helps you think, sort of explains sort of how we think about empowerment when it comes to management and also how we think about empowering engineers as a whole. So if you're really interested in this topic, take a look at that in the future too. So let's start with everyone is remote. First is this idea of nobody on speaker. Has anyone sort of been in this situation where you get a bunch of people into a conference room and then you have a bunch of people like dial in and put onto the side? How many of you have been in a meeting like that before or it dialed into a meeting like that? In that situation it's kind of weird because if you're on speakerphone or if you're on a conference instead, it doesn't feel like you're actually part of that conversation sometimes. It's a little bit strange. So at Stack Overflow we make sure that that feeling doesn't really exist anywhere. If you've had that experience, you feel like a second class citizen in those meetings. So what we do at Stack Overflow is that we use Google Hangouts for most of our video chats. And one of the things that we do is that even if you're in a physical location you need to go talk to somebody. What you'll end up doing is that you'll go back to your laptop, get on a video chat and the person right next to you will get onto a video chat too. The reason that is is because if you want to get somebody that's in Europe but you're both in the New York office, all you need to do is ping them and they can come back in to that chat room and start talking to you. And everyone feels like they're on the same playing field. No person regardless of whether they are in physical locations or if they are in actual remote locations feels that they are more advantaged or disadvantaged as a result of that. And that really applies as a philosophy across Stack Overflow when it comes to remote. How do we make people feel like they're on the same playing field? So one of the ways that we do that is also by creating virtual social spaces. So one of the things that we do or that people talk a lot about when it comes to remote is that, well, it must be really isolating to be remote instead. Well, how do you talk to other people? It must feel really lonely to be a remote worker. Now, one of the things that you sort of miss out when you sort of end up working from home or somewhere else is that you miss out on those casual social interactions that you'd get, right? I'm gonna go grab a cup of coffee and I'm gonna go talk to my co-worker about this or I'm gonna go grab lunch. We have lunch every day in our offices at Stack Overflow. I'm not gonna be able to talk and go to different teams to chat about that stuff. So what we try to do as much as we can is that we have virtual social spaces too. Every week we have this thing called a Bev Bash, for example, where everyone can just sort of jump on a hangout and either grab a beer or coffee depending on what time zone that they're in and just chat. If you were just working and you didn't create those social spaces and all you did was meetings, you would actually end up still feeling that isolation. And there were also events and programs that we have on, we have this thing called Stack Roulette, for example, where we sort of randomize three people from across the company, regardless of where they are and get them talking to people. So you'll sometimes see a salesperson, a designer and an engineer on one call or you'll get a VP and you'll also get people from a different level in that same call as well so that you can really get that social interaction that you would miss out if you weren't in a physical location. Now on the other side of that, there are still physical meetups. We do still think that it's at least occasionally you come together. For engineering, we typically fly people in for a meetup once or twice a year, depending on what team that you're in. So a lot of people on the engineering team will be sort of part of their small team. So for me, it's marketing engineering. There's also a data science team when it works on our Q&A engine. And those people might come together once a year just for that team to talk to each other. But there's also a really large annual meetup that we do for everyone that touches the product. So all of marketing, all of design, all of engineering. And then we get everybody into the same room in one city once a year so that you can actually end up meeting all those people and actually put faces, real faces to those people that you're actually talking to on video chat. Now the last thing that I wanna mention here is around the non-engineering teams. Now when I say that everyone is remote, I really do mean is across the entire company. You know, it's important for teams that work with engineering to be remote first too. Communication and having the same lines of communication really enables collaboration and if you don't get everybody onto the same page, even those that are outside of the engineering culture, it's gonna be really hard to collaborate across teams. So let me give you a quick example of this. So I think about a year and a half ago, I was talking to our VP of marketing and one of the things that was happening was that they weren't really on the same lines of communication that engineering was. And what was happening was because the engineering team ended up doing, really focusing in three different areas when it came to how to communicate with each other. It was internal chat, it was Google Docs and it was also Google Hangouts. Now the marketing team instead, because they were mostly in physical locations, they were sitting next to each other. So instead of being on chat, they spoke to each other across the cubicles. When they were trying to actually have conversations when they were async, they were doing it over email. And when they had to have conversations with vendors, for example, partners, they were having phone calls or being on conference calls. And what you notice about those things is that there's very little overlap. And as a result of that, because not everybody was on the same page, there was very, very little collaboration on this 2S. And it really wasn't until we sort of started mending those two things together. The different modes of communication that the marketing team was doing and the engineering team was doing and really got them talking to each other that they started collaborating more. So, second part of this, empowerment. And this is the second part when it comes to culture here is really understanding how do you get people to work independently, largely of other people. So the first thing that I wanna mention is around gridlock. Being highly dependent on others to get things done really means that things are slower. So going back to that example of, imagine if you had to wait to push your production or if you had to wait for a code review for someone from halfway across the world. This is worse if you're in different places and times. This is not just the case when it comes to remote, it's just worse when it comes to remote. So one of the things that we wanna think about a lot at Stack Overflow to make sure that this doesn't happen is that we think about end-to-end engineering. What you do is that you allow engineering folks to be able to work end-to-end. That means taking something and having control from ideation all the way to production. When it comes to the infrastructure, some of you might have been at the talk yesterday around DevOps and how that really enables high-performing IT organizations. Really believe in that when it comes to our infrastructure too. So how do you actually allow for end-to-end engineering for remote workers is that you really make sure that you get fast deployments. You get feature-flagging, making sure that people aren't riding over each other's work. And third, that you do automated testing too. So all the things that you're thinking about, making sure that there's version control, making sure that there's no collisions around that, making sure that there's quality assurance around those things, we try to make sure that we automate as much of that as we can so that you're not necessarily dependent on other people that might be in a different time zone to make sure you can get things done. Now really when it comes down to it, all these different things around empowerment really comes down to trust too. Giving this freedom means that you trust your engineering talent is smart. You wouldn't want to be able to give all that freedom to someone that you didn't necessarily trust. So again, we go back to this idea of instead of trying to manage for that, you really think about hiring for that. And that's the second part of the smart and gets things done that I was mentioning before. You also want to make sure that the engineering talent that you're getting coming into the door, if you're going to be empowering them that much, is really, really good at engineering too. So the takeaway here when it comes to culture, remote culture means inclusive empowerment. Two things. Inclusive, making sure that everybody feels like they're on the same playing field when one person is remote, everybody is remote. And the second is around empowerment, really making sure that people feel that they have full control over their own work and they aren't too highly dependent on other people to get their work done. So the third part of how we get this done, communication. And this is really thinking about breaking out conversations out of who, when, and where those conversations occur. There's really two parts to the strategy when it comes to communication. And the first is around what we call asynchronous tools. When it comes to async versus synchronous, if you're a programmer, you might already know what this means, but if you're not, asynchronous sort of means, like it's what text messaging is. You can sort of send a text and then you can wait and then you can respond to it later. You don't have to be at the same time and place in order to do that. Synchronous is a phone call. You have to be there and very present in order to do that. And we focus on tools that are asynchronous. It's really difficult to get a lot of really busy people on the same time and in the same place to communicate. So instead of trying to force that happening in a remote culture, we just sort of stop trying to do that. And we focus on tools that will give us a written record. The second is this idea of public by default. So transparency, that's really what this comes down to. It's transparency and it's a really key part of our ability to be remote too. That means that we really think that information has been available to everyone by default. We really think that access really gives you, again, much more autonomy and really empowers engineers to get the work done without the dependence of other people. So asynchronous tools, and this is really addressing the when and the where. We emphasize written record whenever possible. It's really, really, really hard to try to get 12 engineers in five different time zones in the same place all the time. It's just not something that's really possible all the time. So instead of trying to force that to happen or just sort of give up on remote entirely, what we do is that we focus on communication tools that will give us a written record of something. So I'll give a few examples of what that looks like. The first really here is chat. So our primary mode of communication is internal chat. It's sort of like our main square when it comes to working with each other. And the really nice thing about having chat is that what that does is that it gives you a fully written record about all the conversations that are happening by default. So for me, I'm working here in Singapore. I'm actually still working full time while I'm out here. And we're on a completely 12 hour difference when it comes to New York City where a lot of the activity and the people that I work with is sort of happening. What ends up happening is that I can sort of continue doing my work throughout the day and go to sleep. They can see all the things that I've been working on. And when they finish their day, I can go back into the different chat rooms that I need to look at and see what conversations were being had then too, so that I'm never sort of left in the dark about what's going on. Now the next thing here when it comes to tools is around video chat. There are some times when you actually do need to talk face to face and talk things out, right? And Google Hangouts is our primary platform for this. And it works really well for ad hoc things. So they say that you're actually typing and actually having a live conversation with somebody on chat, but you don't want to go through typing all that stuff. You can just go hangout, tag the person, and it'll create a hangout internally in our chat system, and you can just jump on that hangout on an ad hoc basis. It's really, really nice. Zoom is another tool that we use for much larger groups. This is for things like town halls, where we try to get everybody in the company to listen to one of the executive team talk about something that's happening in the company. The last thing that I wanted to mention here is really docs and Trello. And this is quite literally written stuff, right? And this is where a lot of the project management that we have ends up happening. We rely heavily on Google Docs for things like specifications, and Trello for keeping track of tasks. Typical Kanban style that you'd sort of see in other agile teams. The next portion of this is something that we call public by default. And this is really about who actually owns the communication. As a company, we really value transparency and almost all information is available to everybody else in the company. And in many times, it's actually public too. It's not just within the company, it's outside of that. You know, there's some sensitive information like financial numbers or things like that, things that would give away a competitive advantage, but usually everything else, public by default. It really enables autonomy to give people access to the information that they need. So I'll give a few examples here. The first is around our weekly stand-ups. So this is one of the few exceptions that we have where we sort of require everyone to be synchronous and meeting at the same time. And it's our regular weekly stand-ups. We do this on a weekly instead of a daily basis that you might see in other places. And what we do is that we make sure that when we do our stand-ups where everybody talks about what they did a week before, what they're gonna be doing this week, and what blockers that they have, and to resolve them, that there is a public record of it somewhere so that any person can go to another team and find out what was being talked about and what they're working on. What's really nice about that is that you can get access to find out, well, if I'm working in Singapore and you know what the marketing team is doing, I can go find out that information. Now, granted, that's a lot of information if you're talking about a lot of different teams. So the other nice thing that we do is that we actually bubble up those weekly stand-up reports up into what we call a CEO report. And actually, all of this is managed inside of a trailer board so you can see all the different statuses that are happening on a weekly basis in one place. But you also get a digest of all the highlights from each of those reports in an email called the CEO report. And that happens on a weekly basis so you get a good snapshot of what's happening at the company at any one point in time. Now the thing is that this, again, comes back to empowerment. I keep talking about autonomy, empowerment, really thinking about these things. It's really another portion of this which is talking about, well, how do you make sure that people get the stuff that they need to get their work done without necessarily needing other people around them? It really, really allows people to continue working on what they need to do without having others to depend on them and having the information that they need to keep working and being productive. So last thing, when it comes to how we do this, public artifacts really allow for remote communication. Public, because we really believe in public by default. If you need information, you should have it and it should be available to you when you need it, usually in a written record of some sort. The last one is artifacts. Again, having a written record, making sure that it's acing, breaking out of when and where that communication took place. And by having both of those things put together, you really sort of solve this problem of how do you communicate across teams when they're really distributed? So this is the third part and this is the more fun part of this talk is what I call extreme remote. So this is really about pushing remote to the limit here. Now when most people think about remote work, most of them think about working from home, right? I can just go and sit in front of my computer with no pants on and nobody will ever know, right? But what if you really want to work remote but still keep your pants on because you wanted to travel? That's sort of what I was thinking about. So hello world, starting in August of last year, almost exactly a year ago, I ended up traveling while working full-time for three months. I really wanted to see not just what it would be like to work remotely outside of a physical location and stay in one place, but what would it be like if I was actually nomadic? What if I started traveling actively while I was working instead? So the idea here was that if we already have a great culture of remote work, why should I just stay in a single place? Because the idea here is that, well, if I was a European Dev, for example, and I worked out of London and I just stayed in the same place, I didn't necessarily want to live there. I just don't want to be able to travel. The really big difference here would just be that instead of every time everyone get into a Google Hangout and I had the same background, I have a different one because I'm traveling somewhere else instead. So the same principles here apply with a few special exceptions. So this is where I went in three months while I was working full-time as an engineer at Stack Overflow. I ended up going to 22 different cities in seven countries over four continents in three months. And very rarely did I actually end up staying in one place for more than a week. You can see I started in New York where I'm typically based my way through Europe, Germany, Spain, France, Italy, took a one-way flight from Rome all the way to Hong Kong, went from Taipei all the way back to San Diego, sorry, to Los Angeles and then finished up in San Diego. So just to give you a really quick understanding of sort of how this works before we move into Q&A, I just want to give you a sense of what my schedule might have been like in a single day. Let me just skip this slide really quick. So this is an actual day that I spent in Florence and this is what it would have been like when I was actually working full-time. 6.30 a.m., that's when I woke up and I really wanted to do this hike that was about two hours away by taking a train and at this point, zero hours worked. 7 a.m., I took a train to Chigaterre, that's where these hikes were actually happening and I ended up just doing a day trip before I actually had to continue my full day of work and I actually also ended up working on the train. So what I did and what I started out when I was nomadic was I ended up first catching up on emails and docs, making sure going over through the chat record the different things that people were emailing me and with all that time, it was really easy to catch up and actually do some work and with some quiet time. So at 9 a.m., I arrived at the trailhead. I already had two hours of work in because I actually did all my docs and also did my status reports and this is sort of what the trailhead looked like. So when hiking for two hours in the morning, still had two hours of work done, is what those hikes looked like. At 12.30, that's when I grabbed lunch and I still have two and a half hours. So the really nice thing about the time zone that I was in was that four to eight p.m. in Europe works to be about 10 a.m. to two p.m. in New York and that's actually a good sweet spot almost anywhere in the world. So I had about two hours left before I actually had to go back. Wrote some code locally, I was just at a cafe so that internet access could actually do some code while I was having lunch and yes, that did mean that I brought my laptop on hike. I took a train to the next town, took only like 15 minutes, still had three hours of work done and I could go to the beach because it was only 1.30 in the afternoon. That's what that looked like. 3 p.m. I took a train black to Florence and I got another two hours of work done. Again, sort of picking up the code that I did from before and moving on from there. So at the end of the train ride, I actually had five hours of work total. 5 p.m. of riding Florence, all my individual work done for the day and I could really dedicate my time to meeting starting at 6 p.m. when it was actually time to be in New York City when they were waking up. So two hour block to do meetings with New York. 8.30 p.m. Dinner, had seven hours of work done by that time and really is writing up my notes for the rest of the day and then 9.30 p.m., set the notes to the team and the day is finished and you can get, I can still get a drink if I really want to. It's still eight hour full day of work. Things I learned, it can work. The experiment was successful, right? I've been nomadic now three times, I'm actually doing it right now so this is not the last destination I have before I go back to New York City. I also realized I'm most productive at night when nobody can talk to me and I actually really get a private office and I also found out that it would probably help if I could just stay in one place longer than I needed to. It was really hard with interruptions if you travel a lot to do that and the one really funny last thing here before I finish is that it was really funny because I had to convince people that I wasn't on vacation, right? Because I was going to all these places but I was still working and I was like posting stuff to Instagram but people were like, oh I thought you were on vacation for three months and I'm like no, I'm still working full time. All right, that's it. I think we have a few minutes left for Q and A here but if you want to get these slides, I'm going to tweet these. My username is right there, John HM Chan. If you have any questions or want to ask me more about how remote works or what my nomadic trip was like, please feel free to ask. I'll be sticking around for the rest of the conference for the day. All right, thanks. Questions? Yes, right there. I'm quite curious on how you were able, I'm sorry, I'm quite curious on how you were able to somehow work out like a developer trying to push something or a code into production with the deployment team being away or the time zone is being different. So how did you empower them? So one of the really nice things about having remote work culture too is that because we're all over the world, we kind of get 24 hour coverage too. Because you're sort of in New York City, you also have people in California, you also have people in Asia and Europe. You kind of get somebody on call pretty much the entire time so you won't be completely alone when you want to do things like deployments necessarily. Now, it's not necessarily a good idea to be pushing it when there's nobody there and you have a risk of breaking all of Stack Overflow if you actually end up doing something like that. But the other nice thing is that we have a lot of automation and our DevOps team and the Site Reliability team is really, really great at making sure that you can end up doing deployments in a way that's pretty stable and pretty safe. Yes. I'd like to know how stable are your teams and how long are your projects usually? When you say stable, what do you mean by that? I mean, you stay with the same mates for a long time when you develop or going from project to project or do you switch very often? So the teams are really fluid. So there's two parts, one is about the stability and two how long the products are. The first is when it comes to stability, you end up working on a project to project basis because the teams are pretty fluid. I mean, I'm part of what's called the marketing engineering team and that means that I have to work a lot with a lot of other teams. So some teams end up working with a lot of other ones on a pretty regular basis and pretty frequently. But some teams, like the Q&A team for example, they stay pretty close and put their heads down, really focus on the Q&A product. So it really depends on what you're talking about. And when it comes to projects, that also ends up happening. That also depends too. Like I mentioned before that we had the weekly stand up that sort of gives you an idea of what the pace of things are. But the other thing here too is that a lot of engineers get a lot of autonomy like I've mentioned before to really push things through. So things like bugs, you'll see them sort of get from local to production, from discovery all the way out to a fix in a matter of minutes if you really need to. But for longer projects, things can take a few weeks to maybe a few months for really, really big projects. Other questions? Were there any legal issues when you were trying to implement remote when you were trying to do extreme remote, did you apply for work visas to work in Italy? That's a good question. So for when it came to legal issues, right? I picked a lot of the places that I ended up picking to because I wouldn't run into those issues being a United States citizen. So if you were in a different sort of situation you might have a few more restrictions there when it comes to working. But the thing is that it's no different from sort of traveling perpetually as long as you're sort of not going there to work for a company that is in that country. I was still technically working for Stack Overflow based in New York City as an American citizen. I just happened to be traveling and working at the same time. Any questions on the far sides here? I think it's on your hands. Just one question. Where's this coming from? Oh, here. Oh, sorry. So you were saying at the beginning that if remote is done properly it can be even more effective? Yeah. From what you described, the communication, you make a lot of effort to make the communication as transparent as possible. But still, if you're looking at the chat or looking at the record of the video it is not as effective as the normal meeting. So where does it coming from? Why do you think it can be even more effective than the regular office environment? So there's a few things here. The first is that you really get uninterrupted time to work. We really think, especially when it comes to engineering, when you're thinking about programming, how many of you, those of you that are programmers, how many of you have gone into a debugging hole? You go into one problem and then it turns into another problem and it gets deeper and deeper and deeper and deeper and then all of a sudden someone comes up to you and is like, hey, did you get that email I sent you? And you just lose everything. In a remote work environment, you don't get that because you have full control over when information gets to you and how that information gets to you too. Now there's a few trade-offs there. Like you Mahali mentioned, one of the things you might be thinking about when it comes to meetings is that you don't get to talk to somebody about ideas, right? But there's no reason that you couldn't do that asynchronously too, right? That's what chat is for and what email is for and what docs are for, right? You can write up all your ideas and then tag people and comments and be like, hey, what do you think of this line? What do you think of this? What do you think of this idea? Go to sleep, you wake up the next day and you get all the comments that you need from all the people that you need to. So yes, there might be a longer feedback loop there, but I don't think that it really necessarily brings down the collaboration aspect of that too, which is I think a big part of what you're thinking about when it comes to productivity outside of remote. Okay, thank you. Yes? Hello? Yeah, so have you worked in a non-remote culture before? And if yes, what's the difference in team dynamics that you see when it comes to non-remote versus remote? So that's a good question. Actually, something that I should mention is that I am technically not remote. I actually work out of our New York office and I'm based there. So most of the time I am actually in the New York office in a physical location. The really big difference is there are sort of the things I sort of just mentioned, right? I don't get live interaction when it comes to people that I need to talk to, especially when I'm in a place like Asia, for example, where everybody's on a 12 hour time difference from where it is in the United States. That being said, there's still a good sweet spot of when there's actually pretty good synchronous communication across the world. And I didn't really get to mention this, but there's sort of 10 a.m. or 2 p.m. in New York City, which is where a lot of the activity happens. That works out really well in Europe and in Asia because in Europe that's four to 8 p.m., so it's still reasonable for you to be working. And that's 10 p.m. to 2 a.m. And if you're a night owl like me, that's totally fine because that's when I'm most productive anyways. And what that ends up happening is that half of your work day is spent really doing individual work and half of your day is dedicated to meeting time whereas in a physical location, that's just interweaved across the entire day. I think that's probably the biggest difference in my mind. Other than that, we do a lot to make sure that it's not too different for each person. Then we have time for a few more. Yep. One more. All right, yes. So how do you build the company culture in the first place? So you're talking purely about remote working culture, but there is also a thing about the workplace culture and how do this aspect and building that firm culture go hand in hand? So there's a good question. When it comes to, well, besides remote culture, well, how do you build the other aspects of that culture too? The really nice thing and something that, I've been sort of talking about all these different things in the lens of remote, but the things that I'm talking about so far, really thinking about empowerment, really thinking about giving engineers end-to-end flexibility over the things that they are working on, giving people the flexibility to do the things that they want. Remote is just an expression of those values. Those things still are really, really important to people even in a physical location, right? So the things that we talk about, the onboarding, how we hire all those different pieces around the different values that we have are still part of the culture, but not necessarily just for remote. They also are expressed in how we think about management, how we think about people how, and when they perform at Stack Overflow across the entire board. So you're recruiting in the other units as well with the same case, right, in marketing in sales? Yes, I mean, when it comes to hiring across the board, for example, we still think smart and gets things done. You know, everything else is a proxy for those two things and that's regardless of whether you're in engineering or something else. And the different philosophies that we have around empowerment, making sure that management is sort of a support infrastructure for people, giving people autonomy to do the work that they need is something that's across the board. Okay, all right, I think that's all the time that we have for questions, right? But if you ever have more questions, please feel free to come up to me. If you have more, go ahead, tweet at me too. I'm gonna tweet the slides as well and I'll be sticking around for the conference. Thank you everyone for your time. Thank you.