Optimizing remote work: Pull Requests, Stand-ups, and emojis with Kasey Kelly

Speaker 1: All right, hello. I am Casey Kelly. I'm the director of user experience. And uh front end developer at Link and Loop. Uh today we're gonna be talking about uh optimizing remote work Uh why am I qualified for this? So Lincoln Loop is a full service web strategy design and development agency. And we've been remote since the beginning. Pete actually started the company by looking at GitHub users that were active in the Django space and started hiring from there. So we've been fully remote from the beginning. Some of those folks are still around and still in this room. Okay, let's start with some definitions.

Speaker 1: Remote work is decentralized space. So working remotely is the ability to work from a coffee shop or from your basement, not meeting together in an office and not being able to sit across the table from somebody and have a conversation. Async work is a little bit differently. Async work is decentralized time. So the ability to not even maybe be able to have a phone call and have to rely on things like text-based communication over hours or days instead of instead of that getting that immediate feedback. So we are all here in this room because of open source software. And open source software can only exist and can only be successful

Speaker 1: when remote work and asynchronous work. Um is used well. So we have this down. We've been doing this for a long time. We contribute to and we benefit from open source projects. And in general, online, we get by by being good people. You know, it's a it's a pretty low bar to just not be awful in the YouTube comments section, right? So our level of comfort in this space bleeds into other parts of our lives because we do this so much. Even things like the very offline hobbies that we have, like I'm a scuba diver and I play music. I will seek out those communities online just because I'm very comfortable with that. And it It

Speaker 1: makes us feel like we're not alone. You know, we make friends that way. Oh, no audio. Come on.

Speaker 2: You want to go do karate in the garage? Yup.

Speaker 1: Anyway, we are very good at this. We've learned a lot on our own just by just by being terminally online. Individually, we're very good at it. But what happens when we're managing a project with a team of our peers? What happens when we have an open source project that's becoming popular and other people are beginning to look to you for leadership? What happens when maybe you're not in leadership, but you just want to level up by working better together with the people in your community? Or often, our clients and our stakeholders and the people that we report to might not be as good at this as we are. So, how do we do status reports?

Speaker 1: How do we communicate progress? If you're an agency or a contractor, how do you communicate budgets and timelines and burn rates? How much communication is just enough? It's a lot to take in. And these skills don't come naturally. So here's the thing: maintaining emotional guardrails, maintaining productive focus across time zones, and a healthy sense of community, these things are hard. They're harder than just being good people online. Asynchronous, text-based communications is difficult and it's a skill that we have to develop. Whether that's in GitHub or Slack or email, whatever the medium is, it's a skill.

Speaker 1: So that's what we're going to try to tackle today. There are a lot of reasons that a project can go off the rails. Teams can erode because of one disgruntled person. Clients can be surprised by an invoice, and that immediately reduces trust. In open source, unanswered PRs can really derail a project pretty quickly. So, how do we go from herding cats to managing an effective team? The first step is to set expectations. We have to define the relationship in the early stages of a project. The early stages are high risk for both sides because you have to figure out if you're going to be able to work well together.

Speaker 1: We try to do that in the agency world with contracts. But contracts can be very one-sided. You know, you write a contract to protect yourself and to sort of set the really high-level guardrails on a project. But really, when it comes down to it, not everybody reads your contracts, especially the people that you might actually be working with day to day. Contracts might be read by the people in charge, the people writing the checks. But you really have to do a lot more interpersonal communication with the people that you're going to be working with more closely. So the emotional labor that we put in here is really important. We have to remember that we are the experts at this. This is new to our clients, our stakeholders, and sometimes even our peers.

Speaker 1: So we have to get that initial handshake right. So we have to remember that hiring us can be a really high risk decision. Sometimes, you know, hiring a big team is expensive. It can be a major uh a major spend for that company for a span of months or years. So we need to make the person who made that decision, the person who really vouched for us and helped us land that job. We have to make them look like the smartest person in the room when we are not around. So how do we do that? The key here is to demonstrate a deep understanding of the business problems that we're hired to solve

Speaker 1: So as we're developing this initial relationship with our clients and our stakeholders, we need to ask questions in a way that refine our own understanding of those major business problems. We're not just here to make software. We're here to help the bottom line. We're here to help systems run more efficiently. There are goals beyond let's build a Django project. And we have to understand what those are So when you can show that you understand the business problems, you'll build trust. And that will help you to do your best work. it will help to uh maintain that relationship so that when things go wrong, you have somebody on your team. So uh just as a quick example, sometimes we'll get overly prescriptive clients that will come to us and say, we've got this

Speaker 1: uh technical problem we want you to migrate from this front-end framework to this front-end framework. And in that very early stage of the process, we'll do what we're told. You know, we'll do what we're asked to do. But as the project unfolds, as things develop, maybe they might have been a little off the mark in what they what they initially asked for. And we can say, well, it might have been Or it might be a good idea now to go in this different direction, you'll get more bang for your buck this way. But you have to build that trust first. So how do we begin this relationship with a solid start and then instill confidence? Point backwards. Okay. So let's talk about meetings.

Speaker 1: The first step in developing this relationship and putting up the guardrails for a project is to develop the cadence of these initial meetings. So be strategic about when you schedule them. We like to set up recurring Google events to have these meetings between our sprints. So Uh on the current project that I'm on, uh, we meet every two weeks. So in agency land, it's really important to set these things up, but I'd also argue that for open source projects or internal projects or things that aren't like your main day-to-day job, it it can be even more important to set A date on the calendar for this is when we have deadlines. This is how we'll actually make progress

Speaker 1: because things can go off the rails if life gets in the way. So putting something on the calendar, trying really hard not to move those dates is important. It sets the rhythm of the work. So these meetings are for demos. You know, you want to show what you've done the last couple of weeks, plan for the next couple of weeks, and uh summarize the individual communications that have happened among members of the team, uh whether that's internally or with individuals at the other side. Really, it's a time to summarize. Here's what we've done. Here are the decisions that we've made offline, just to make sure that everybody's on the same page. This is not a time for bad surprises.

Speaker 1: Never come into these meetings blocked. Make sure that if you are blocked. You're having those conversations elsewhere and then coming in to talk about your successes. Ideally, these meetings, these scheduled meetings are for everything is going well. Um, so you you try to just make sure that um that that happens. For meetings like this too, we want to respect everybody's time, especially for these meetings where you might have more people in the room than the individuals who are actually working on things. Make sure you don't go over on time. When you are going over, let's say you've got somebody finally sitting down in front of you and they're hard to catch and you want to go over some features or things, give everybody else an out. If there are people involved in the meeting that that don't really add value, then let them go.

Speaker 1: You know, say if you've got other things to do, by all means, we'll catch you next time. So respect everybody's time. Along with that, don't invite folks on your team who don't necessarily need to be there. I like to summarize meetings for my team members and they appreciate that too. If it's not, if they're not going to add value or they're not going to get anything out of it, by all means, don't make the meeting more expensive than it has to be. So along those lines, absolutely bill for meetings. If you're uh in the type of business where you're estimating work and you're estimating projects, You have to include meeting time in those estimates because you're sitting at your chair. You wouldn't be doing this otherwise. So you know, the time that a project takes isn't just the time that your fingers are on the keyboard typing code.

Speaker 1: This is all part of it. So make sure that that type of thing is worked into your estimates. Okay, finally with meetings, be presentable. Um it's very important at uh especially at the early stages of a project that you um Take your entire surroundings into account. Um, you know, if you went to a a job interview, you'd want to look your best, right? And in a video call, everything around you, your audio video setup, your lighting your background is all part of your presentation. So uh consider that as if you're as if you're presenting yourself in person. That's all part of the same thing. I like to look at it, you know, I'm a designer and uh

Speaker 1: oftentimes people will pay designers because they want to look cool, right? And so if I show up and you can see a huge bag of cat food in my background, I'm not doing something right So you think about it like uh if you went to a barber shop and you saw two dudes there, one who's got a bad haircut and one who's got a good haircut, you're gonna go to the guy who's got a good haircut, right? So nobody wants to hire a designer with a messy desk. Okay, so that said, also set the expectation that it's completely fine to turn the video off. Video is something that we ran into in COVID when our kids were on video calls and they don't know how to do this stuff. Is it's kind of an intrusion into your home.

Speaker 1: When you get other people walking around, when there's noises, hitting the mute button isn't always, you know, something that comes naturally. So it can be really performative in a way that just being on audio is not. So there are no hard and fast rules for this, but uh but just make sure that you you're setting the right expectations for your team and being cognizant of those differences. So when should we schedule extra meetings? Um nobody likes to attend meetings that they don't feel that they add value to, right? Um, so when should you schedule extra meetings? When meetings or when someone is confused or frustrated, when you start to get the sense that someone's not happy. I am much quicker to say, hey, let's jump on a quick call and talk about this, because it's so much easier to diffuse

Speaker 1: frustrations or anxieties in person. You can actually get a real color of the person that way. And I personally, I just find that much more effective than trying to go back and forth and email, which can be, you know, kind of cold. So when should you not schedule extra meetings? Anytime you've got short questions, lean into async as much as possible. It's good for leaving a paper trail. It's good for searchability later. You know, if you've got a if you've got a video meeting, you might not always have the answers. You don't always take great notes that way. So if you can keep things in text. that you might like to keep archived, that's always going to be better. You can also keep things thoughtful and concise that way.

Speaker 1: You can revise a paragraph, you know, even a Slack message. if um if you're trying to say something in particular and it's going to be saved forever you can you can revise you can edit and it's just much more clear and easier for everybody Clear QA and status reports. If there's again leaning into the async, if there's something that somebody just tosses over the fence to you and you just need to review it. Um you have a bug report, all of that stuff, the more async you can do, the better. So really the best way to discourage Extra meetings is to be vigilant about asynchronous communication. So

Speaker 1: in summary for the meetings, uh make your meetings count, be efficient. Call out the wins, you know, uh talk about your team, be a good cheerleader, and summarize your work. Um and if anything can be async, make it so. Okay, so let's talk about the actual work. Sprints are the space between recurring meetings when the actual work gets done. Personally, I don't like sprints. I don't like the term because in a real sprint, you've got runners, most people lose, and everybody's winded at the end of it I would much prefer to call it something that is more indicative of a work-life balance that I would appreciate, you know. But sprints is the word we have, so that's what we're going to use.

Speaker 1: So during sprints, uh, as a team leader, I try to make myself available during the day when people are working, right? But um remote work isn't really asynchronous if you expect that from everyone around you. So there's always a balance with working asynchronously to not, you know, ping somebody over and over and over again unless it's super important. You know, don't don't abuse the the little red dot on Slack. So if you expect immediate responses, it's not going to go well. And you know, if you work across time zones, uh, that sort of thing is kind of baked into it. You can't avoid it. So um So when you've got people across different time zones, it does kind of help to set that culture for everybody

Speaker 1: So work achieving work-life balance really requires async work and it just lets everybody work at their own pace and it's it's much more um much more calm you know you you end up it it ends up making a better place to work okay finally um protect your team Uh an example here is I recently had a client, we no longer work with this person, but um he had the attention span of a goldfish. Uh he would be really excited about a particular feature, and then the very next day Um, he'd be off on some other tangent and say, why are we spending so much money on this thing? Things never shipped. It was a very stressful client relationship to have. Um Meanwhile, I was trying my best

Speaker 1: to uh keep that away from my team. You know, I don't want to bring that baggage. I don't want to spread his garbage out everywhere. So I was trying my best to take his feedback and turn it into something actionable for everyone else. So I try to absorb the brunt of the angry email. And if it is something something actionable and reasonable, then I'll kind of distill that and try to kind of you know remove the venom from it. So also spot and curb unreasonable expectations. That's just, again, part of team leadership is making sure that you're not you're not stressing people out unnecessarily. No client is worth losing a good engineer over.

Speaker 1: So as someone in a team leadership position, that's just something to keep in mind. But this isn't just for leadership roles. Every interaction that you bring to your work brings a certain color and temperature with you. And it affects everyone around you. So take care of yourself. If you find yourself bringing an ugly shade of red with you, calm down, you know, take a break. Don't respond emotionally. you know, write that angry email and then delete it without sending it and try again later. Um go out and touch grass. When you're working asynchronously, you should be able to take breaks. This that's all part of it. So

Speaker 1: everything you do in async communications, any sort of text base or video work, whatever, is painting a picture of you and your entire team in a certain hue. So just be aware of the the colors that you're painting into the world. So my most important point here about the work is if somebody has to ask you for a status update, you're not doing enough. You have to be clear and be transparent about your work. Make your breadcrumbs easy to follow between the different tools that you use. Because most of the time, different tools that we use have different audiences. You'll write PRs in a different way than you will respond to a JIRA ticket. because those things uh have completely different audiences.

Speaker 1: So that's kind of English class 101, but we forget sometimes when we're working, you know, in our basement on our computers that we've got other people on the other end of the line. So in summary, uh be focused, clear, and transparent and recognize the color that you bring to your interactions and really take care of yourself and be kind to yourself. Okay, so let's get into the actual tools that we're using day to day. The project that I'm currently working on uses Teams, Microsoft Teams, GitHub, and Jira, which They're fine. All these tools are fine. We we all have our preferences, right? Um and in agency land we

Speaker 1: uh are often dropped into clients that already have their own systems set up. And we try to not add friction by insisting on using the tools that we're familiar with. with. So whatever it is they want to use will will deal. And sometimes if I'm on two projects, that might mean I've got Teams and Slack open, you know, having these uh different different contexts for different things. So be flexible. But if you are in the fortunate position to make decisions about these tools for your team, um The only thing I'll say about that is make sure that your tools all work well together. If you're using GitHub and Jira, make sure that you've got those integrations tied together so that you've got those breadcrumbs that can tie back and forth easily All these tools have APIs. It's certainly easier to stay in the same ecosystem, but it's possible to

Speaker 1: sync it all up. So everything that you write in all these tools, consider your audience and purpose. I just mentioned that. But uh let's dive into some of the tools that we use So everybody knows what a PR looks like. For this project, PRs are internal. Our client doesn't review our code. They have developers on staff, but they um have completely trusted us with this particular product. So they're not really in the weeds in the code. So this this PR uh I what is this? Okay. I um Made sure that I spell out the QA, you know, this is how you fix this bug, or I paste in URLs, uh

Speaker 1: go exactly to this spot. to recreate this problem and give full context for here's what I'm trying to solve, here's where I am. And then also I'll often give PRs that aren't quite ready yet. So I want the backend team to start working on this job. While I've got the design 80% there. So I'll say things like, here's where I want you to focus. Here are some things that I'm not quite ready. uh for you to look at yet or if you have ideas for this spot. I haven't fully fleshed it out, so don't treat you know this column over here as like this canonical thing. So just Be very clear with your status on things too. So this is the problem we're trying to solve together. Giving business context, going

Speaker 1: back to um Going back to that initial idea that we need to make sure that everybody on the team knows what the real problems are that we're trying to solve because nobody wants to work in a vacuum. Nobody wants to just say go make these database columns, right? So also on this on this slide, notice my emoji here. A lot of times we'll use emojis in plain text areas to help with wayfinding. You can imagine a list of PRs with the little work in progress emoji, and it's very easy to see these PRs are not ready to merge yet We also use emojis in our CLI tools once in a while. They're great for anytime you've got a big block of plain text that you want to call something out. Using emojis strategically like that is really nice.

Speaker 1: Okay, so the next tool I want to talk about, I have kind of geeked out about this at work for a while now. Um I love Loom. Loom is great for short video features, short feature demos and uh bugs. You can say, okay, here's how I reproduce this thing. So you don't get to tell me I you know works for me. Um so it's uh it's good proof and it's it's very nice to have like just walk through this one feature really quick and we use it for clients, we use it internally and it's just it's super nice. You can record something very quickly. And then as soon as it's done, it will open up a browser window with the URL. So even before the video is done uploading to the server, you can copy that URL, paste it in, and be on your way.

Speaker 1: It's very nice. The one thing I'll say about videos though is keep them very short. I've got some that are under 10 seconds where I go and re reproduce a bug and ship it off. Sometimes I might go up to two minutes where I'm demoing a short uh new feature. The the longer you make it, the more annoying it's going to be for everybody because you can't just skim a video in the same way that you can skim text. The last thing that you want to do is create a super long video and have somebody and and this this happened which is the the the reason I can talk about this, but uh this client made an hour-long Loom video

Speaker 1: where he just went through the entire app. And said, fix this, fix this, fix this. So it took me a couple hours to hit pause, take notes, try to scribble down the URL that's, you know, real small at the top of the video screen. It was just such a nightmare. So I did that for my team exactly once, and then I told the client never do that again. Okay, so you've recorded your video. It'll give you an immediate URL, which is great. And it's got the the the other nice thing about Loom is they've got just enough editing tools. So they've got some AI features where you can just hit a button and it will trim out all your verbal ticks and Spaces. So if you've got something loading in a terminal window and you're waiting and waiting and waiting, you can just hit a button and it'll trim all that out.

Speaker 1: Um it'll also process your transcript through AI so that it sounds a bit more uh like real language instead of a choppy video transcript. So it's it's really nice in that regard. Bradcrumbs are really important here too. You really want to paste in your links if you've got If you mention things in the video that are on live URLs, paste in the links in the comments and things like that. And also paste links to the video itself in all the tools necessary. So if you've got people that use Jira and people that use GitHub, make sure that all your tools are up to date. So being precise and concise at this stage makes for a more pleasant experience for the whole team.

Speaker 1: And it makes everybody as efficient as possible. So you've written a great pool request, you've recorded a Loom demo. It's time for uh facing the client, which is yet another audience to think about. So you leave a comment in JIRA, you change assignments and link it all together. Make sure that the statuses across all your tools are up to date because everybody who uses their particular tool needs to be able to trust that it's all in sync. So that's the day-to-day. But the bigger picture here is important too. Point releases are a great way to give a high-level overview of the life of a project A week of work might be condensed to a single bullet point.

Speaker 1: And this is a type of communication that is important as a project. has a long history and also um with projects that might have stakeholders that aren't in the in the weeds with you. So it's really nice to be able to trust this data as well and have it Have it concise and accurate. So we use a tool called TownCrier to put up effective guardrails for our point releases. To make sure they're accurate. So the way we do this is we protect the main branch, and then everything that is merged into the main branch of the code repo is happens in a PR and then you're not allowed to merge the PR unless the tests pass.

Speaker 1: And so these this all happens in GitHub actions. So one of the tests that we have checks for a markdown file in the changes folder of the project. So anytime you want to merge a PR, you have to describe what is in it. So you have a markdown file that just describes very quickly what this PR does. So the way that happens is your file names have a syntax that organize the change log. So this particular example, you can start the file name with a ticket number. So that will link back to Jira using settings that are just in the town crier settings. So you've got the

Speaker 1: The ticket number there, and that'll populate the link. And then you can add feature or bug fix to the file name as well, and that will organize it chronologically under the right subheading in the changelog. So then once we've got that, the GitHub action will create a new release. So you can see here we're using the workflow from main and we're going to create a patch release. and branch from the main branch, release it from the main branch. So that creates a commit that looks like this. It removes all the markdown files from the changes folder and appends that into the changes. markdown and then the GitHub Action will take that data from the changes markdown file and create the tag

Speaker 1: for the release. And so then that creates something like this. So that gives you all the right data to have your point release. And then once that's created, we can deploy to the server based on another GitHub action. So the other really nice thing about forcing this workflow is that bi-weekly status reports become a lot easier. I just make Google Docs with things like budget, timeline, the general health of the project, any blockers that we have. And I can just take screenshots of my point releases here to give a really nice summary of what we've done in the last couple. of weeks. So most of the time these aren't going to be read. That's the thing about these status reports is they're nice documents to have.

Speaker 1: They're a good like, you know, cover your butt. uh documentation but uh I don't spend a whole lot of time on them. They're really they're for stakeholders who aren't necessarily in the day-to-day of the project. So finally, we need to record our time. We use Harvest. There's a lot of different time recording tools, time tracking tools. The important thing is to be able to record your time in a way that your clients can see, you know Um in your invoices, that's yet another audience. The people that are writing the checks need to be able to see what you've worked on. But also the data has to be good for internal tracking to make sure that your estimates are good so that your estimates can be better the next time. And here in particular, this Harvest

Speaker 1: plugin will look at the URL of the page that you're on so that you can tie every hour that you log to a particular ticket. So that that helps with the breadcrumbs, again, tying all this data together. Okay, I could spend a whole talk talking about Slack, but I'll try to be brief here. We use a lot of dedicated channels in Slack for different priorities. We have a Today I Learned channel, which is just things that anybody can post to randomly and uh you know if you go check on that on your lunch break every couple weeks just to read an article or something that's fine but then we also have back end help and front end help which the priorities of those are more important because that means somebody's blocked and

Speaker 1: um And so everybody kind of keeps an eye on those to make sure that everybody's moving as quickly in their projects as possible and they're not getting frustrated with things. For client channels, we often have internal and uh shared client channels. Uh, you know, and that's not just for we want to complain about the clients. uh it it's oftentimes we have a lot of things to talk about that we don't necessarily need the clients to hear all that noise. So we've got the channels dedicated to the shared projects with the clients and you know, we just use those appropriately. Um as far as the culture stuff with Slack, avoid using DMs. Um maintain a culture of transparency. You know, try to uh avoid keeping private conversations as much as possible.

Speaker 1: So if there's something that can be public, it should really be public. Likewise, avoid using the at channel directive where it pings everybody with a lot of noise. It is easy for things to get missed in Slack. So I understand the temptation to use channel for that sort of thing, but even still, if you're away from your desk, you might still miss it. So So it's not it's not always the best tool for the job. So when you consider using channel, uh maybe consider a different tool instead because things will get missed in Slack. So, some of the other mediums that we use for this. We also have a Basecamp channel. This is used for more thoughtful, considered conversations that ought to happen over days or weeks instead of hours and minutes.

Speaker 1: This is not for chat. This is for things like I've got this proposal. Let's talk about it. Let's let's rehash. You know, do we really want to keep this client? Do we want to what what's our company retreat going to be this year? That type of thing. So conversations that are not day-to-day critical, but you need to be able to reference later. It's just much more archival. Otherwise, we use Notion. Notion is for documentation type communications. Onboarding doc. Company details, anything you might use a wiki for, where it's just the static data that we need to be able to reference for a long time. So if Slack is the town square, then Basecamp might be closer to a city council meeting. It's a little more formal, a little more archival.

Speaker 1: And Notion would be the library. And then there's email. Email is email. We all try to avoid it. Nothing important happens in email. Nothing internal happens in email. It's for sales and for dealing with folks who aren't in the day-to-day of the business. And I know I just said you bring a particular color with you, and I just put that on the slide. Which, you know, I know causes a bit of anxiety. So sorry. So here, this is my cat. This is this is Cosmo. So we can all just take a breath and hit reset. So, those are the tools that we use. Take a critical look at how you can set different guardrails for yourself.

Speaker 1: Hold yourself accountable to making changes, and it'll pay off. Because here's the thing. For all of us at different times, the soft skills are the hard problem The clearer your communication is, the more precise and concise that you can be day to day, the less time that you have to spend communicating with other people at all. Because when everybody is happier, the communication side of our jobs becomes less of a chore. Happier and more productive teams Make for optimized profits and deliver delivery and ultimately a healthier work-life balance. So that's remote work. Thank you for your time.

Speaker 3: Thank you, Kissy.

Speaker 1: Excellent.

Speaker 4: So I'm curious about um kind of your expectations around responsiveness, uh, because I find with Slack sometimes I get a response the same day. Uh, but sometimes it can be multiple days before somebody gets back to me. And at least we've tried to set the expectation that Slack is the immediate tool And email is the it can wait tool.

Speaker 1: Yeah.

Speaker 4: But not everybody seems to have observed that.

Speaker 1: It's tough. You know, the more you expect immediate reactions, um The more you're going to be frustrated with Slack. You know, it's the kind of thing where we're not shy about asking multiple times. If there's something that's important, um, you'll get pinged again. And you know, there's a there's a bit of social shaming that goes along with that. Like everybody knows the the person who has to get pinged three times before something happens. So um yeah, it's a balancing. for sure. But yeah, email, email gets completely lost. We don't we don't do much internally in email at all.

Speaker 5: Hi, thank you. Our team is extremely distributed, so we have time zone issues. We have people in the UK and California and Australia. And so any meetings at all are kind of impossible unless somebody is willing to stay up till two AM.

Speaker 1: Yeah.

Speaker 5: Um and w so we do most things asynchronously, but people still want to have that sort of You know, because we never see our colleagues. Like people want some FaceTime. Do you have any strategies or have you found anything that works to sort of keep engineers engaged on a team?

Speaker 1: Yeah, good question.

Speaker 5: So no one because it it tends to be like certain time zones end up being preferred.

Speaker 1: Right. It is. It's tough. You know, we have um Most of our clients are in the US, but we have uh engineers all over the place. We've got somebody in New Zealand. So he's a great example. He and I have, he's on the team that I'm working with right now. And he and I have four hours of overlap a week because my 4 p. m. is his 8 a. m. the next day. So all we get is an hour of overlap Monday through Thursday. say and it works really well for us. But um but yeah he's just gotten used to you know he's kind of he works while everybody else is asleep and there's not a whole lot we can do about that. We do try really hard to have um uh actual face-to-face meetings every couple of years.

Speaker 1: We'll do a retreat. We try to get as many people as possible to come to DjangoCon. We've got most of our team here. this week. And that's that's part of it because we never see each other. And this is just, you know, it's an important part of team building for sure.

Speaker 6: Hi there. Sorry, uh I'm in a remote, pretty well distributed team too, and I think you I think you touched on this a little bit, but I'm really curious uh what does and doesn't work. You said sprint, so I'm assuming some implication of daily stand-ups. The idea of putting all my developers in a room once a day and making them like Talk of it just makes me want a barf. So I'm really curious, like, what have you done in terms of stand-ups? Do you ignore them? Do you do them in Slack Do you use Basecamp? Like what if what hasn't worked and what has?

Speaker 1: Yeah, so I think every one of the people that lead a team come up with their own cadence for that. Um the particular team that I'm on right now, we end up having fairly regular stand-ups, you know, we'll I'll catch Chris in in New Zealand probably two or three times a week in a quick video chat just to say what are you doing, what are you up to? Um, because oftentimes um he'll he'll end up doing work and i it's difficult to know where he left off if he's not leaving real notes. You know, I can I can pull down his code, but I have to kind of hunt and peck. So it's it's important that I do actually talk to him occasionally. Um and every team's going to be different. You know, we don't we don't mandate that we have to have daily stand-up.

Speaker 1: Oftentimes if we've got a solid week worth of work and everybody can just go off and do their thing, maybe we catch up on Friday and that's that's all we do. So yeah, there's no hard and fast rule. But it's kind of the thing where as in a leadership position, you have to do whatever you need to make your team effective. Good question. Anybody else?

Speaker 7: Yeah.

Speaker 1: Yeah, go ahead.

Speaker 7: So uh thank you for that. So uh I just wanted to ask you based on your experience, how does data science fit into your your experience. I'm a data scientist, so that's that's why I ask.

Speaker 1: Yeah.

Speaker 7: You know, what works and what doesn't based on your experience.

Speaker 1: I have zero experience with data science. I'm a designer.

Speaker 7: Okay.

Speaker 1: No, sorry. I imagine a lot of the skills can can apply though. You know, it's people are people, no matter what you're working on. So just make sure to stay focused with your team.

Speaker 3: So we have two minutes. Anyone has that question? Okay.

Speaker 8: How would you encourage people to get into those public channels and out of the DMs if you had to make a public service announcement or Something.

Speaker 1: Um, you know, it's a culture thing. It's uh you have to lead by example. Um Any any sensitive conversations, I think are still completely fine in DMs, but but really sensitive conversations I'd also argue ought to be done in in as face-to-face as possible. That should be a video call. It shouldn't be you know, throwing text over the over the fence at all. Um, but yeah, it's kind of a lead by example. Make sure that you are doing as much in the public channels as possible. And you know, a lot of that is the casual channels just getting people comfortable with saying hi in the morning and things like that. We've got some folks that never chime in and we've got some that every morning they're just you know posting a little hand wave emoji just to say, hey, we're here.

Speaker 1: Um we're real people sitting down getting work done.

Speaker 6: Hi, we don't work together or anything.

Speaker 1: Yeah.

Speaker 6: Um my question is um how are you teaching people who are new to re remo remote work or new to the company that you work at that I don't also work at, um, how are you setting the stage for the expectations and the culture? How are you communicating that? So that someone sort of new to the company can figure out how to fit in and find their flow with you and be effective.

Speaker 1: Yeah, that's been an ongoing conversation with us for sure. Um a lot of that is the Notion document. um the onboarding there's there's not a whole lot that you know you you can write about this but you have to experience it the culture thing is you know it's called culture like it's it's a people problem Um so you've got to lead by example. You've got to make sure that you're showing people what leadership looks like and what growth looks like and asking what do you want to see from your job? And help then helping them get there. So it really is a lot about listening and um and just demonstrating this is this is how we work. This is what we do. Um, and this is kind of what we expect. So giving people a lot of grace too, you know.

Speaker 1: Um it's it's difficult to take a new job, no matter how cool it is. Like it's super fun to work with me, but not everybody knows it right away.

Speaker 3: Yeah, so in the interest of time, you'll find us in the Lincoln Glue booth. Yeah, he's there. You can ask him all the other questions. And thank you for your time. Thank you also for coming. Let's give him a round of applause.

Speaker 1: All right. Thank you. It's been a lot of fun