 I'm here to talk to you about local and remote teams. And who here was in the last talk as well? It was an awesome talk, wasn't it? They really did a great job with that. I'm gonna cover some of the same things. It'll be a little different, it'll be from my perspective, but yeah, I really enjoyed listening to Glenn and Maria tell their experience as well. So my specific perspective on this is looking at hybrids where we have team members who are local and team members who are remote and how to get the best of combining those two styles. So I wanna start with a quick poll. If you would raise your hand if you today are primarily someone who works locally in an office, not maybe not every single day, but most of the time you're in an office with the rest of your team. Okay, maybe half. And then how many of you are primarily remote? The other half, makes sense. How many of you would like to do the other? Okay, so that's what we're gonna focus on is some of the advantages of each, why you might choose one versus the other. I think there's a lot of value in each one and I've done both and I enjoy both and there's a lot to look at there. So an introduction, a little bit about me first. My name is Ben Klang. I have been doing Ruby for 10 years, doing open source for 20. A lot of my appreciation for remote work comes from open source, where when you're doing open source work most of the time it's remote anyway. Your collaborators are in other parts of the world. Previously I founded a company called Mojolingo. We were a software consultancy. We were a remote first company from day one. About 12 people, not a huge organization, but definitely learned a lot from that experience. Today I'm vice president in business technology for power-humor modeling. It's a much larger organization. About 2,000 people in the company, 51 in the technology department. We have seven scrum teams, six states, four countries. And really about half and half when it comes to local versus remote or local versus distributed. And again, I want to stress, this is my experience. You know, it comes from what we've done in the past and what's worked well for us. I would say that everything you hear today has come from something we've learned, something that hasn't worked. And I'm sure that some of the things that we do today we will find better ways to do tomorrow. And that's okay, that's just part of the process. So I want to start with a little bit of background. Like what kind of teams exist? What are we talking about when we talk about remote teams? And I want to emphasize that when I say team, I'm really thinking of a fairly small unit. I'm thinking of three to five people, not the entire department say, but the actual people that you depend on day to day. The kind of people where if they're not around, you would end up blocked, right? So first of all, local teams. That's a pretty easy one, right? People in the same building. Not really in the same building, but in the same floor and in the same room even. I'm reading that people who are just separated by as little as one floor start to lose some of the benefits of being a local team, right? Some of that face-to-face interaction is lost when you have to go out of your way to interact with them. So local teams, we're focusing on people who are physically co-located together, preferably in the same room. Another one is remote teams. Again, pretty intuitive. People who are spread out in many different locations. Sometimes it'll be at home. Sometimes it'll be in a coffee shop. Sometimes it'll be in a coworking space. We actually do have one guy on the team who for some reason just loves coffee shops. He will spend his entire morning in a coffee shop. I couldn't deal with the noise, but he works for him. And then there's a third type, which are mixed teams. So this is a type of team where you have most of the people on one physical location, and then one person who's kind of an outlier. This is, to me, this is an anti-pattern. I don't really want to talk about it much other than to say, I strongly advise that you don't do it. This can lead to isolation, right? This can lead to this one person being left out of conversation. This can lead to people not having the same level of understanding about what's going on within the business, what's going on within the team, what's going on within the software being developed. And sort of another spin on the same topic is where you have one team that is split into two parts. So you have a part of the team in one location, part of the team in the other. Again, you'll end up forming clicks. There'll be small communication patterns referenced to Conway's law earlier, right? When people are communicating together, the organization will develop that way. So again, I don't recommend this style either. So I'm gonna say something that may be controversial. Maybe you agree with me. I just ask that you hold your pitchforks until the end and I'll explain why I think this. But I feel pretty strongly that local teams win. They're the most effective, most efficient way to develop software. I don't think, I think that all else being equal, if you can control for everything else, having everybody in the same room is gonna be the fastest way to deliver what you want. And I say this myself as a hybrid employee spending about half my time on site, half my time working from home. I say it as someone who founded a business that was remote first and successfully remote first. I was very happy with that company. And I say this as a manager of three remote teams and one local team. I think it's better for communication. I think it's better for camaraderie. Better for brainstorming and for resolving issues. And even Scrum teaches, we follow Scrum pretty religiously and one of Scrum's big things is, get your teams co-located, right? So this isn't just me saying this. This is kind of the wisdom being taught. So then why even talk about remote teams? If local is clearly the way to go, why would this even be a conversation? That's because we wanna be remote. A lot of us wanna be remote. Just from your hands I saw earlier, half of you are doing it and another good chunk of you would like to swap whatever you're currently doing. So there's a really great Stack Overflow article or rather survey and it came up with 53% of people looking for jobs want some kind of remote option is a top priority in seeking a new position. Which means if you're trying to hire these people, this is a major competitive advantage for you. If you have remote options in your employment, then you have the attention of a very large number of job seekers right away. Additionally, 11% of remote workers report higher job satisfaction or I should say the job satisfaction is 11% higher among people of remote options versus purely local. So it's not just about acquisition. It's also about retaining the teams that you have, keeping them happy. Happiness is correlated with productivity and with longevity within the organization. So this is a big deal, right? And I do wanna touch on something I think that Glenn and Maria said very well, which is that not every position can be remote and within our organization we've called out a few specific types of positions that we don't, we will not consider remote applicants. The two that are kind of obvious are application support and infrastructure support, the people that day-to-day have to interact with some of the end users. We are self-hosted, so we have our own physical infrastructure and we have the teams that manage that infrastructure. We want them local in case something breaks, they can unplug it and replug it as necessary. And the third one, which is a bit of a shift for us is junior development teams. So we actually, we did a first time for us, experiment a year ago, where we put together a team of developers who were junior and paired with them a mentor to bring them up to speed and we did it as a remote team. And it was successful, I wanna say that the people who went through that program are all with the company still today and they're absolutely valued members of the team. But what we found was it was harder to support them and mentor them in the ways that they deserved. It was harder to establish the kind of communication to jump over to the whiteboard and explain some kind of complex process. Then it would be if they were local. So going forward, we've started saying that all junior developers, we wanna put them at headquarters where they can be mentored with other team members and given that the attention that's necessary there. So what are the benefits? What are the benefits of enabling teams to be remote? And I'll start with benefits to employers. First of all, obviously it's a broader applicant pool. If you're looking in one location, best case scenario, you're kind of saying give me the best person within 50 miles. That's just a small pool to begin with no matter where you are. If you can open that up and say give me the best person plus or minus three hours, suddenly you have a lot more options to choose from. And ultimately what you really wanna say is who's the best person for the job? So as your organization continues to expand and as you can start to form teams in multiple locations, as you can start to organize teams around locations, you're not just looking at one geographic location or even one time zone, you can actually look around the entire world. This has a bunch of advantages. It has advantages like taking better advantage of referrals. So the people on your team are going to refer their friends, hopefully. If you're a place that they want to work, hopefully their friends also want to work there as well. And if those friends happen to not be in your city, you might not have the opportunity to work with them. It definitely improves things like time to hire. So as we grew, we had to grow, we doubled in size twice over the last two years, basically double each year. And the only way we could do that was looking remotely. We just couldn't get a big enough stream of candidates looking only locally. So that was a major shift for us. But it also increases the opportunities for diversity. I think that the last talk mentioned this well, you know, if you're a mother with a newborn child and you don't want to or can't easily get to the office, that's a limiting factor, right? When I was a single father, my daughter would come home from school at 3.30 and I could be home to be there with her. That was a big deal for me, right? That meant that if I was tied to an office, I would have to drive home to do such a thing. And that's not feasible, right? But if I was able to work from home, I could be there for her. So that was a big benefit for me. So let's start with the benefits to the employees as well. I talked about being home when my daughter got home from school, it's more than just that. It's also a choice of lifestyle. For myself, I like living in the city. I like being in an urban area. I like not having to have a car. I like being able to walk to shops and restaurants. That's quality of life for me. A very good friend of mine, he had five kids, has five kids. They lived about two hours away from the office. So two hours one way to drive from his house to the office. And at the time, the company we worked with, this was 10 years ago, they did not have remote options. It wasn't on the table. So every day he would drive two hours into the office and he would work full day, and he would drive two hours home. So four hours of his day. By the time he would get to the office, he had already been up for at least two, probably three hours. He was tired from the drive. He was stressed from dealing with traffic. And then even at work, sometimes he would be trying to figure out how to make his commute better, trying to find just the right time to leave to avoid traffic, or started looking at train schedules to try to figure out, is there another way for me to get to the office? No doubt that impacted this productivity. There's just no way you can be as effective when you're spending that much of your energy getting yourself physically to a location. So getting to live where you choose and being able to do so remotely gives you that flexibility, gives you the option of picking the lifestyle that's right for you and being able to have the job that is right for you as well. So one size does not fit all. And then there are mutual benefits. Things that benefit both the employer and the company. Life is not static. The one thing we can count on is that it will change. What has actually happened with a lot of our team members is their life situations have changed and they have needed to move. So one of my favorite examples is a very good friend of mine. He was living in the UK. He got married to a Brazilian and they wanted to live in Brazil. If his employment had been tied to his physical location, then we would not have been able to keep him within the organization. And he's a very strong developer. So that was important to us, like having him be a part of organization while he still was able to live the life he wanted to do and allow his life to evolve in the way he wanted to evolve it. That's important. So that gives him the ability to transition his life while retaining the stability of his employment. And it gives us longevity of someone who's a valued team member, somebody who knows and we've already invested teaching him about the organization. Those are things that benefit both sides pretty well. So location independence adds longevity to employment, which is a win for both sides. All right. There are challenges. No surprise, right? Remote's not all easy. I hope everybody had brought a pencil and paper. I'm going to give you the three most important bullet points. Remote work. Everybody ready for this? Okay. Number one, communication. No surprise. Communication is the biggest challenge to remote work. What may not necessarily surprise you is that number two is also communication. And number three is communication. Right? Got it? Okay, sweet. Communication challenge number one. My favorite, time zones. Love time zones. Hate time zones. Time zones were the biggest factor in figuring out how and where to grow the team because while we don't particularly care where you live, we do care that you have the ability to communicate with your team. We do care that you can support each other. We do care that you can ask the questions and get answers and get unblocked. So we have a rule of thumb. A team should not spread more than three hours total. Not plus and minus three hours. Three hours total, right? So we try to group things, and these circles are not exactly representative, but the point is that we try to group teams such that no one is more than plus or minus three hours than anyone else in their team, and that gives a nice amount of overlap to the workday. Now you'll notice that some of those circles are decidedly longer than three hours. And as I mentioned earlier, one of the benefits of smaller teams is you can orient your teams in such a way that the teams themselves are within that three hour rule. But across the organization, you can have multiple teams and you can spread the work around that way. So that does work. Communication challenge number two, being able to understand things deeply. Not just superficially, but truly understand the work you're doing and why you're doing it. I love this quote by George Bernard Shaw. The single biggest problem in communication is the illusion that it has taken place. So you might spend a bunch of time trying to explain what we're building and why, and depending on how you do it, you may or may not have actually been heard. I think this is one of the reasons we love whiteboards, because when you can get up and draw something, it pictures worth a thousand words. It makes it so easy to explain relatively complex concepts when you can map them out like that. The problem is that doesn't really work so great when you're remote, right? You can't just pull up a whiteboard. We've tried lots of online whiteboarding tools, and they all are kind of disappointing in one way or another. But you have to replace that somehow. So we lean a lot on video conferencing. We lean a lot on screen sharing. Screen sharing is huge. Code reviews are a big deal. And then my CIO's favorite, flow charts. Don't be afraid of the flow chart. This maybe took me 15 minutes to put together. There's no color. It's a bunch of boxes, a couple errors, and a little bit of text, but it really conveys very quickly some things we're trying to get done. And so this has become part of our culture, and we're even trying to encourage more of it. The point here isn't to burden you with documentation. The point here is to communicate as clearly as you would on a whiteboard. And if you start to build that into your culture, you can partially solve this problem of deep understanding. All right, communication challenge number three. Perceptions and distractions. Everyone knows Dilbert? If I can't see them at their desk, how do I know they're working? It's a real problem, right? Anyone dealt with this? Yeah. Point to your bosses everywhere. There's a flip side to this, though. As a remote employee, my team leader is always multitasking. How do I know if she's taking me seriously? A lot of our communication happens in videoconference. Videoconference, for most of us today, means working on a laptop. So if I'm speaking with someone on my team and we're having a great conversation, it is really tempting. Really tempting just to alt-tab, pull up email, answer something, answer a quick instant message. That is so destructive. It's so destructive that the conversation is happening. It's even worse when you do it in a stand-up or a retro and you're not paying attention to the team. That's something you have to fight. It takes conscious effort. It doesn't come automatically. You've got to put that away. In addition, you need to make sure that... Back to the first point about... If I can't see the team, how do I know they're working? You need to also make sure you proactively manage up. Talk to your supervisors. Let them know what's going on. For us, a lot of that comes through dealing with tools like Pivotal Tracker and Coderviews. A lot of it has to do with retrospectives and, excuse me, stand-ups and sprint planning. Those are opportunities to communicate within the team about what's going on, but also to communicate about progress, so people know what's happening. I'll talk more about that in just a second. So that's kind of an overview of some of the benefits and challenges. I want to be really specific and talk about how we do it. These next few slides are going to talk about what we do at Power2 to work through these challenges. We understand that there's value in both styles of work, local and remote. We understand there are business realities of acquiring and retaining the people that we want on the team. And then retaining has a lot to do with happiness. So we needed to find a way to get the best of both of them. First, we looked at structure. Small teams. Three to five people. That is a big deal for us, is keeping it small. And if a team starts to get too big, we don't hesitate to split it apart into smaller teams. And also consistent teams. They believe we're not trying to mix local and remote. You can put two people in one location on the same team, but if you do it, they need to act as if they're remote. They need to be on video conferences on their own computers, and on the same, they have parity at the communication layer with everyone else in their team. So it doesn't feel like there's just two people and then the rest of the team. Back up one. Okay. Then we have process. Scrum. As I said before, we're a big believer in Scrum. And there's this sort of related concept of Shu Ha Ri, which is where in the beginning you do it exactly like the book says. And we're probably at that point now. Most of what we do is doing our best to stick to the principles exactly as written without too much variation. And then the next step for that is Ha, which is where you understand the principles and you can start to bend the rules where necessary to adapt to your situation. And then there's a mastery level, which is where you completely understand everything and why the rule exists in the first place and then you can break the rules whenever you want because the rules no longer exist. Sort of like the matrix, flexes his arms and the walls bend. I want to do that. So for us, that process, it's really important to have the right and the right parts for managing the communication, ensuring the communication with remote teams. Standups, if nothing else, give you an opportunity every day to make sure you communicate with everyone on your team. It's really easy to do, right? If we were all remote and just focused on our pull request, it's so easy to get into the editor, push the code, move on to the next thing and not even talk to anybody. But standups at least, if nothing else, will give you a chance once a day to communicate. And retrospectives as well will bring that to the surface. And it's just, again, another way to checkpoint communications, make sure they're happening regularly. Of course, you have to emphasize remote-friendly communication. We do a lot with code reviews. Every single piece that goes to production has had a code review. It's one of the three criteria we require to ship code. Obviously, text chat. A lot of people use Slack. We have a tool internally called Connect. It's the same concept, but it's critical because it facilitates communication within our development team, but also within the larger company. Anyone can talk to anyone at any time. That's critical. Video conferencing and screen sharing, I mean, I've already given the examples for that, but, again, without the ability to pull up a whiteboard, being able to at least look at the same thing and talk about it makes a big difference in facilitating communication. And then, as I said, diagrams. Love diagrams. It is my goal to, at least once every 90 days, spend some time face-to-face with everyone on one of my teams, just to have that personal relationship with them. We also do lunch and learns, and I got to give credit to Jill who's in the audience and probably modified I'm calling her out right now, but she did a lot to make lunch and learns happen for our team. She did a great job with that. And that has been not only helpful for onboarding and bringing new people into the organization. It's also been really helpful in just getting people talking across teams. As we emphasize small teams and as we grow, we end up adding more teams, they don't necessarily communicate as much as they would otherwise. So lunch and learns are a great way to get a larger group together. And then she was telling me yesterday she wants to do coffee dates, which I think sounds like an awesome idea. So I think we'll be doing that when we get back. All right, so we've talked about how we're doing it. I want to talk about one more topic which is how we optimize for the different styles. First of all, we're going to talk about how we optimize for local teams. For the teams that we have decided will be local, whether they're development or support or DevOps, there are a few things we can do to make them more productive, to maximize the benefits that they have. First, we built a headquarters that has a lot of collaboration space. I mean a lot. Probably at least within our department's sort of area of the building, at least half, maybe more than half of the space is dedicated toward collaborative areas. So when you build up, there's power to plug in. There are, I don't know if those little puzzle piece chairs are. They're sort of like bean bags, but it's sort of not. But it's just a more casual space where you can discuss things. And we use that space not only for internal conversation. And I think this is really important. We use it to also talk to the business. These two rather serious-looking fellows are from our talent acquisition department, and we're in the process of building some software to help them automate some of the work that they're doing. This is them coming into our area and speaking with the guy in the red shirt, it's an application support guy, and he's explaining some of the features we're delivering and some of the bugs that we're addressing. And so this is communication not only for within the team, within the department, it's also communicating out to the business. So there's a real danger if you have an entirely remote team that nobody can see that stuff just happens and nobody knows about it. This is part of our effort to make sure that the business knows what we are up to and then on that same kind of vein and actually even more outbound, we have this area called the Knowledge Dojo, which is very much modeled on the Apple Knowledge Bar concept. We have this area which is outside. It's in a very public space, a hallway where a lot of people walk by, and anyone who has a technical issue of any kind can walk up and ask questions. You know, I need help with a mouse or printer ink or I have trouble with the application. And again, it's just putting a very public face on what we're doing and why. Ultimately, if you do this right, if you build the kind of connections with the rest of the business, what it does is it lowers resistance. I don't know, I don't think I mentioned this early on, but the business we're in is homer modeling and the company we're in is in many ways traditional. Very local, very much. People come into the office, you saw the people in suits, that's because they actually wear suits. And we're a little different. Not only do we not wear suits, a lot of us just aren't even there. So we need to manage that. We need to let them know that we're working with them, so it lowers the resistance to enabling remote work. And then finally, as developers, sometimes you just have to get away from the noise. So we have these little pods we built. There are 12 of them. For the people who are local, they become their office. And then for the people who are remote, whenever they're at headquarters, they can use them as office space. They're quiet. They're away from the noise. And then the colorful lights, besides looking really awesome in this picture, if the light is red, it means you're busy. You don't want to be disturbed, and please leave me alone and come back later. And if it's green, you can come in and have a conversation. All right, that's what we do for local. What can we do for remote or distributed teams? Daily stand-ups. I'm just going to hit that point again. That is a big part of how we manage the communication, how we keep the communication good. And we don't have to take them too seriously, as Darren is showing you. What else do I want to say? The other thing I wanted to say about this is this is kind of an interesting team. This team has since been reorganized so that they are now entirely local. But at the time this picture was taken, three of the people were physically in the same location, and two of them were in remote locations. But the reason I show this is this is a good example of getting everybody on the same playing field. You'll notice everybody is at their own workstation, on their own computer talking and communicating as peers. So the guy in the bottom left and the guy in the bottom center and the guy in the top right are roughly 10 feet apart from each other in their cubes. But whenever it came to team communication, they would level the playing field to ensure that. I talked about getting face-to-face as a way of enabling remote communication. And this is a big part of it. So it's not just for work. We do a lot of work. We do this three times a year. We call it Create. We bring all the developers, all the remote workers, two headquarters. We bring all the remote communication support teams that they work with. We bring in the infrastructure teams they work with. And we find... It's not a hackathon exactly. How would you describe it? Basically, we take goals and projects that are hard to get to in the normal cycle of development. Sometimes they're bigger picture architectural things. Sometimes it's a cool feature that we just couldn't work into the normal flow. And we'll go build it. We'll spend a week building it. What's cool about this, and what's cool about this kind of emergent behavior was that the teams self-organized and they did it in different configurations than their daily teams. So when they're out in the field, maybe you have this group over here and this group over here, but when they actually came to this session of headquarters, they picked completely different people to work with. And that's beautiful for the kind of personal connections that are necessary to both grow and also to get questions answered beyond your team. And of course, it's not just work. It's social too, right? So we have both structured and unstructured time where people can... We were doing some kind of weird game show thing. So that's one of the structured examples. We've done go-karting. Almost killed somebody, but it's okay. He survived. But it's important, right? Because these are things that are hard to do in your remote. It's hard to build those social connections and the trust that comes from goofing off with somebody. All right, so in summary, three things I would say. When you have a local team, you want to optimize those face-to-face interactions. That's your core strength, right? You've got people there. You want to give them as many opportunities to communicate with very high bandwidth, both internally and externally. Second, you want to develop the tools and practices that are necessary to make remote work successful. And this doesn't happen automatically. It takes effort, it takes conscious thought, and it takes evolution, and that's the status quo. Whatever you're doing today is great, but there's always something you've been doing better. And the retrospectives are... and create are big parts for us for analyzing that process, finding ways, finding what's working, finding what's not, and then finding what can be better. I want to give you two links for further reading. I want to thank Martin Fowler for a really awesome article that guided a lot of my early thinking about how to build distributed teams. He goes into some more detail on some points I kind of glossed over here, highly recommended. And then weworkromotely.com when we were hiring specifically for remote developers. This is where we would advertise and got great responses. It's such a focused demographic, I think, that helped a lot. It's also associated with a book that the guys at 37 Signals put out called Remote. It's the website that goes along with that book. That's it. So my name's Ben Klang. I'm at Beklang just about everywhere, GitHub, Twitter, et cetera. And thank you very much. I'll try to repeat the question. One of the slides I had a team that was hybrid, the mixed that I said was a bad idea. And the question I think was when we did bring them in to make them a local team, how did we handle that transition and what happened to the people that were remote? Did I get that right? So a couple of things. One of the people just started coming into the office more regularly and he was already in the area but it wasn't a big deal to start commuting, right? The other one was in Australia and he's kind of an interesting story. He came in the organization by a fluke. To be really honest, I missed that he was in Australia when I started the interview process, but by the end of the interview process I was so impressed with him that I said, we got to make this work. And he was great because he actually worked really hard. He, for probably seven months, eight months lived on East Coast time in Australia. Which, God bless him. I couldn't do it, right? But anyway, we ultimately actually had sponsored him and had him move to the United States. So no one on the team was let go. We did reorganize to put them all together. But we made that happen organizationally and they were all on board with it. That team in particular, it was a positive thing for them. Right? So to repeat the question, what kind of mix is the situation? And I'm not sure if you were the only person that was in the outsider or one of a... Okay, so you were in that picture where you had a bunch of you in one location and one person remote. And then to your point, you were having conversations and decisions being made sometimes without that person just because they were spontaneous. And then how do you deal with that? It's tough. If you find yourself in that situation, the only advice I can give you is that you have to be very conscious about it in a mode where they can be observed by the person remotely. Text chat is probably the best place for that. I don't think there's an easy answer. I wish I could give you one. Our philosophy has been just don't do it wherever possible. You can somewhat help that by keeping your team small. There's less of a risk of that if you're only having to manage three or four people. If you're keeping the team small, it's harder to have one person remote. You're either all going to be remote, you're all going to be local just by virtue of having a few people to adjust. But yeah, I hear you. That's a difficult situation. And I would... Best thing I can say is just try to avoid it. That's a good question. So the question is, are there certain types of projects or I guess to extrapolate certain kinds of work? Or projects? The technology... Okay. That are better suited to local versus remote. Yeah. Well, so projects that require you to physically touch things like putting a server into a rack, that's an easy one, and that's really what led us to wanting those teams on site. In the development space, I'm trying to think of any project where it's purely writing code where we have that issue. Nothing comes immediately to mind. Everything, once you get past that physical realm, as long as you have a way to communicate, I can't think of any... I think that either can be made to work effectively. With the provisor that you're doing all the other things, that you're doing stand-ups, you're doing retrospectives, and that you're gathering the team so that the communication is occurring naturally. Oh, one thing I didn't mention is besides just the three times a year, if we have a big launch for a big feature, we'll bring the team to headquarters for a week and we'll focus on the stories of that feature and the payoff for that lasts. We might spend one week on site figuring all the pieces out, and then for three months, they have a really good, clear picture of what they're trying to build, and we're mixed right now. What's my recommendation for getting past that? To make them work. To make them work. When we did it, we had the same problems that I've talked about where people felt isolated, people were left out of decisions, and what we tried was a lot of video conferencing, a lot of text chat, a lot of notes in wikis, in pull requests, written documentation, and then would try to encourage people to remember when you had a pull-up conversation to go dump the artifacts from that into something that everyone else can see. It can be done. My personal opinion is you've just got to be superstar, focused on proactively pulling those people closer and closer to make sure that it happens, and I think that's hard. I just think human nature is too easy to have a quick conversation without actually informing anyone else. My advice would be if you can try to reorganize such that you don't have the mix. That takes time. I'm not saying it's easy or automatic, but it can be done. I just think it's hard, and I don't think we will do it again if we can help it. That's interesting. In your company, it's mandated that you have teams that are mixed, some remote and some local, with the goal being to ensure consistent culture. What are the ways you can address the culture arguments while not doing it in a mixed team mode? Right. Tactically, some of the things I talked about, the lunch and learns are good because they cross teams. Because they happen regularly, in our case, every two to three weeks, depending on how excited people are about finding something to present, at least everybody's coming together for that. The other thing we do, is every week, we do demos on Friday. Again, that's the entire department. Everybody gets together, everybody sees what everybody else is doing, and everybody gets to ask questions. In some cases, in this case, right now, we have two teams who are working on alternate sides of the same feature. One happens to be local and one happens to be remote. In those cases, we are trying to do more. We put them in a single chat room. Those are all really small answers to your questions. I think the bigger answer is, the answer to culture itself is culture, is getting people to understand each other, to respect each other, and to want to communicate with each other. All of these other things kind of grow out from that. I don't think culture is easy. I think it's conscious, and I think it can be done. And again, bringing people together so that they get that face-to-face time helps with that. Does that help? Good. Anyone else? Awesome. You've been a great audience. Thank you very much.