Hey everyone, you're listening to Developer Tea. My name is Jonathan Cutrell. We have all been in this situation before, probably if you've been working as a software engineer, you've faced this situation before, where you have a feature and you're trying to develop this feature and there's a deadline approaching. You know that you can't get this feature done by the deadline, but the client, the stakeholder, the product owner, the manager, whoever it is, still wants the feature done by the deadline. This is probably an all-too-common scenario and the same problem underlying this scenario underlies most negotiations scenarios as well. The problem, as it turns out, is similar in its fundamental structure to many other problems that we have. That is, it needs to be broken down. We should inspect this problem more closely. For example, what does the client actually want? What is the product owner, the manager? What are they really actually trying to get from this particular delivery? How does the date matter? And more specifically, is there something that they want that can't really be expressed by just the date and the feature? One of the most common anecdotes that we hear about in this particular kind of scenario is to change the scope. Change what we are delivering. Change the feature to be less of a feature. Instead of supporting all use cases or most use cases, maybe you only support the primary top three use cases for that particular feature. This solution and most solutions to negotiation share something in common. You'll notice that what we've done is we've broken the bond, this seemingly unbreakable connection between the feature and the date that that feature should be delivered. We've broken it by changing one side. In doing so, we've uncovered something that is critical in most of these negotiation scenarios. That is a false coupling. Think about it this way. If one side gets everything they want, the other side gets nothing that they want and vice versa. The coupling in this case is imagining that the complete feature and the date is actually what the product owner, manager really wants. Whatever that stakeholder is, they want the full feature and the date all together. But by breaking these two things apart, we shatter this illusion of coupling where it didn't actually exist. We're going to talk about why this technique is so important, not just in reducing your feature scope, but in every other scenario where you're trying to balance the trade-offs. Speaking of trade-offs, you're going to make trade-offs in your software all of the time. Today's sponsor is going to help you break some of those couplings, allowing you to be more flexible with the trade-offs that you're actually making. Once darkly, this feature management for the modern enterprise, it fundamentally changes how you deliver your software and hears and what works. Once darkly, it enables development and operations teams to deploy code at any time, even if a feature isn't ready to be released to users. We're talking about decoupling these things today. In this particular example, we're decoupling the release of your code, the pushing of your code from one environment to another. Your code can go into production without actually being released to users. This is an important decoupling. You can wrap your code with feature flags, which gives you the safety to test those new features and infrastructure in the production environment without impacting the wrong end users. When you're ready to release more widely, all you do is update the flag. The changes are made instantaneously with a real-time streaming architecture. Go and check it out. Head over to launchdarkly.com. That's launchdarkly.com to get started for free. Thanks again to launchdarkly for sponsoring today's episode of our full-length event. In our example, we decouple the fundamental parts of the bargain. In other words, instead of looking at the whole thing as one untouchable piece where a given feature is supposed to be delivered by a given date and neither the date nor the feature can be touched, we instead break those up and we say, which of these is more important? Is the feature more important or is the date more important? But beyond this, the critical piece of this technique is actually to ask what is important in the first place. Not just the feature and not just the date, but is there something else? Is there a specific issue that can be resolved that makes it feasible to reach the most important pieces of this delivery? And you should notice on your teams that this tradeoff has made quite often. Very often, you'll have a feature that is well thought out, something that really can't be delivered without the scope that is already defined. And that feature delivery may happen in stages, but ultimately, the completion of the feature is not really up for debate. Whereas the date is actually relatively flexible. In this case, what you see is the thing that matters, the thing that is important to your stakeholder is actually the feature itself. It's not really so much the timeline that it's delivered on. This kind of thinking is employed in all kinds of negotiations. For example, let's imagine that you get a job offer and you suspect that you could get paid more elsewhere. Well, instead of the prospective employer just increasing your offer, your salary, maybe they change a different aspect of your agreement. Maybe they give you a little more vacation or they change something about your stock options. But perhaps the more interesting versions of this are where things that don't have an explicit monetary value like vacation or a stock option, they might speed up your investing schedule. Whereas most employees may have a four year investing schedule, yours, you may have some immediately vested interest in the company. This is an unlikely scenario, but these kinds of tactics are useful in negotiations because they find value. Finding value is a critical part of all of our jobs. We find value in the work that we do and we find value for our stakeholders. We find value for the other engineers on our team. We find ways of creating value for the company that we work at. And we find value for ourselves. If you're on a job search, you should be thinking about what is important to you. What are you making decisions based on? If you only have a single metric to make decisions on, then your opportunities, your flexibility, your ability to actually negotiate with your potential employer or looking for a job, your ability to find a job that might match your criteria that could maximize your different values, it's going to be much more limited if you only have one way of measuring value. But if you have a compilation of ways, a multi-approach to what is important, then finding something that fits might be a little bit easier. Here's the critical thing. Usually, what is important to one side of a negotiation is less important to the other side. So in order to negotiate well, whatever scenario you're in, whether it's in that team scenario or in a job negotiation, or maybe you're doing a kind of special negotiation with yourself. What does that look like? Well, trying to decide between one feature or another, you're trying to negotiate between the two of those. If you can find the things that are important to one side and less important to the other, then the side that they're not important to, they can give that part up. And so if both sides give up things that are not important to them, but are important to the other side, a positive negotiation position can happen. In other words, a situation where neither side has to give up something they don't want to give up. And yet, both sides are happy. In the previous example, let's say you're a manager and you have a team that doesn't want to give up their nights and weekends in order to meet an unrealistic deadline. Well, they don't necessarily have to. In fact, they don't have to give up anything they don't want to give up. And the opposite side may not have to give up anything either if they believe that the paired down version of that feature is just as satisfactory as the full featured version. The key here is to think about breaking these problems down, shattering that false coupling that we do so easily. And it's not just two things necessarily. It could be multiple things and you're coupling all of these things together. Break those down into their individual concerns. Find what is important. And more specifically, find the things that are important to one side, but aren't important to the other. This is how we do good negotiations, not just negotiations, where you're trying to convince another person to give you something, but also negotiations in our everyday decision making. Thanks so much for listening to today's episode of Developer Tea. I hope you enjoyed this episode. Hopefully it was an interesting exploration on this idea of negotiation is such a powerful concept. If we start looking for negotiation in our day to day lives, this is happening all the time all around us. Most we talk all the time about decisions on the show. So many times the decision being made is happening after some kind of negotiation. So typically those things are happening in concert. So we will talk quite a bit about negotiation on future episodes of the show. If you don't want to miss out on those, go ahead and subscribe and whatever podcasting app you currently are using. And of course, if you want to help the show out, leave a rating or a review, I guess both in iTunes. iTunes is the big one of course. And then the other podcasting platforms are helpful as well. Thank you so much for listening and until next time, enjoy your tea.