 Okay, thanks. Yep. Yep. Yeah, it's been on. Yeah, Leslie did have that last time. Okay, so yeah, thanks for everyone for sticking around. So so Laurie and I, this is a talk that we initially thought of when we were together at Prague at the LinuxCon there about how a lot of the things that we've seen in our careers is really about collaboration and open source is obviously all about that. But we think it also provides a lot of business value. So we've got some examples from our business lives. Okay, so we'll introduce ourselves, Laurie. Hi, so yeah, I'm Laurie Apple. I'm a cartoon character and a senior program manager at Workday, which is HR financial management software company based in California, but with offices worldwide. I'm in the Dublin, Ireland office. My colleague Ali is in the back row. Hello. Thanks for joining. And I'm not really doing open source work these days anymore. But my, the teams that I work on are using Kubernetes Helm and a variety of other open source software programs. So so yeah. Okay, I'm Eric Redell. I was most recently spent nine years at Dell EMC building large scale storage clouds. I've been involved in open source probably 20 years, 25 years as an engineer, 15 years as an engineering leader and director. So I've built teams building open source. I've done open source projects across the industry. Before open source, we used to call them standards projects in the hardware space. But it's very similar in collaboration. So a lot of experience with with teams and collaboration. So we're going to try to share some of those with you today. So on our menu for today is communicating in technology. And of course, an open source, which provides unique opportunities to communicate in different ways than you might in your day to day work. Communication magic. Eric will go into what that's all about. Empathy is skill as a skill. That's me shared goals. I think that's both of us and inclusion and collaboration across cultures, which you might have to speed through as we wind down. But hopefully we will get to the exercise included there and then Q&A at the end. So communication is an art form. And to practice an art form successfully usually requires a bit of discipline. And so this slide is inspired by the work of Eric Fra, whose art of love was quite influential in psychoanalysis circles and psychology. That happens to be a hobby in an interest of mine, psychology, brains, neuroscience. So I saw it was at the end of the book. And I thought, well, golly, that's pretty applicable to how we talk to each other in software development. And when we're disciplined, things tend to go pretty well. And I'm not talking about rigid rules, but an expression of one's will, something that we develop organically over time, a disciplined approach to communication, communicating effectively, communicating clearly, and communicating in a friendly, warm, inviting, collaborative way. Concentration helps us to develop this discipline by becoming better and better over time through different exercises, exposing ourselves to different experiences, doing mentoring or asking for mentoring and how to be a better communicator. And it really is about introspection and listening to others, gathering feedback on how we communicate so that we can continue to do so more and more effectively. And then patience because this is a discipline or an art form that's going to take a lot of time. We all build habits over time and some of those are bad habits and it takes a while to break them. It also takes time to shift our bad habits into better habits. So these three elements which Eric Fromm had identified is essential to the art of loving people successfully in a very organic, natural, not rigid, not forceful, not controlling way. And also being able to really connect with other people that we're trying to love really, for me, because I'm, seemed perfect for this, for our world. A lot of times we think we are doing discipline, concentration and patience. We go to work, we show up on time, we go to the meetings, we work on our teams, but just doing those things on their own doesn't necessarily mean that we're living the spirit of discipline, concentration and patience if we're kind of on autopilot or we're not really contributing proactively to those activities of, you know, meetings, like do we enable or empower others during those meetings? When we're working on our teams, are we actually talking to our team members? Are we just sort of hoping that they understand this and letting it go? Hierarchies, which are pretty common in old school companies, don't make us collaborative either, even though they kind of assert that they are creating structure for all of us to collaborate, but it's really quite automatic in many cases. And if there are toxic hierarchies, then people are going to rebel, which is obviously not discipline at all. Okay, so if, what we listed out here is some common problems in tech projects, right? We've got missed deadlines, probably no one in this room, you're all well organized and never missed your deadlines, but it happens out in the tech world, right? There's complaints about low productivity, maybe somehow tied to the time, but if we only had more time or more people as comes lower down, maybe there's poor quality, right? And then people issues, often there's high turnover and everyone complains about the difficulty of recruiting, finding, you know, quote unquote good people, right? And I think many of us, there's certainly many of the industry that I regularly interact with just feel like it's always like this, right? That this is just the way that technology is, that it's always things are always going to be late, things you're always going to have to make compromises, etc. It's just the cost of doing tech business, right? And so the question is, does it have to be that way? Of course, everything on the previous slide is true. Projects do get slow, inefficient, they're unpopular to work with, they're not pleasant to work with on. But if we just give in to the lowest common denominator, we're never going to get better. We're never going to really maximize our potential. And collaboration can be the way out of that sad state of affairs. So let's talk about talking. In open source, these are some of the key ways that we talk to each other, GitHub issues, the pull request and code itself, Slack, meetings, meetups, Zoom calls, Google Docs, social media, one-on-ones, conferences. Think about which channels are most challenging to you. And also think about which channels you use most frequently and which ones seem to pay off, rape the most benefits for you. Maybe in technology, the assumption is a lot of us are not extroverts. So we don't really want to go out in front of a lot of people or we're not getting our energy out of these big, cloudy, social interactions that might require a lot of conversation. So maybe we do all of our communication online. But how do we do that communicating? Is it clear, effective, structured? Do we think about how the reader is going to be able to intercept information, really understand our point of view, and also not be hurt or offended by it, because it's rude or insensitive in some way. How, if you are struggle with communicating or you're just kind of new to the scene and entering a project for the first time or community and you really want to do well at collaborating and communicating, it's a priority for you. You can learn a lot from the land of therapy and psychology. So this slide lists 10 principles for what's called intentional relationship design, which is a popular concept in therapy relationships. So when a client goes to see a therapist for the first time, the therapist can't just be their friend. It can't just, you know, it can't be like going to meet your friends for coffee and telling them about your day. There has to be a boundary set to make the relationship effective. And, you know, that boundary can be easily smashed if the therapist isn't deliberate and vigilant about maintaining it. And so they also don't want to necessarily lead the client on to the conclusions. They have to be able to allow the client to arrive at conclusions themselves. And so these 10 principles were developed to help therapists manage that relationship successfully. So I'm not going to read them all out because they're right here for you, but being self aware, learning, which you know, we call growth mindset in the tech world, focusing on activities instead of like ideas or plans, but like actually doing things. So having results orientation, cultural competencies so that one can communicate and collaborate with as many people as possible, and mindful empathy, which, you know, will help retain. If you're running a project, if you're empathetic to the contributors and users, you'll retain them over time because they can, you're engaging with them. So why would one want to be intentional? Well, I think I've hinted at it already in the previous slide, but in open source software reasons would be to reduce or eliminate conflicts or drama, which are negative and toxic forms of communication collaboration, you know, collaborate on a big Twitter mess, you know, something goes wrong in community can all this point on Twitter at the outrage that ensues. Not a great use of time that happens quite often. That's waste and delays of energy, goodwill, contributors, time, effort. If you're intentional, you can avoid those by setting your boundaries early and often in the expectations for how everybody can work together. Confusion, again, setting boundaries can clear that up. Here's what we all expect from each other. Now let us go forth and collaborate. Misalignment, common in projects. Again, being intentional helps people to align. So and check in frequently to make sure they remain aligned, instead of just kind of going off on tangents. It protects collaboration builds trust, which is essential to any collaboration being successful, reduces cognitive load by replacing all that drama and awfulness with focus and sharing of cell and celebrating of work done. And it drives experimentation because instead of arguing and fighting, you're thinking about how to collaborate and brainstorm together and you actually had the time to do it. When we're not being intentional, we do all those terrible Twitter outragey conflict things. We make assumptions and jump to conclusions based on emotions. So that prevents collaboration because we're coming at a situation from a place of fear or anger. We don't ask for what we need because we don't think we can get it. We just give in. It's just opposite of being aggressive. It's being passive. We become frustrated and ruminate again being passive. This means we lose opportunities, because we don't ask for what we want or figure out how we can get it. And then we rely on my handwriting powers that we don't have. So we don't open up a conversation. We just assume that we know what the other person's thinking and give up. So we don't want to try these exercises here because there's not really time. But if you actually want to practice some communication skills, here are a couple of examples of ways you can do that. And you can actually apply these in your open source collaboration efforts. So a lot of times people will fire off an email or comment on GitHub and maybe they regret it because it's like very hasty and blunt and even maybe rude or we'll just shut someone down. So to avoid that, create scripts or templates in advance to help set up an empathetic response. So here's an example that we give you. Thank you for trying to understand my point. However, I think where we're still misaligned is blank. You know, what do you think? And then that's inviting somebody to communicate with you and it's a lot better than like, no, you're wrong. Goodbye. Another example would be, thank you for your enthusiasm. I've noted your concerns and believe we might handle this concern or situation by and then you make your proposal. And again, that's a lot better than saying like, that's a stupid idea. We don't have time. It's not important, you know, getting rude and hasty. And that's the magic that you can add to your project and your interactions and getting further into magic. Now is Eric. Oh, right. Yes, I just want to give you a microphone. I'm good for to communicate better, right? Yeah, so there's a so that those the types of things that that that Laurie talked about there are sort of guideposts in communications, right? And so so I want to kind of change a slightly different story from from my recent experience on my most recent project. So so as an engineering project, large corporation, like I said, we're building big cloud storage systems at the height. This was a 250 person development team spread around the world, you know, only maybe a dozen people in any geography altogether. So there was there was a lot going on right a lot of a lot of communication. And and one of the explicit decisions that we made in the leadership team at the beginning is that that we were going to over communicate in this in this project. So there was a lot of communication. And and what we we took away from that was that there was a lot of benefits, right? A lot of secondary benefits that maybe we hadn't quite intended, right? So we so what we did the way we initially implemented this starting maybe five five years ago is we did these massive mailing lists. So so there was, you know, at the beginning, maybe there was only 30 of us. But even as we grew to 250 people, when a new person joined the group, they were added to an alias that was a list of all the engineers on the team. And there was also an alias for escalations if there was a problem with a customer that was a link to the list of all the engineers on the team. And there was an alias for new design ideas if someone wanted to propose some new aspect of the system. And it was a link to the same distribution list of all the engineers. So you can imagine, you know, people had all kinds of filters for their email. A new employee was warned that, you know, within two days of joining the group, they'd be added to these email lists, and they'd be getting, you know, up to maybe 100 messages a day. But what it embodied more than just sending out lots of emails was that the information was available for people. And that was used in actually a lot of ways. For example, like the archival history meant that folks that were coming to a problem fresh that maybe they hadn't paid attention to, they actually, so most, the way this happened most often was an escalation. So some customer would be angry about something, and chances are that they'd actually been angry for some amount of time, and there'd already been some engineers working on it before it hit, you know, your particular component. My team was responsible for the hardware, for example. There'd usually be a bunch of debugging and diagnosis and other things would go wrong before someone would decide that it was the hardware's fault, right? But we had, in our inboxes, whenever something like that would occur, we would have a long archive that we could go back to even if it first happened a month ago with this particular customer, as long as we had the right keywords, the information was right there. And the same thing with design discussions, right? So like I said, we had, you know, an alias, the design discussions that went to everybody and people got used to kind of ignoring, hey, this is really not my part of the system, et cetera, but you had that archive, right? In addition, there were often folks that were in remote geographies or maybe they were, you know, new to the team and were acting a little bit more in a support role. The QE team was also included in this, as part of the engineering team. And so there was a lot of people that had small, that were able to pick up small bits of information because we were spreading it very widely. Whereas if we had just centralized the information or tried to work out different streams of who needs what information, which all of us had experienced in previous projects, we would always miss somebody, right? So that was a great way to do shared state. And sort of luckily for our email inboxes, about two years into the project, we started using Slack. So we were also able to introduce with Slack and the combination of the emails a way to have more real-time responses so people didn't have to constantly monitor their email. But the important point that I wanted to, you know, that I would take away from this is that we massively increased the amount of information that flowed through the organization. And then we went back and occasionally thought about, you know, how to optimize those flows. But the baseline was that we sent probably an order of magnitude 10x as much information into the organization as any of us had experienced on past projects. And it was better rather that the upsides far outweighed the downsides of, you know, the scary new person who's like, oh my gosh, I'll never be able to recover again from all the emails. So there's an example. Okay, next part. So thinking about that person and recovering from the email shows empathy. So let's talk a little bit about empathy and how it's a skill. And this isn't an idea that we came up with. It's kind of floating around the internet. Andrea Goulet, who's the CEO of Corgi Bytes in I think Virginia. She's on Twitter. I think she's writing a book about legacy code and empathy involved in managing her legacy code. She kind of propagated this idea a couple years ago. And it's a good one. So just so we know what empathy is. Here's the old online dictionary definition. It's a psychological identification with or vicarious experiencing of the feelings, thoughts or attitudes of another. The second one isn't so pertinent to our purposes here. But it's really emphasized what this word is about. It's really trying to identify with somebody. It's different from sympathy where you actually feel sorry for someone, which could even be like a power dynamic, you know, I feel so sorry for you all. But empathy is like, I understand you, I get to. I'm going to do things so that you feel like a real person that matters, because this is how I know that, you know, how to make that possible for you. By building a great software project that's not hard for you to use, but has a great user interface, has good documentation. I'm going to be nice to you so that you have a good experience in that way. If you're a contributor or user, you're going to feel comfortable coming back to me in my community. So this is how you empathize. One good thing to do every once in a while is do an empathy audit of ourselves. And why would we do this? Well, just to make sure where as empathetic as possible. This is, again, a discipline like communicating that one can develop over time and constantly get better at. And there's lots of benefits of doing so. You know, we all tend to like friendly or empathetic people, because they make us feel good. So on a scale of one to five from low to high, how would you rate your own empathy? You know, that might be hard, because you're like, well, I don't know. I don't know how to do that. But go to the internet and find examples of read about empathy and how to be empathetic and then get, you know, figure out your own metric. When you aren't communicating empathetically enough, what does that feel like in your body and mind? Usually when we're not communicating effectively or nicely, we'll feel it. You know, feel a little twinge of guilt. So, you know, what is that? Reckon with that feeling. Reckon with the thought of that. Oh, I should have done better. You know, like sit with that and think about, well, how could you do better next time? When you're communicating empathetically, how does that feel? You know, we might feel very good about that experience and it's good to sit with that feeling too. And then, finally, do you reflect on your communication to improve your collaboration? Do you regularly think about how you communicate and ask people for feedback and see how you can do better? Some exercises to reinforce your empathy journey is that when you're frustrated with somebody or something, just stop. But what if you're so busy, you can't stop. So, like, I've heard this before in certain open-source communities. Well, you know, we're just so busy, merging all this pull requests and reviewing all this code. You just can't stop. You can't stop. We're like robots. But you know, what if you're, you know, that's kind of a perception that we develop in ourselves. You can stop, even if it's for a few moments, before you say or do something that you might regret. Like, you're rude to someone. So, you know, pause. It's the easiest way to avoid a lot of trouble. Just pause. If somebody really makes you angry, just get up, walk away, come back. And then respond, you know, in a different way than you might if you're like filled with energy and venom. And if this is a real problem for you, like, if you are kind of wired to be, like, going after folks on a regular basis or you have anger management problems, journal, talk to a peer, go seek help. It will make you happier in the long run, because it really doesn't feel good if we're always just going off on people. We're going to help you get started now. We're going to throw in a minute of meditation for you. So, if we can set the clock, I guess we have it right here. So, just see what happens when, you know, maybe some of you are already a meditator. Who actually does meditate on a regular basis. Okay, a couple people. Yeah, it's gotten popular. So, if you haven't done it before, here's your chance. So, count your breaths. As you inhale, we're starting the minute here. So, as you inhale, just silently think one. So, breathe in, one, and then exhale, two, and then inhale, three, exhale, four. Inhale, five, exhale, six, inhale, seven, exhale, eight. Inhale, nine, exhale, ten. Inhale, one, exhale, two. Inhale, three, exhale, four. All right, so that's a minute. You can do this three times. You can do this 100 times at home. There's other ways to meditate. You know, stare at your feet. Think about your feet. Think of your thoughts as little pieces of ice floating down a river. You know, there's always you can do this. But the idea is that you could just kind of think about your thoughts and detach from like all of the craziness that goes on in all of our brains. You know, we're constantly thinking about things, usually in a very rapid fashion. And if we don't take a step back sometimes and we just allow this to happen, we can get very stressed out very quickly and also not become in touch with the effects of all of these racing thoughts on our mood. So I think we only have two minutes, two minutes left. Oh really? Oh well, okay. So I guess we'll hurry up. So a couple of ways to empathize with people in addition to becoming a Zen master and chilling out and being mindful or setting up a personal readme. We all know what readme's are so just make one for yourself. How do you operate? What are your pet peeves? What will make you ragey and stressful or annoyed? How would you like to be communicated with so that you don't have a negative mood response? These are some of the things you can do. Yeah, I still don't need that. So then there's another section here in the slides that you can look off offline about building shared goals among a team with brainstorming techniques, other kinds of techniques to get the team communicating together. Obviously that's, you've seen now a big theme in my experience is getting people working together, brainstorming ideas, deciding goals together, rather than working off of lists or some kind of top-down. It's a great way to operate within a team. Actually a lot of, a lot more details. A lot of details there in ways that you can focus. Like I say in a future talk we can get you updated on that. And then the last part we wanted to talk a little bit about is inclusion and having that perspective. I don't, do we want to try to do another exercise or? We can tell them we're in a hallway. Yeah, okay. So why don't you, so why don't we leave you this as a homework exercise afterwards and then we can take a couple questions. So the way that we set this up was, you know, think about some of the things that make you more aware of how you're responding, you know, why you might have difficulties with a certain communication, other communications, etc. There's a lot of background to that. And the exercise that we did when we did this in Edinburgh would to ask people to talk with the person next to them and talk about two cultural things that may not be obvious from just physically looking. And we're not going to ask you to do it here because in Edinburgh we lost control of the room. When we asked people to talk to each other, we were really afraid that no one was going to talk to each other and everyone was just going to stare and we were going to be stuck and ultimately everyone just kept chatting and we were like wait, we're still here, we have two microphones. So we'll leave you this as an exercise after the fact, but this is is super powerful even in a work setting, you know, not sharing everything about yourself, etc., but having a way to connect at, you know, at a cultural slash human level. Yeah, you might find your next collaborator here, if you're an event tonight and you say like oh, what are two things about you I would never expect. Oh, here are two things about me, and then you can start a conversation as our group, our audience did in Edinburgh, like that you might not want to stop, but we won't be there to tell you to stop. Right, or you could do it after after Leslie does the housekeeping, lets everyone go. So we can, I guess we could take some questions, I guess we have both microphones, so we, our own.