Think about any relationship you've had, specifically a professional relationship. These relationships have either explicit or implicit agreements. In today's episode we're talking about explanations if breaking expectations.
Imagine you're running a team. As a manager, you're setting up the processes and expectations among your team. What are the organizational responsibility, ceremonies and disciplines?
In today's episode, we're talking about setting expectations and specifically how we can plan better for when disagreement happens.
Local by Flywheel is the #1 local WordPress development tool designed to make building, testing, and launching WordPress sites a total breeze!
It’s time to revolutionize your workflow and download Local by Flywheel for free today on Mac, Windows, or Linux at localbyflywheel.com!
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Think about any serious relationship that you've had. And specifically if you've ever started a company or maybe you've had some kind of professional relationship, something that has documentation, prove that it exists, that's the kind of relationship that we're talking about here. But really, every professional relationship has some kind of agreement, whether it's explicit or implicit. For example, as a friend I might implicitly agree to act in your best interest when possible. But it's probably not in our agreement that I'm going to give you part of my income on a regular basis per se. And of course, in more formalized agreements, these kinds of expectations are laid out more explicitly in some kind of contract documentation. And most agreements, most serious agreements, especially those explicit ones, they have some explanation of what to do if things go horribly wrong. Most every serious agreement has some kind of explanation of what happens if we breach our contract, if we break expectations from each other. How do we dissolve this agreement? But what most contracts don't necessarily cover is what happens when things are not going drastically wrong. They're not blowing up in our face, but they're also not going right either. In today's episode, we're going to talk about how you can plan better for disagreement. My name is Jonathan Cutrell. You're listening to Developer Tea and my goal in this show is to help driven developers like you find clarity, perspective, and purpose in your careers. And imagine you are running a team. Imagine that as a manager, you are setting up the processes, the expectations. You could even say you're setting up the team agreement. Here is how we're going to work. Here are the ways that we're going to work together. Here are the ceremonies that we will perform as a team. And here are the kind of organizational responsibilities that each of us has. Most of the time, these kinds of things are laid out, partially, explicitly, partially implicitly. So you might have something like an org chart that shows explicitly how the different people interact with the other people on the team, but then you might have implicit dynamics on your team that can't be explained by the org chart. And so if you're running this team, you know that these plans are important. This agreement is important to set expectations. But what we often don't do when we're setting up a team or when we're running a company or when we have some kind of relationship between one professional and another, we don't plan for disagreement. In fact, most of the time when we disagree, we fall back to kind of our normal social ways of disagreeing, the kind of cultural norms. Those are the things that end up guiding our disagreements. And this is in stark contrast to the way that we run everything else on our team. We have very explicit values. We have explicit ways of performing work, of managing work, of defining our acceptance criteria, but we don't get explicit with our disagreement structures. Why is this so important? And why are we talking about disagreeing so much? Hopefully you're not disagreeing all the time, but you certainly will disagree, even on teams that are culturally highly gelled together. You're still going to have strong disagreements, strong opinions, situations where people quite simply don't see eye to eye. And these are critical moments for your team. These are absolutely critical moments for the team because when you don't see eye to eye, that means that there's something to figure out. There's something to learn. When there's multiple opinions about a given subject, that very often means that there is an opportunity present in resolving those opinions. But instead of creating these structures for smart disagreement, we end up falling back to things like power structures, where the person that has the highest position on the org chart ends up winning the conversation, or we might fall back to an endurance test, whoever's willing to hold out on their particular point, the longest, ends up winning the disagreement. So how do we fix the way that we disagree, or at least how do we start to prepare better for inevitable disagreement on our teams, particularly the important disagreements? We're going to take a break and talk about today's sponsor, Flywheel, and then we're going to come back and talk about three guidelines for having intentional disagreement strategies. But first, let's talk about Flywheel. Flywheel has created an incredible tool for WordPress developers. And based on sheer statistics, so many of you who are listening to this podcast, you already use WordPress. If you haven't checked out local by Flywheel, it's a simple, free and beautifully designed local development application that's optimized for WordPress developers. It's used in a door by over 200,000 web developers already. And it's also used by designers. It's because it's so easy to use. You can easily spin up a local WordPress site. People use it because it's completely free, first of all. It's certainly the most friendly developer-friendly local environment that I've ever used. It has local SSL support. You can do a single click for WordPress installations. It gets shareable demo URLs. You can access H into your local WordPress machines. You can use WPCLI. This is a modern tool. It's not just getting these things to work locally with the simplest possible thing. Turns out that you can have both of these things. So go and check it out. Head over to localbyflywheel.com. And once again, this is totally free. It's available for Mac, Windows, or Linux. It's local byflywheel.com. Thanks again to Flywheel for sponsoring today's episode of Developer Tea. So how can we disagree better? How can we disagree better? Well, the first thing, and this shouldn't come as a surprise, but it's to understand thoroughly what we're actually disagreeing about. Many disagreements are not actually about the thing that we think they're about initially. For example, it's easy for me as a developer to disagree with another developer on how to accomplish something. And that discussion can easily turn into an ego discussion. A discussion about my taste somehow being better than your taste. We can have equally good approaches to a problem or close to equal. It's hard to measure exactly which one is perfectly better, but we both hold positions as if ours is significantly better. So it's important for us as we engage in a disagreement to ask ourselves what our core motivations are with the resolution. How will we feel, this is a good way to get at that motivation? How will we feel if our way or our opinion is not chosen? And then how will we feel if our opinion is chosen? Those are two very important questions to ask, but additionally, what is the point of choosing my opinion or my way or a given way over another? Sometimes our arguments are not necessarily about ego, but rather one person is advocating for one value and another person is advocating for a different value. And so we're not really arguing about the same things. We're arguing about which value comes before the other. For example, one person may be arguing for speed and another person may be arguing for quality. And those things are not necessarily at odds with each other. They just require some kind of resolution. What's interesting here is that we can often reframe the fundamental question of the argument. When we ask what our core motivations are, we can reframe the question in this example of speed versus quality, rather than saying which way is best, we can say which thing is more important. This no longer becomes about which of us has a better approach, right? For which person has the upper hand when it comes to judgment calls or talent? So that's a guideline number one. To take a step back, understand the motivations of the resolution, right? This is just understanding really what are we arguing about? What exactly are we disagreeing about? The second guideline is to focus now on the question of what is keeping us from being on the same side? What is preventing me and my opponent in this given disagreement, a person who has a differing opinion than I do, what is keeping us from being on the same side? Now, notice that I'm not saying what is keeping us from agreeing with one another. We can have disagreements and still be on the same side. When we get on the same side, what we're doing is looking at a problem together. And, understanding the merits of two different approaches and instead of trying to pull someone over to my approach or them trying to pull me over to their approach, what we're doing is we're looking at how can we resolve our two approaches? When we're on the same side, the kinds of things that happen are fundamentally different than when we are on opposing sides. When we're on the same side, we're both open to learning. When we're on the same side, we often are mixing our approaches. When we're on opposite sides, we're not trying to learn, but rather we're trying to prove. When we're on opposite sides, we aren't mixing, but rather we are banning or we're pushing away the other person's approach. When the answer to what is holding us back from being on each other's side has something to do with fear, we're afraid that if we let our guard down and we start mixing approaches that either something is going to fail and we're going to be blamed for it or we're going to be seen as less than authoritative or less than capable. These are the kinds of fears and there's plenty more fears. But these are the kinds of fears that you might experience in a disagreement. The third guideline to disagreeing well is to make sure that you are disagreeing about things that matter the most. Oftentimes disagreements can happen in areas where realistically we don't care that much. We don't actually have a lot writing on this decision and so it makes sense to have some shortcuts and heuristics to allow our disagreements to be reduced. Don't think about this as squelching your disagreements, but instead as making space for the disagreements that matter the most. Having a heuristic or some kind of device to help you short circuit disagreements that turn out to not matter very much is useful. So for example, imagine that you start every disagreement or discussion about a disagreement or maybe you realize that it's devolving into a disagreement. You stop for a moment and you say, okay, let's both on a scale from one to seven, determine how much we care about this. If both of you care about it about the same amount and if that amount is, let's say, five or maybe six, then perhaps this disagreement is worth hashing out. If both of you care about it totally different amounts, someone cares a lot about it and the other one cares less about it, then you might bias your disagreement to care more or defer more to the person who cares more about the subject than the one who cares less. Similarly, if you both care very little about the subject or about the disagreement, then maybe the disagreement is not worth having. Maybe the best answer is to flip a coin and go with whatever the coin tells you to go with. There are other ways to short circuit disagreements that matter less. For example, imagining how long will this disagreement matter for? Are we talking about something that will resolve itself in just a few days and the cost of going with one direction over another direction is relatively minimal? Or is it something that's going to impact the future of our company or our working relationship, our product, our customers? Is it something that has a larger impact? These are the kinds of questions to decide whether you're going to have this disagreement at all, but also to give you an idea of what the disagreement is worth to you, both as an individual and as a team. Overall, if you haven't given thought to how you disagree, what are the ways that you can have valid disagreements and come out on the other side better? This is an area where your time spent is likely to be an investment. It's likely to come back with a positive return. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Flywheel for sponsoring today's episode to try local, head over to localbyflywheel.com. Once again, that's on every platform that you are using Mac, Linux, and Windows. Thank you so much for listening to today's episode. If you enjoyed this episode, I'd love for you to do two things here at the end of 2019, going into 2020, if you want to share this episode with someone who you think will benefit from it. Sharing this podcast is the best way to help us grow and therefore continue doing what we do here. Secondly, if you haven't yet subscribed, go ahead and subscribe in one of the podcasting app you're currently using. This is the best way to make sure you don't miss out on future episodes like this one. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.