 It's an honor and a pleasure to introduce our next speaker, Naritzee Sanchez, who is a senior open source program manager here on the Community Relations Team at GitLab. Naritzee has a great breadth of experience in open source, and her talk today is titled Communication Hacks, Strategies for Fostering Collaboration and Dealing with Conflict in Open Source Communities. Naritzee is going to share some great strategies for providing feedback, dealing with conflict, and some overall ways to have more charisma and improve your online communications. I hope you enjoy her presentation. Hi, everybody, and welcome to Communication Hacks, Strategies for Fostering Collaboration and Dealing with Conflict in Open Source. My name is Naritzee Sanchez, and I am a senior open source program manager at GitLab. While I've worn many hacks throughout my tech journey, communication has always been at the center of that, and I'd like to share some of my learnings with you today. We're going to cover some of my favorite hacks, which I think are things that everybody should know about, and we're going to cover navigating cultural differences. I'd like to mention that this is part of a larger talk that I gave earlier this month, and my full-length slides are available at the link below. Those slides include topics like giving and receiving feedback and active listening. So if you're curious about those topics, check that out. And we'll dive right into my favorite hacks, which I hope you'll be able to start using today. The first is that it is the writer's job to be understood, and that formatting really, really helps. When you're writing something, it's important to do a skim test. Look over what you've just written, and make sure that people can easily read through it and understand it. If you have a call to action, make sure it's clear and that you can easily see who needs to do it and by when. You can see that I've tried to do this even in my slide here, where instead of just including bullet points, I've also included a bold section in each so that people can, within a few seconds, understand what each bullet is about and be able to refer back to it as well. Sometimes even with bullets, it can look like a wall of text. So this tip really works. And when you're writing, try to avoid long sentences and don't assume previous knowledge. Make it easy for anyone to jump right into the conversation. This is an example of an issue template that our social media team created at GitLab. Here you see that they've used formatting, like different header sizes and bold. They've created checkboxes and even use their motocons to make it easy for people to understand what to do. And similar to this, I'd like to encourage you to use the issues description to do something similar. Oftentimes with feature requests, especially, these can be open for years at a time. And there are hundreds of comments that has gone on over the course of that time. So when you see something like this, really try to edit the description to make sure that you summarize what the conversation is about. That way, anybody can take a look at that issue and understand the basic idea of what it is and the current status what's happening. And then they can dive into the comments to have a fuller understanding of what's going on. The next tip is yes and. And this is that instead of saying no or yes but, you just switch out the but for an and, you say yes and. And this is incredibly powerful when you're having discussions or have a difference of opinion with somebody. When you use yes and, it acknowledges what people are saying and it still gives you room to disagree with them. So I think that most of us have heard that anything before the but doesn't really matter, that really what we're trying to say is after the but. And what this makes us feel like, if somebody says yes but, it's like, yeah, I sort of listened to you, maybe not, I don't really care what I really care about is this other thing. And it makes you feel unheard or just shut down in some way. When you use yes and, you can say, yes, I've heard what you've said and I still disagree. I think it should be this way. And that one little word has made a psychological difference where now we're more ready to hear what they have to say because we've felt heard. And along those lines, collaborative language really helps. And while I don't have the time to go through this full list, I wanna highlight the first, which is how might we? This is a phrase that I've really tried to incorporate in my own daily usage where instead of saying something like, let's solve this challenge, which yes, it's motivating, yes, we wanna do it. You might wanna say instead, how might we solve this challenge? And just by changing those words, you're inviting people to participate in solving that challenge to give you their ideas and take ownership in solving that challenge. Next up, we have navigating cultural differences because as we continue to expand our communities and work with more contributors from all over the world, we need to understand how to best work together. And I love this book by Erin Meyer. It's called The Culture Map. She's done a lot of research on different cultures and she plots them out along seven indicators. These indicators are communicating, evaluating, leading, trusting, disagreeing, scheduling, and persuading. Again, I don't have time to go into all of them, but I'll highlight a few. The first is communicating. And with this indicator, there are low context cultures and there are high context cultures. Low context culture is value communication that is precise, simple, and clear. Repetition is often used to avoid misunderstandings. On the other hand, high context cultures, value communication that is sophisticated and nuanced and layered. And oftentimes you have to read between the lines. And another indicator is evaluating and this is about how we give and receive negative feedback. Direct negative feedback cultures deliver feedback frankly, bluntly, and honestly. They don't use positive messages to wrap negative ones. Absolutes are used like you always do this or you completely did that. And it's okay to give it in front of groups. On the other hand, indirect negative feedback cultures deliver the feedback softly and subtly and diplomatically. They oftentimes use positive messages to wrap the negative ones. So this might be like the sandwich effects that we have sometimes heard about where you say something positive, then you say the negative feedback and then you end with a positive, a sandwiching the negative with the positive. And in these cultures, feedback must be given privately. And unlike the negative feedback cultures, they oftentimes use qualifying descriptors like you sometimes do this, maybe a little bit. Persuading is another indicator and there are some cultures that are principled first, that really value hearing the why or really explaining the why first. They've been trained to develop the theory or the concept before presenting the facts, statements, or opinions. On the other hand, applications first cultures value the how or the what first and they're trained to begin with a fact, a statement, or opinion, and then back it up as necessary. So these can be like executive summaries or here are our findings and here's how. And Erin Meyer mentions in her book that for example, somebody from France who has a manager from the United States and is constantly asked to do something without really knowing the why can be really frustrated by this dynamic. And so I think it's a really interesting one to think about and for us to use as we evaluate how to interact with people from different cultures. I'd also like to give you a practical example of how this all works. And since I belong to the GNOME community, I thought I'd map out the board of directors for this year. We have a board from the UK, United States, Brazil, Mexico and Nigeria. And here you can see how those different cultures map out using Erin Meyer's indicator. And I'd like to focus on trusting which is the third indicator from the bottom. There are some cultures that value task-based trust building and there are some cultures that value relationship-based trusting. And so what this means is, US and the UK to a lesser degree follow on this task-based trust building. That means that as you work together, as you complete tasks together, that's how you build the trust versus these other ones where you really need to form a relationship. That's going out to get drinks or go to lunch together, really understand their family background, where they're coming from. In a board of directors setting, it's really important to know these so that you can collaborate best. You'll need to find ways of both having the relationship and the trust building equally and in order to then work better together. I have a few more tips for navigating these cultural differences and that's investing time and understanding the people you work with especially those that you work closely with and do not make assumptions even though someone may look like they're from a certain culture or may have been born in a certain country, it doesn't mean that they identify with that culture. For example, somebody may have been born in India but may have grown up part of the time in Japan and really values the Japanese culture has been immersed in that. And so actually identifies more closely with Japanese culture than with Indian culture. Even though cultural differences do exist on a wide scale overall, it's just remember that people are individuals and that you really do need to get to know them before knowing how to best work with them. I also think that it's okay to set expectations around how communities or companies tend to work. So we need to understand the trade-offs and we need to let empathy be our guiding light. And so for example, there could be companies that value low-context communication where everything is precise and concise. And when interviewing people that come from high-context communication cultures, that could automatically count against those people. And when we're trying to build diverse teams and organizations, we need to make sure that we understand that and that we're keeping that in mind as we adapt and move closely together to work. So I think that there needs to be more research in this area and just more knowledge share so that we develop that empathy and can better work together. Let's end with this quote that I love by John Powell that says, communication works for those who work at it. And this is so true. Communication is a skill that you build. And so even if you think that you need work in this or you're not great, don't worry, this is something that you can keep improving. And I hope that today you've learned something and I look forward to hearing about your journey eventually. Keep sharing the knowledge. That's it. Thank you very much. And I hope you enjoy the rest of GitLab Commit.