 I'm here to tell you about remote working and why you shouldn't or shouldn't embrace it. You totally should, because it's awesome. Alright, thanks for having me. Alright, let's try that again. The stock might be better in title. How to do remote properly and when not to bother. So, a little bit about me first. My name is Toby. I hire software engineers for automatic. You may know us as a company behind workbots.com, Jetback, Gravitaro, WooCommerce and a bunch of other things. Right now there are 854 of us in 69 countries speaking 84 languages. We've been distributed since day one and that's nearly 14 years ago. So what's the difference between remote and distributor? In a remote setup there's an office somewhere and one or more people work in elsewhere. In a distributor company there's no office so everybody works elsewhere. The first setup is more common so I'm going to refer to remote working today, but everything I'm talking about applies to distributor companies as well. So what's the great about working remotely or employing people who are remote? In both cases the major benefit is vastly expanded opportunity. Let's say you're a typical Silicon Valley company and you're only looking to hire developers from inside the US. According to Stack Overflow's most recent developer survey you're excluding 77% of the 20 million developers who visit Stack Overflow. Talent is equally distributed around the world but opportunity is not. Remote and distributor companies change this equation and provide opportunities on both sides otherwise we're lost. Before we get too much further, let's define what we're talking about and what we're not. Remote is not just about being able to work from home and go for jobs, although that is a fringe benefit. What remote working is really about is flexibility. Flexibility for people with family commitments, with educational commitments, with disabilities or who live in other time zones to work on their terms and to be able to contribute meaningfully without being physically present at a particular time and place. Remote working is not easy. In fact remote working down there can be incredibly damaging. It's all too easy to develop habits that bring inefficiency, exclusion and an unhealthy working environment. It takes a ton of commitment and hard work to pull off remote working correctly. But it's absolutely worth it in terms of the access to talent and opportunity and a global focus in it. But what Mac has been doing this for a little while so we have a few tips for you. The first is to act as though everyone is remote. The second you have a meeting of nine people in a room and one on the zone, you've created two groups of people. It's far more inclusive if that meeting is 10 people or two. The second is to default to asynchronous communication. When you let go of the idea that everyone has to be available right this second, you give people permission to use the flexibility of remote working plans. One thing that makes asynchronous working work is to document absolutely everything. At automatic open source is our culture and it's a foundational principle. And documentation goes along with that. But too often documentation is written after the fact and only about the in-state. We document everything as we go along from the original idea through all the discussions and decisions and dead ends to the final product. That way our documentation is context which is something that's usually not done properly in some place here. You also need to be quite intentional about building a culture when you're remote with no such thing as bumping into the city on the breaker in it or heading out to spontaneous groups after work. Providing the opportunity and crucially the permission for socializing and fun is important. It helps create a shared argument. It is important to get together in person once in a while. At automatic we do team meetings once or twice a year and they're all company-grounded at once a year. So these are opportunities to not only get a bunch of work done in a really accelerated way but they create and cement bonds that carry us through the rest of the year. The key with me knows is to make the best use of them by being fairly ambitious about what you want to accomplish but not to rely on them too much. So Congo say there are a few notes. The first is the conversations about work that exclude your colleagues. Don't talk about work issues on the phone in person or in a DM. Do it in public slide chat. If you can't do it in public make sure you recap the conversation in public while. I've been in a situation of previous job where I had to scrap the week's worth of work and start over again because I've missed out on one conversation. There's nothing that fills me around like having your time wasted. As with most workplaces in a remote environment it's dangerous to assume communicate. At automatic we have a saying that communication is the oxygen that we're distributing in company and that is 100% correct. If you're going to use a remote model don't negate the benefits by insisting that people stick to a particular schedule. This just tells your people that you don't trust them and people don't respond well to that. Embracing a remote model means embracing a certain loss of control and that only functions if you trust your people. And finally don't call it an experiment or leave yourself on the scapegoat. You have to commit. Trust goes both ways so allow your team to trust you. Ultimately though the remote isn't forever. When shouldn't you bother? From the perspective of the business implementing the remote in an existing environment takes time and resources that you may not be able to commit right now it's not something that you can do halfway. From an individual perspective ask yourself if you'd be suited to remote work or do you perhaps need the structure that offers a community? Do you need to be around people? Another thing to consider is that when you onboard people into a remote company a lot of the time they're onboarding and inter-remote work at the same time making it right becomes even more crucial. So if you were turned over in the first year as relatively high you need to fix your onboarding process before you can reduce the complexity of the remote. Genie developers ramp up the complexity even higher. You're onboarding the inter-developer as well as your company in the life of inter-remote work. It's a super event since it's not for the environment. It's something that we haven't been able to do it on although it's something we're working on. So going back to my original title remote working why you shoot or shouldn't embrace it. You should embrace remote working if you're looking to expand your options past those that are in your immediate area. You should embrace remote if you're aware of what it takes to succeed and if you get it to do it again. And you should embrace remote if it's a fit for your values for your circumstances and your needs. And again, thanks for having me. Any questions? Anyone have any? So the question was what's the best practices for selecting team members for remote work? Our hiring process is fairly intensive and it simulates the more working environment as best we can. So we have a paid trial that is done entirely remotely and our entire interview process is done remotely. So it's very, very similar to the normal working environment. So that works really well for us. It exposes inability to or people who are not suited for the remote environment. It exposes that fairly quickly. Generally speaking, what we look for in people are just communication first and foremost. You know, people who over communicate or who really want to do well. So the question is whether there's any online resources about hiring people or not. Something that we're working on. It's in progress. So not yet, but so. Time for one more. So the question was whether we have any tips about organizing remote retreats. It's a little bit different for us because we've gone to the point now where we have to be able to fit 850-odd people. So at the moment we're sort of constricted to resorts and larger convention type destinations. But internally, because we do meetups twice a year per team and with some of the teams, we sort of maintain an internal blog that just compares destinations, where we stay, what the internet was like, what the cost was per person, how much travel time there was involved in getting there. So basically just give it a shot, but document everything so that you don't make it save the state twice. Yeah, never say never. I'm not sure if it's on a list of things to do at the moment, but it's definitely a very useful resource that we probably should consider making some developments of the public. Alright, thanks everybody.