 Well, thanks. Thanks a lot for coming. My name is Dave Copeland, or DaveTron5000 on Twitter. And I'm going to talk about how to be an effective remote developer, I hope. So I spent the last four and a half years as a remote developer. I was one of the first engineers at StitchFix. We're a personal styling service for men's and women's clothes. And when I started, we were very small, scrappy startup kind of thing. And I was just writing code as one does in that situation. But due to the way we work at StitchFix and over time, my role has also changed. So I was a tech lead of a small team, and now I'm a manager of several different teams. And so I've worked with a lot of different people than just developers. Certainly, I work with a lot of developers, but I work with people who use our software. The business people who run StitchFix, vendors that we rely on, all remotes for that entire time. And that's pretty typical of a developer at StitchFix. We now have over 70 engineers, and most of the engineering work at StitchFix is done remotely. Over half the engineers don't live in the Bay Area. We're headquartered in San Francisco, but most engineers don't live there. Those that do live in the Bay Area certainly come to the office, but they don't necessarily come in every day. So there's a lot of remote work happening. So what does that mean, remote, though? When I was thinking about this, it occurred to me that people work remotely a lot more than you might think. If you think about what that means. So I tried to describe it. Bear with me. You do not often interact face to face with the people you work with. It's not a great sentence. I tried very hard to make a better one, but I think this gets the point across. You go somewhere and do work. Maybe that somewhere is a coffee shop. Maybe that's your basement. And you work with people. And those people aren't there most of the time. So that's the situation that I mean by remote. And if you think about it like that, there's a lot of remote work happening in the world, not just with developers. So there's the lone wolf. This is the hard mode of remote where you are by yourself, and everyone else you work with, is that some other office tricky. But what we're going to talk about in this talk applies to the lone wolf. You also have easy mode, which is everybody is distributed. No one goes to an office. There is no office. Everyone sort of works whenever, wherever. That's a little easier, but still the same things apply that we'll talk about. But think about multiple offices. Like, you could go to an office every day, have a commute, go to a desk with a computer and all that entails, but the people you work with aren't in that office. You're a remote developer because you're working with people who aren't there. So that's what I mean by remote. So we also have to talk about what is effective. So obviously producing some value. Your company's paying you to do a thing, and you need to do that thing. So that's part of it. But for you, you also want to be working on something valuable. You want to make sure that you're working on the right things, that those things are useful, that people want them or get some sort of benefit out of them. You also want to have some level of agency. You don't want your job to just be closing your tickets all the time. Like, you want to have some broader effect on the team, the people you work with, the company, something like that that's not just doing the task in front of you, but growing as a person, and you need agency and impact in order to do that. You want to feel included. You want to feel like part of the team. You don't want to be, again, the person whose job is just to close your tickets. You want to be part of the group moving forward on a collective goal. And you want the experience to be rewarding. No one wants their job to not be rewarding. And to the extent that having to have a job is a necessity, you want it to be as rewarding as it can be. Now, I don't want to imply that you get these things for free just because you go to some office. But you get some of these things for free just by going to an office. Like, there is this sort of implicit level of effectiveness that you can just get for free by being with everyone that you work with. So what it means is to achieve these things when you're remote, you have to just work a little harder, and you have to be more intentional in your behavior to make sure that stuff happens. And that's what we're going to talk about. There's not a week that goes by that I don't think about the remote experience that I have or that the people I work with have. And it does require constant upkeep. And it is not what I would call easy. It's not impossible, obviously. But it is a part of my job to work on this and make sure that the behavior that I'm exhibiting is doing the best to make the remote experience good. Of course, it's worth it. Who works remote most of the time? OK, all right. So you know what I'm talking about. It's totally worth it because you get this level of freedom and flexibility that you don't get by having to go to an office. I don't have to commute anywhere at all. I can make lunch in my kitchen. My kitchen is, in fact, stocked with these snacks that I prefer. And I don't have to stock other people's snacks. I can work outside if it's nice. I don't have to use a public bathroom. But the best part about working remote is I don't have to live in San Francisco. I love not living in San Francisco. My favorite thing. No offense to San Francisco, but I don't want to live there. Now, the company gets a benefit from this, too. The company, I'm sure, is very happy that I get to make lunch at home. But really, the company gets access to a wider pool of talent. So that's why they are also willing to spend the time on this sort of thing. So if Stitch Fix had decided that every engineer had to come to some office in San Francisco, it would have taken us much longer to build the team that we have, it would have been harder to build the type of team that we have, and it would have actually had a significant impact on the company's growth. And because we committed early on to making the remote thing work, we're able to get people from all over the place. I'm not sure if you are aware of this, but there are developers who are really awesome, and they don't live in San Francisco. There's a few of them. So we've got a lot of them on our team, and it's awesome. So this is how we do that. So it's not technical. I'm not going to talk about Slack or anything like that. You have to spend your energy building trust with people that you don't know, and maintaining trust with people that you do know. And you have to be constantly doing this. So that's what we're going to talk about. Behaviors that you can take in a very small way that contribute to building trust with other people and acknowledging that trust. Anyone ever heard this phrase, the half life of trust is six weeks? So there's a tiny link there that you shouldn't bother with. You can go to the slides later. It's a blog post by Steve McConnell. Steve McConnell's an author of software books. He wrote Code Complete. And in the blog post, he talks about his frustration working with a team located in India, which is halfway across the world from where he was. And he recounts one of his managers saying this phrase, the half life of trust is six weeks, which sort of implies that if you take no action, if you don't do things to reinforce and replenish that trust, it's going to go away. And when you're not present with people, it goes away much more quickly because you don't see them. Like you get a lot of trust by default by just being around people. And as a remote developer, you're not around people. And so you have to work extra hard to make sure that the trust that you've earned continues and that you're building more trust and just replenishing that constantly. So I've got four mindsets that you can use to drive your behavior that I believe will build and maintain trust with other people. And we're going to talk about those with respect to all the different things that we do as developers. They are communicate frequently and clearly, be responsive, but set boundaries, assume good intentions, and help others help you. So the theme here is that you have the power to make your remote experience good, and we're going to talk about things that you can do to do that. But we do have to have a brief chat about technology. So the biggest problem with being remote in terms of communication and building trust is, like I said, you're not actually there. So you don't have the ability to go over to someone's desk and talk to them. You have to go through some piece of technology to be able to just communicate with them. And so you're going to need a few set up. You're going to need some sort of chat system that people can use, and that they check, and that they're in. And I said the word people, not developers, right? So it's got to be something that every person that you need to interact with is going to be able to deal with. IRC is not that thing. I'm sorry. You're going to need a video conferencing system that accommodates multiple people and that they can use easily. And again, this is people, not developers. They should be able to include meetings and calendar invites. They should be able to connect them to room systems or other things like that. They should be able to get in and out of them very easily. So WebEx, anyone like WebEx? Anyone love WebEx? No. WebEx meets the standard even though it is terrible. So again, the bar is low. You just have to have it there. And if you don't have these things, the entire thing is very difficult. It's also not very interesting to talk about because you just sort of need to pay money and get them set up. And I don't want to trivialize that, but that just needs to happen. You also need a non-shitty microphone. So people's experience of you, yes, those of us who have dealt with shitty microphones, people's experience of you in real time is mostly going to be talking over a video conferencing system, which is very terrible because all that that entails. It's not the same as talking to a person face to face. And you can't control the crappy internet and terrible software that's involved. But you can control the input to that, which is your microphone. So your laptop mic is shitty. I'm sorry if you feel otherwise, but it is. Apple earbuds are perfectly fine. You don't need an amazing $4,000 ribbon microphone. You just need something that works and is near your mouth while your buds work. So technology over. Back to the harder parts, which is building and maintaining trust. So I outlined these kind of four mindsets. So I want to talk about the kinds of behaviors that they can drive when you're doing different things that are part of your job. So we code, right, mostly. Hopefully, we're coding most of the time. That's the output of our work. We communicate asynchronously, like with an email. We communicate synchronously, like on a video chat. And we socialize. So we'll talk about each of those four things as we go. Coding first, right? Coding, that's a thing you're hired to do. That is the thing that makes you a developer and not someone else. This is probably what you're spending most of your time doing, and this is your work product. So how do we communicate when we're coding? So think about what it's like to walk into a room with a bunch of developers. What do you see? You see people typing on a keyboard, into a black rectangle with white text on it. And maybe they're working, maybe they're not, but they sure look like they're working. And just that visual image is actually important. And people will assume, well, the developers look like they're developing because they're typing into rectangles. When you're remote, you don't have that at all. So to build trust, you need to produce things. And so a way to do that, which is also a great way to write code in general, is to turn larger projects into smaller ones. Find a way to take whatever your problem is and get parts of it in front of other people quickly, whatever your process is. This lets people, first of all, a small change is easy to understand. A large change is not. And so when people see you produce a small change, they're going to see that frequently, and they're going to be able to understand it and give you feedback on it. And that lets them understand you better. And that also shows that you are producing stuff and you're driving towards a result. And that builds trust because they can see that you're actually doing something. When you're making changes, think about what is the smallest viable change. Because you have to think about it not just, am I getting the code to work? But can someone understand what I've done so they can give me the feedback that I need to know if it's good so they can say, yes, this can go to production? You want to optimize the way you work so that people can understand that because you're not necessarily going to have another way to talk to them. The only communication you might have is the change request, whatever form that takes. So if you're thinking about redoing the test because they're not R-spec enough, don't do that. If you're thinking about refactoring this ugly code you don't like, don't do that. If you're thinking about fixing some white space because it offends your sensibilities, don't do that. I've done all those things and it does not help communication at all. When you are submitting your change request, however you do that, so it's stitch fix, we make pull requests to GitHub, whatever your process is, you're presumably going to have to write something to explain what you've done. Write more about it than you might think you should. Because again, you're optimizing for people to understand what you've produced and so you need to give them some clue as to what they're looking at and why they need to look at it and what you want them to look at. So when I do this, I try every time to write the word problem and hit return and I type a sentence or two about what I'm trying to accomplish. I hit return and I type solution and hit return again and I write some couple of sentences about how I approached it, what I tried to do. To give somebody a chance at understanding what I've done because that might be the only chance they get to understand what I've done. More practically speaking, learn how to screen cast and diagram. So early on at stitch fix I was working on software and there wasn't an easy way to share it with anyone. There wasn't really a staging server that anyone could feasibly use and I'm not there to bring my laptop over to show it to someone. So I would just run the app on my laptop and screen cast and just talk over using the app in my development environment and that is way easier to explain what you're doing than typing a bunch of stuff out. I use this thing called Jing. It's free for five minutes or less. You can share the screen cast privately. If you just get really good at doing that quickly then this is a thing you can just do without friction and include. Diagrams the same way. Just buy OmniGraphil and learn the keyboard shortcuts and then you will make diagrams very quickly and easily and then that is a thing you can bring to better communicate with people. Being responsive and setting boundaries. So the first boundary you need to set is your working hours. Especially when there's time zones, right? I mean, does anyone like time zone math? Cause talk to non-developers. They don't even know what it is. They're not gonna do it. So you need to help them. So there's a lot of ways to do this and you have to take a wide approach. So I set in my calendar what my working hours are. I include my time zone in my email signature and then when people are interacting with me I try to be nice about what my working hours are. So if someone schedules a meeting with me at like six o'clock I say, hey, that's a little bit late for me. I don't know if you know this, I'm on the East Coast. Can we do this later? It's a very nice way to kind of set some boundaries not being a jerk. Or if someone's giving me feedback or I'm chatting with someone I might have to say, hey, it's the end of my day. I gotta take off. Let's pick this up in the morning. But you do need to set those boundaries cause people aren't gonna know and they need to know. So when you're asking for feedback when you're writing your code and you're like, this is done, I'm ready. What is the next step? Someone has to like say, yeah, cool. Or whatever the process is, you're kind of watching for feedback. And so the second you do that your job then becomes to respond to that feedback. Why? First of all, it shows that you're engaged and that you're trying to drive completion which builds trust because people like people that drive to completion. But it also allows you to capitalize on the context that people develop by giving you feedback. If someone like reads your pull request and gives you feedback and then you don't respond to it for a couple of days, well, they've forgotten whatever they looked at and they have to go relearn it again if they're gonna engage with you. But if you do it quickly and you engage with them back and forth then you're making everything better. And what I've learned is you need to develop a workflow that does not put you heads down away from all forms of communication for hours at a time. And this is really hard because sometimes as developers we need to do this. But the more you are not able to be contacted, people can't walk over to you. So they have no way to contact you except for the avenues that you have set up and created. And if you're not responsive to them then they can't take advantage of your expertise. And that is gonna drive you more towards the JIRA ticket closer and not closer to a full-rounded developer who has agency and impact and is growing the team and growing themselves. So I will happily tell you my crazy workflow that I do for this, it might not work for you. But the gist of it is I have an SLA for all forms of communication and I try to stick to that and I have a way that while I'm working I can check all the forms of communication to see if I need to do anything without forgetting my spot. Whatever works for you, try to find some way to do that. And the more you do build up trust though, the more you can kind of get away with being offline for a little while. So this could be a thing where early on you need to focus on being more responsive and as you kind of build up trust with people you can take more time to do this stuff. This is hard to do, it's very hard. Assume good intentions. So code review comments. Anyone like getting their code commented on? Is that a fun experience? Okay, yeah, it's very harsh. We as an industry aren't used to critiquing each other. We're not used to being critiqued. We're not good at it on either ends and so it can be hard to accept. And also people are bad at it and it can often come off mean or you can read a tone into it that is unpleasant. It's not good but you have to assume the only way to deal with this is to assume that the reviewer whoever's telling you stuff about your code they're just trying to help. They're trying to help make your code better, make you better, make the company better, whatever it is they're trying to help or they wouldn't bother commenting. I'm not saying to tolerate bad behavior but bad behavior is a pattern that you can observe one time thing, you have to assume good intentions otherwise you'll go crazy. Now a way to deal with this problem leads to helping others help you. Not everyone is good at it like I said but some people are exceptionally good at just talking. So if you're having an interaction in text that is not working then jump to video. Like this is my failure mode all the time as I never go to video but if you go to where someone communicates well then you will have good communication with them, right? It kind of stands to reason and instead of making people come to you you should also be specific in the feedback that you want. If you put up a pull request and say thoughts you're not likely to encourage good feedback. So if you actually specify what are the areas of your code that you want someone to look at? Like oh this variable name I had a hard time coming up with it I don't know, does this make sense or does this method make any sense? Could someone sort of help me understand does this look right? So that does several things. One it lets people quickly figure out what to do and can more easily engage with you which means that you will engage with them and that kind of builds trust but it also shows a little bit of vulnerability which is huge for building trust because it shows that you're willing to acknowledge areas of your code that aren't perfect and so then when people interact with you they know that they're getting an honest and authentic experience because you're willing to call out things that aren't perfect. Okay code, asynchronous communication. So all this coding stuff is a form of asynchronous communication it's very specific to our profession but you're also gonna interact with people not about code, writing emails, sharing documents, texting in Slack or something like that. There's all kinds of asynchronous communication and this is the primary way you're gonna communicate with most people just by nature of being remote. Fortunately this is a little easier to deal with so communicating frequently and clearly. You have to provide more context so when you're talking to somebody you can see their eyes start to glaze over you can see them get confused they can raise their hand, they can interrupt you if you're not like making a point but in an email or a document like you're not gonna get that you might never know if someone understood an email that you sent. So you need to provide a little bit more context to increase the chance that they are going to understand that. So explicitly state what problem you're trying to solve or what information you want or what you want them to do and why give some more back story so that there's a chance that they get what you mean. You should also become a better writer because you're gonna be writing a lot and this is how to do that. So you write something, you want someone to read the least you can do is read it yourself first and when you do that you find all kinds of mistakes in your writing you find all kinds of incorrect words and other things so everything that I write I read at least once and I revise at least once because there's always a way to make it better and I just do this all the time and as you do this more and more you make a habit out of this then you will do it frequently and the more important an email might be or whoever you're sending it to you will revise more and more and it just makes you more effective at communication when you're sort of at least taking it for a dry run. Typography matters. A wall of text is impossible to understand like hit return a few times make some paragraphs at least every few sentences there should be a paragraph or something but bold, italics, underline like those exist they have meaning you should use those bullet lists I mean it's stupid to say any of this but I remember in my youth every email was just nothing but courier text wrapped at 80 characters and if people wanted bold and that was their problem right that is not the way to effectively communicate. Again the diagramming thing is really helpful especially when you're communicating to outside developers or people who are not good at processing text which is lots of people learn how to make diagrams quickly and efficiently and that's tool that you can bring to bear and make things more clear. Being responsive so a lot of the things we talked about with code kind of apply here the point is you want to engage give feedback if you're being asked for it ask for feedback if you want it like engage so that you're interested in helping someone solve their problem because when you do this this is how you get agency and this is how you have an impact and this is why being responsive is so important you have an opinion about things and if you don't share that opinion with anyone then that opinion is not going to affect anything it's just an opinion that you have but if you share your opinion with people then that is a chance for you to affect how things are and if your opinions are good and they are helpful then you will be seen as someone who is good and helpful and that means people will trust your opinion and trust you and come to you and ask you for things and give you more of an impact on what you do and that makes a much better work experience so being responsive and helping people out is good but don't forget affirming feedback so all the stuff we've been talking about feedback is like critiques this is wrong, fix this, blah blah blah it's very easy to get wrapped up in that and we do want those that is the critique that we want because we want to be better but it is nice when someone tells you that the thing you did is good and it's even nicer when they say it in a very detailed way so if you say oh that API design looks good I mean that's nice, that's very nice but if you say the names you're using in the route map exactly to the domain which makes it really easy for me to understand this whole thing is like really simple thanks for putting this together that is really great to hear because it shows that you've understood what they've done and that you took the time to say something nice and it's if you're a person that says nice things to people it makes them feel good that builds trust so I used to think affirming feedback was pointless it is not pointless it is very, very pointful assume good intentions so a lot of asynchronous communication as you have as a developer will be with non-developers sometimes there are people that use ask as a noun or use solution as a verb and if you're like me it drives you completely insane but the point is that's just a communication style it's not an indicator of ability so I choose and this is hard but I choose to assume that everyone I interact with is killing it at their job that they're really good at their job because that mindset is the only way to deal with other people otherwise you get wrapped up in communication style I mean the number of power points that I have had to have a conversation about in the last four years is kind of staggering but that's how some people communicate and that's cool because they're good at their job and that's fine help others help you so again kind of same deal ask for the feedback that you want the other cool thing about this is this is another avenue to give context to help people understand what you're doing if you're telling them what you want that helps them figure out what it is you're trying to accomplish and is much more likely to garner some back and forth and for me anyway this is the hardest part is synchronous communication which basically means being on some sort of video conferencing system why? I mean part of it is I'm an introvert and so this saps my energy to have conversations but another part of it is that it's this weird uncanny valley version of having a conversation with a real person because you can see them and you can hear them but everything between you and them is terrible software that barely works and the whole thing is just awful and so it's just more stressful to have to deal with this but some conversations cannot happen over text like you have to have synchronous conversations sometimes so how do we deal with this? Be prepared so I find if I'm expected to like say words to people the more confident I am in the subject matter the more likely I am to say something that makes sense so read the material before the meeting see who's there what is the meaning about do you have an opinion about what we're going to discuss if so formulate that opinion in your mind at some level of detail so if you have to say something it will make sense and people will get it you should also try to speak with more nouns than pronouns when you say stuff like he, she, it, they, this, that, thing things not a pronoun but you know what I mean those words don't mean anything who knows what that means the only way you can know is if someone said a noun before and you can guess that that noun is the thing that that means and okay now I get what you're saying and when you're talking to a person like face to face you can see them get confused and be like ah okay sorry this is what I meant blah blah blah when you're on a video you can't see that also due to technology you will not be heard everything you say is not going to be heard someone coughs a word is gonna drop out two people start talking there's crosstalk people aren't gonna hear what you say the internet drops for a microsecond and one word goes I've been on video chats where I missed the noun because of technology and then for two minutes people were discussing and they never used a noun and I literally couldn't figure out what they were talking about and I had to interrupt and say what is the noun please I don't know what this means I'm sorry you've got to tell me so when you do that that means that the things that people do here they're more likely to know what you're talking about a better way is to pause frequently and ask for feedback right because people can't interrupt interrupting on video is very hard people aren't gonna start going to do it so take a moment okay this is my proposal for how we're gonna do this JSON thing does that make sense everybody and then you have this like pause when we do our all hands engineering meetings at such fix like you know I say like I said a lot of us are remote and our CTO is really good at doing this so she'll give us information and then she will pause and say anybody have any questions and then if nobody in the office has questions she will always say anybody on the phone have any questions and then pause for a very uncomfortable amount of time because she knows that it takes a while for us to oh do I have a question I do have a question let me ask that question like that takes a while and so she puts those pauses in there so that nobody has to interrupt and everyone has a chance to participate so when you're speaking you should do that being responsive and setting boundaries this is kind of the other end of this and this is the for me this is the absolute hardest part to not multitask so if you are in a conference room with people and you're on your phone or you're on your laptop like that's very rude and so you wouldn't do that because social norms say I got invited to a meeting I should pay attention in the meeting I shouldn't be on my phone but when you're on a video conference you're literally on your computer and stuff is popping up and you can check email and Slack and you can do these things you can tell yourself that you can multitask but you're not really paying attention and then either you miss things that are important or you get called out I have definitely been asked questions in meetings where I have no idea what to say and I just had the cop to it I'm sorry I was multitasking please please repeat the question that's super embarrassing when you do have something to say it is very awkward to jump in but sometimes you're gonna have to and because of all the delays that happen you may have to ask the group to backtrack and just be up front about it hey I'm sorry to jump in here real quick but can we go back for a second I had this thing and this comment like it's hard to do this some people just can't I have a hard time not as hard as others the pausing thing that I talked about if others are doing that that helps and when you do have the floor that is your time to set an example on explicitly calling on other people especially people that you know are not gonna be comfortable jumping in but you know have an opinion that is a really good technique oh Chris you just did this thing what's your thoughts right or anyone on the phone else have something before we move on that's how these meetings should be run and so you have to set that example whenever you can no one's gonna know that the AV is a problem but you this is like when someone has something on their teeth you just have to tell them because no one's going they're not going to know so you have to be comfortable pointing it out it sucks but that is a fact of life and of course you have to be self aware these behaviors that I'm describing that kind of have to exist on some level are jerky behaviors if they're done too much or too frequently or too aggressively and so you need to have a lot of self awareness when you do this sometimes you've been asking people for feedback when you're offline to say hey I'm sorry I kept interrupting you I'm really not trying to talk over you but maybe I was like give me your feedback on how that went so I can get better like yeah it's definitely hard and that sort of follows on assuming good intentions because people are gonna interrupt you and it's gonna seem jerky and you have to assume that they're just trying to deal with the technology the other thing though is that the people who are maybe not remote who are part of this who are in this mythical conference room they're not having a great time with the video chat either like it's not great for them to have all of this stuff going on it is friction for them and having some empathy for them is really helpful because it's actually something that you all can bond over I complain about the technology all the time and it's kind of can lighten the mood sometimes because computers are terrible like you have to rely on all of these servers and all these pieces of technology and they all barely work I'm amazed it works at all they don't work consistently it's just all just terrible and acknowledging that can make everyone sort of feel a little bit better about getting through the video conferences helping others help you so I mentioned before about the AV system issues this will definitely happen and you need to kind of channel your inner wedding coordinator and just tell people what they need to do because they're not gonna know hey point the laptop at Pat because Pat is the one who's speaking right like just tell people what to do they're happy to fix it but they're not gonna know because they're not experiencing the AV the same way that you are if you can recruit an ally or have a blessed back channel that is really helpful too so at Stitch Fix we do company all hands meetings and as I mentioned you know a lot of developers are remote but there's a lot of other remote people we have lots of different offices our stylists are remote people are traveling so remote is a big part of our all hands meetings and there's a wonderful person on our ops team who monitors the back channel and she asks questions for us and she fixes AV problems and we can handle this all by chatting and not interrupting the meeting so if you have an ally that is super helpful okay socializing why are we talking about socializing? you go to an office people know things about you even if you're the most private person on the world and you never say anything to anyone people will know like what kind of clothes you wear what your hair looks like how tall you are what time of the day you come into work how often you go to the bathroom these are banal silly things but people will know them about you and if you are not going to an office they will know absolutely nothing about you I'm amazed at the height of my coworkers when I first meet them it's not what I expect ever so what this means sadly for the introverts is you're going to have to make small talk you have no other way to interact with people and when you're on these video conferences especially with the west coast people are going to be late and so you have a lot of time to kill where you're waiting for everyone to find the conference room and get there so make small talk it sucks but you can talk about the weather and it's the beginning of a conversation the beginning of a personal connection for me it's easy because I live in D.C. where we have weather San Francisco they don't have weather so it's always an evergreen topic another thing that we do is we do one-on-ones with people that aren't our manager or aren't our direct report or anything like that with no particular agenda so I have a lot of one-on-ones with people where yeah we'll talk about work sometimes we'll also just sort of chitchat and sometimes it's just five minutes but it's a time set aside to interact as people as best as we can and it feels awkward to schedule these sorts of things but it's the only way to make them happen and it feels normal after a little while being responsive and setting boundaries so this is more about travel so getting together with people helps replenish this trust a lot it is really handy if you can do it travel is a pain so you want to make sure you understand like what are the expectations hopefully before you take the job and I guess I'm saying this because you might not be told what the expectations are because it might not occur to someone that travel is difficult for you or something like that so be clear about what the expectation is and try to do it when you can I mean a lot of us work remotely because travel is difficult or we want the flexibility to run our lives in a certain way and travel sort of disrupts all that it's totally true and definitely set boundaries but if you can travel it is worth it to re-establish those bonds with the people that you work with every day because you do refresh that trust by seeing people in person assume good intentions right so people are gonna make a small talk with you too because they're gonna want to know who you are and they might ask things that are uncomfortable and they're not trying to be nosy they just want to get to know who you are if you have things about your personal life that you don't want to talk about that's totally normal and totally cool but that's all the more reason to do that whole small talk thing if you're driving the chit chat then you can drive it in the direction that is safe for everyone and just be okay missing social events like happy hours my respect and admiration for my coworkers is not derived by the number of beers I have shared with them it is by the good work that we do as a mindset I take and so therefore I don't care if I miss happy hours or social events I enjoy them when I can make them and it is nice to have a beer with my coworkers but many of them I've never socialized with at all and they're still great people that I love to work with so you just have to sort of be cool with it but it doesn't mean you can't socialize at all or you have to miss everything what it kind of means is that it might not be clear what those things are but if you have ideas, bring them up like you'd be amazed at how successful you can be by bringing your boss an idea that requires your boss to do absolutely nothing but say yes you do that, you're good but it does mean you've got to kind of take the initiative there if you can find a way to have in-person meetups be creative about it there's a couple of developers live on either sides of our Dallas warehouse and every once in a while they will go to the Dallas warehouse and work together they don't work on the same project but they get to see each other in person and have a little social interaction be creative and bring them up and suggest them and often your boss will be happy that you're helping to figure this problem out because they're not going to know how to make the experience good for you so all of that are tiny little things that all build little bits of trust between you and others and when you're trusted and you work with people that you trust you are going to be way more effective at your job way happier you're going to have much more agency you're going to be producing much more value you're going to feel included and the whole experience is going to be much more rewarding so that's it these are the four mindsets again communicate frequently and clearly be responsive but set boundaries assume good intentions and help others help you I have just kind of described how things are in my company and so you should come work for us or you can or just talk to us and we'll tell you how all this is and we can give you all kinds of details on how this stuff works for us and then that other link is for these slides that you can check out if you like, so thank you yeah so the question is when there's social events and there's business talk you're missing out on that and that's a potential thing that is absolutely a problem and that's sort of a company culture thing and that's hard to fight it's hard to fight information happening that you aren't even aware it's happening like that is tough getting to know the company culture before you kind of make decisions helps and asking about that directly sometimes is the way to do that but that is potentially a problem for sure yeah so what's the good frequency for visiting up with people so when I started I did every two months because I was new and I knew I had to put a lot of effort into making it work and that was helpful right now the team gets together every three months and for me personally I do that but then I end up going for random other things in between but everyone comes every three months and that seems to work pretty well thanks a lot everybody