 Raise your hand in the back if you can hear me, please. Super. Thank you back. All right. Hopefully in the back you can also see this. Who in here sees a bunny rabbit? Okay. All right. Who in here sees a duck? Does anyone see both a duck and a rabbit? Yeah. All right. Cool. So this is an illustration made by a Polish American psychologist named Józef Jastrof and it was published in 1899. And when you look at it, some people perceive a duck. And if you look at it just a little bit differently, if you look at the duck's bill and make that into the ears of a rabbit, you can see a rabbit. This talk is about perspective. Perspective doesn't change your reality, but it changes how you might interact with it. My name is Jennifer, too. I am one of three co-founders of Cohere, where a small software consultancy that specializes in developer education and engineering leadership training. I've been both a software developer and a manager, and now I co-own a small company. And today I want to share with you how I approach navigating, communicating with others. This isn't the only way to do things, but it's hopefully one tool out of many that you can learn to use. Other people need different ways to communicate, and that means it's always good to learn different communication techniques, because more techniques means that you can reach more people successfully and work with more people. In all of the roles I've held, I've had to make requests to my teammates. Sometimes I need to ask them to change or adapt what they're doing. And sometimes that reaction isn't what I expect. Sometimes that reaction, it looks a little bit more like this. Sometimes people have really poor reactions to my suggestions, and they just reject them outright. And it doesn't matter if that other person is your report, if they're your peer, if they're your manager. Whoever they are, unexpected responses can be a frustrating experience on all sides. You're frustrated because what you thought would be the simple request is suddenly hard. You're frustrated because you just gave them a hard request. It's tempting to think about situations like this in terms of failure. It feels like you failed to communicate. It feels like they failed to hear you. And it's easy to think that successful communication looks like getting our ideas across the first time we try, if we can't do that, we fail. That's a message that we get a lot. There's so many classes you can go out and take that will teach you how to craft your message, how to choose the right words so that your communication is clear and unmistakable. That's not really communication. That is being able to give a unilateral command or an edict and know that your intent is clear to the other person. That's not communication. When your message doesn't land the first time, that is not a failure. Is this the beginning of a dialogue? That is where your communication can begin. So was that a duck or was it a bunny rabbit? Is it failure or is it a beginning? All of that is perspective. Perspective can help you with looking at what looks like your personal shortcomings, your personal failure, and seeing it not as that but more as an opportunity to engage with the other person. Perspective can also help you get what you want. It can help you look at why the other person is responding the way they are and understand what it might take to change how they feel, how they think. I'm not up here talking today because I'm awesome at saying the right thing the first time. I'm giving this talk today because I have a lot of experience around needing to navigate beginnings. This talk is going to share one of the ways that I look at that. I only use it when I'm working with people who I think are operating in good faith. If you don't take any of what I say over the next 30 minutes for anyone who you think is operating in bad faith, these techniques won't work so well. So for the teammates who you believe are operating in good faith, when I need to begin a dialogue with them, there are three things, three variables that I think about that describe the other person's inner state. These three variables determine how successful my request might be and how I should approach the problem. They are understanding, agreement, and willingness. If the other person understands my request, that means that my message was received and it didn't get garbled or mangled. We agree on the message content. If the other person agrees with the request content, then they think the request is a good idea. And if the other person is willing to perform the request, they plan to change their behavior to match what they believe that request to be. It's important for me to know the state of these three variables because that gives me this baseline of understanding for where the other person is and what I should do to try to reach them. This is a little abstract, so we're going to go through an example, and then I'll run through variations of what that might look like. And then after all that, we will dig into a little bit more detail on what to do. So here's the first example. Let's include unit tests in every change request. All right? Sounds good. Some time passes, hey, I know that you've been including unit tests in all your change requests. Everything looks good. This is the happy path. The other person understands, agrees, and is willing to take some action, and they go off and do it. I often think about Boolean variable combinations as tables. So here's how I visualized this example interaction of the happy path. Does the other person understand the request? True. I knew that they were looking for unit tests in every change request. Do they agree that the request is a good idea? Seems true. Are they willing? Also seems true. This is a combination that doesn't require this talk, so we're not going to talk about it too much. Things get more interesting when you tweak one of these variables. So we're going to toggle the variable for understands, and we're going to switch it over to false. So we're no longer on the happy path. I'm going to replay that example and toggle it with understanding to be false. Let's include unit tests in every change request. All right? Sounds good. Hey, I noticed you haven't been including unit tests in your change request. Oh, you wanted unit tests in every change request. So this is why it's most important to understand the state of your understanding variable first out of all three of the variables. If you don't have it, you won't be able to go forward. If you have agreement and willingness, those are all meaningless. If the other person was agreeing and was willing to do something different than what you thought you were asking. So let's do one more tweak. We're going to keep understanding false, and now we're going to make agreement and willingness false as well. Let's include unit tests in every change request. What? No way. You were just preaching the gospel of unit tests over lunch today? Oh, you want unit tests in all of your change requests? Yeah, let's do that. If someone isn't thinking about the same thing you are, it's impossible for them to agree with you and your idea because they're not thinking about your idea. Whether they agree or disagree doesn't matter because they're agreeing or disagreeing to something that isn't what you're trying to talk about. If understanding is false, you can think of the other two variables as being undefined behavior. If someone has similar values to you, getting to understanding will probably flip them immediately to agrees and willing. If it doesn't, at least now you're talking about the same thing, and that by itself is valuable, you successfully communicated what you want. You cleared that understanding hurdle. So when you are making a request to someone else, start from whether they understand your request. If you don't have understanding, you don't have anything else. And if you do have understanding, remember, especially if you had to work hard for it, that is an accomplishment. You're not done yet, and at the same time, you did hit a milestone in connecting with another human. You should note that and be proud of yourself for it. Let's look at what happens next after you clear this first hurdle. The second variable you need to identify is willingness. If someone understands your request, are they willing to do it? If someone is willing and agrees, that's the happy path we talked about earlier. Every now and then you get someone who doesn't agree, thinks your request is a bad idea, and is willing to do it anyway. Let's include unit tests in every change request. I think writing unit tests in every single change request will slow me down, but I'm willing to give it a try. When you hear this, it might be tempting to categorize this interaction as happy path, because it seemed like they were willing to go on, they're going to go do the thing. In reality, this is both a warning sign and a gift. The person you're talking with has a lot of trust in you. Kind of like what Jim was saying earlier in the previous talk, this person trusts you enough to override their own judgment, and they trust you enough to share their reservations. Don't take this person for granted. Make sure you're using that trust well. You might also remember in Seron's keynote yesterday how her Code Land conference attendees trusted her enough to give her feedback. This is the same thing. When you get feedback that someone has reservations about your idea, it's the same thing. This is a gift, and it won't be repeated if you don't appreciate it. To express your appreciation, make sure you understand everything that the other person shares with you. It's possible they might see a better solution than what you requested, but they are deferring to your less good idea. They might be doing that because they want to support you, or they might be doing that because they're motivated to act always for the greater group good. Whatever the reason is, don't throw away this gift by ignoring their feelings on the matter. So for the person who's afraid of the unit test slowing them down, check in with them over the next couple of weeks a couple of times. See if they still feel that way. Is there maybe something fundamentally flawed about your code base or the code base that they're working with that makes it impossible or unreasonable to write unit tests all the time? Maybe there is. If you've had that experience where you say to your manager, hey, I've got this problem, and your manager says, yeah, thanks for bringing this to my attention. We need to focus on this other thing instead. And then nothing ever changes. You've had this experience. You've experienced this yourself. You understood your boss had different priorities. You were willing to go along with that, but eventually your disagreement on that prioritization exhausted you. So when you are on the other side of that, when you are the person making the request and you need someone to go along with your idea, try to remember how it looks and feels on the other side. You only need understanding and willingness in order to get your idea to go through. But you need agreement for the other person to continue to want to work with you. If you ignore this variable, you might be ignoring a bigger problem you can't see. And that other person is going to eventually get tired of you not caring about what's important to them. So if you don't see any progress in someone coming to agreement with your original request, start talking and work together to uncover why they're still unhappy. Check in with them regularly to see if their feelings change from disagree to agree. And then be prepared to do some work to get there. Let's take a look at the inverse situation where the other person agrees with you but isn't willing to go along with your idea. Let's include unit tests in every change request. I know unit tests all the time is a good idea and it will make the deploy safer, but I don't really know if we should do this. The person you're making a request to does agree that your idea is a good idea. But they're showing hesitation in being willing to go through with it. When you hear hesitation or concern like this, it's a good idea to ask yourself a few questions. Why is this important? What happens if I don't succeed? How will the other person feel if I do succeed? Why does the other person feel how they do? How will I look back on all of this in a year? Why is stopping and asking these questions important? Is getting your colleague to write unit tests all the time really the most important thing you could be accomplishing right now? Is this what you want to be proud of? What you want to be proud of in a year and five? It's easy to set your sights on a goal like improving your test coverage and then lose sight of everything else but that goal. How do you know if your goal is still the right one? If your colleague is hesitating or showing concern, maybe they know something that you don't know about the development environment or the business priorities. And what you are trying to do is going to be at cross purposes to all of that. You might want to get some more information before continuing to pursue your test coverage goal. And when you do get that new information, you might realize you're not asking for the right thing. Sometimes it can be embarrassing to feel like you're publicly changing your mind and it can feel scary to walk back a request either by explicitly or silently dropping what you had been asking for. You might feel conflicted about not standing up for something that you value. I mean, we care about code quality, right? I want to guarantee to you people are going to respect you much more for doing the right thing than for charging single-mindedly towards your goal without considering if it is the right thing. If it seems like your goal really is the right thing to do, share with the other person why that's important. If you're transparent about your reasons, you're sharing information that might help other people adopt your motivation or maybe it will reveal missing information to the other person that they can point out to you. Whatever the result, sharing your context will make everyone involved better able to make and share informed decisions. You should probably do this not just when you encounter someone who agrees but is unwilling, but share context with any of those previous Boolean combinations that we talked about so far. The only time it might not be a great idea to do that will be for the final Boolean table configuration. Here's the last combination. Let's include unit tests in every change request. Unit tests in every change request, that is a terrible idea and we shouldn't do it. So the person you're talking with understands what you want and they are unwilling and disagree with your request. Before we dive into what to do, let's do a very quick review of the whole table. If you are looking at your request through the lens of these three variables, you'll want to take different steps forward depending on the state of those variables. If you have understanding, agreement, and willingness, you can go forward. If you don't have understanding, clear up that misunderstanding first. If someone hesitates or disagrees, you might not have agreement or willingness or either. If the other person is willing to go forward, do that but be careful not to burn them out. Make sure that what you're doing is worth it and be willing to change your mind and drop your request. If the other person is unwilling to go forward and you still want to go forward, your best path to that is to stop, drop, and listen. That means you stop pursuing your goal, you drop the topic, and you listen to the other person. Now, stopping and dropping the topic might seem like the opposite of getting to your goal. So I'm going to go in a little bit deeper on how this will actually help you. So let's do the mechanics. Stop, drop, and listen means you explicitly call for a timeout and agree on a time to return to the conversation. That might be immediately, it might be the next day, it might be some unspecified time in the future. The important thing is that you're communicating a desire to reset the conversation and start when you are both ready. This is important because some people need time to react to new information. When someone is busy reacting, they're not really talking with you anymore. They're in this reactive mode and they're interacting with their feelings and reactions to the new information you're giving them. And you might be in front of them and it might seem like you're talking with them, but you might not actually be a part of that conversation they're having with their feelings. So when you stop and give people time to finish having that big set of feelings, you're giving them time to be able to come back ready to engage with you. There's two reasons why someone might be in this reactive mode. One reason is they might have some past experience that's influencing the present. And the other reason is there's some external factors currently in the present that are influencing how they relate to your request. So sometimes when we hear something, it might remind us of random past experiences. And if they were particularly impactful experiences, it might get us thinking about the past instead of the present. And when someone is in that kind of space, the only thing they need from you is time to process those strong feelings and re-anchor themselves into the present. This might be after lunch, after sleeping on it, after many nights of sleeping on it, right now, never. Whatever it is, give them that time and space. You might be wondering how to know how much space and time to give. There's kind of an art to it, but here's a very rough guide for how to get started. If the other person isn't too upset, you can agree on a rough time together. You might say tomorrow, next week, after lunch. But if they're feeling really, really awful, just proposing talking again sometime in the nebulous future, that might make them feel even worse. So in that case, you're going to need to know what you know about them to figure out the best time to bring the topic back up. That means pay attention during your regular conversations and look for signs that they are exiting that reactive mode. Then ask if it's okay to bring the topic back up sometime. If the answer is no, leave it alone. If the answer is maybe, maybe later, maybe never. By giving them time, you're giving the other person the chance to work through that internal conversation before picking up the conversation with you again. It's giving them a chance to feel, oh, I'm thinking about that awful tech lead again. This is a different situation. It's giving them the chance to give your idea a fair hearing. This also works if the feelings aren't coming from the past, but from the present. Maybe there's stuff going on in their personal life. Some of us might want to think that home life and work life are separate, but everything does bleed through a little bit. And if someone is having a tough time in their personal life, they might not be able to make changes or make space for change in other areas of their life, including the office. This is one reason why water cooler time is really important. If you want to influence what other people do, stay in touch with them with regular conversation. That is how you're going to learn what they find important, and that is how you learn whether it's a good time to ask for a change, or if the other person is less open to change than usual. And it might not be their personal life. Maybe their work environment is making it really hard for them to get any work done right now, and they can't see how they could do even more work, like adding your unit tests, given all of that. If you can uncover anything you can do to help them with their situation, do that. Whether you are in a leader or a peer relationship with the other person, find ways to pull the pressure off. The more power you have, the more you'll be able to do. But even if you don't feel like you have any power, do your best to get creative and find ways to pull some of that pressure off of your colleague. If you're asking someone to make a change, be ready to help them make that an easier change. If you remember that phrase about refactoring, it applies both in code and in real life. When someone is being overwhelmed by external factors, it can be hard for them to accept or initiate a change to do that delicate balancing act that they have going. Be aware that what you're asking for might seem like a small request, but to them, they've got a bunch of balls in the air and you're asking them to just pick up one more thing. It might seem small to you and it might be too much for them. So make the change easier for them. You can wait until those external pressures ease up so that the change is easier, or you can jump in and take away some of those pressures so the change can be easier. One thing you might have noticed is that whether someone is reacting to external factors or someone is reacting to their own ideas about the past, it kind of all looks the same. It looks like the other person is being obstructive and difficult. That's all perspective. If you look at it a different way, you can see that your teammate is under pressure doing the best they can with what they have. So help them out. Respond in a way that lets them be able to process their feelings on their situation and come out with their dignity intact. You don't need to know what they are thinking about or what that past trauma is to do this. Give them a little space and that's sometimes all they need. And you can do that by reminding yourself to stop, drop, and listen. Call an explicit pause, acknowledge this is a bigger request than you realized, and be prepared to listen. There's a few things you can do to be a better listener. If someone doesn't want to talk, don't push it. Allow them the agency to decide if they participate in more discussion. And if someone does want to talk, your job is to listen very closely to what the other person is communicating, which is not necessarily what they are saying. Listen for whether they sound like they're open to being persuaded. Listen for do they want to be persuaded? Could they be persuaded? Think about all of these different questions. They sound very similar, but if you ask all of them, it gives you a more complete picture of what the other person is thinking. As the conversation progresses, get consent actively. That means you pay attention to the other person, and if it looks like they're getting kind of uncomfortable with talking about whatever it is, check in with them. You might say, I know this isn't an easy topic to talk about. Do you want to keep talking about it? And sometimes it can help to give options. Maybe you suggest we could go out to lunch a little early instead. Continue to give the other person more agency in deciding to continue to participate in that conversation. And finally, signal that you care. You know what's worse than the feeling that you're being manipulated into a plan? It's the feeling that you are being manipulated into a plan while you are in a vulnerable state. People can tell when they are being manipulated, even if they're too tired to call you out on it. So don't do it. When you drop your topic and focus the conversation on the other person's problems, that shows that you care more about them and their feelings than about your goal of getting unit tests everywhere. Don't screw it up by then returning to your request. Keep it focused on the other person and let them drive the conversation back to the original topic when they're ready. Not returning to your topic might feel like you're running away, abandoning your principles. But not listening to your colleague, that's running away from their concerns and abandoning your teammate, your teamwork. What if you want unit tests and the other person is just exhausted, they just wanna ship it and never touch that code again and it really is low churn, you're never gonna see it again. Do you need to win this? Can you let it go? What's the worst thing that could happen? This is the question you need to ask first before you decide to make that request to the other human. If the answer is yes, yes you should make your request, here's a quick recap of what we talked about today. First, make sure we're on the same page. If you don't have a shared understanding, everything else is undefined behavior, meaningless. If someone understands and is willing to do it but they don't feel too good about it, don't let them sit on that disagreement for too long. They will burn out and they won't want to work with you anymore. Check in if they have more information or context that you don't have, be willing to reverse course and then figure out if the other person is willing to make your change. If not, you can stop, drop and listen, which means maybe you come back to the topic and maybe you don't. This stuff is hard to learn and you will definitely make a lot of mistakes along the way. That's part of learning, it doesn't feel good and you'll be okay, keep trying. There's not really any good way forward other than making a bunch of mistakes. Stay honest and brave enough to admit when you mess up and use techniques like this one so that way you can learn to get to where you want to be faster. If you have more questions after today, you can reach me on Twitter as at JTU or email JTU at wecohear.com. Slides are at wecohear.com slash humans and we do integrate the harder topics like today's into all of our technical workshops and coaching services, including our pairing and mobbing services. So come talk with me more about this. I like learning about how other people think about how to communicate, how to get your ideas across. So please come talk with me after. Thank you very much for coming to this talk and I want to give a really big thank you to all of the RubyConf staff and volunteers. If you haven't yet today, find someone in a purple shirt. They're maybe an organizer, maybe a volunteer, whoever they are, thank them for making the last two and a half days the next half day possible. And thank you to the live captioner, AV staff and recording staff in the back. Thank you everyone.