We're going to start today's episode with a familiar story. Our hero developer, we'll call her Anna, has recently started working on a feature on a team that she recently joined. The requirements she needed to accomplish her part of the work were a little bit late, but she's started on it and she's making headway. In a meeting, a product owner, we'll name him Brad, reminds everyone in the meeting that a deadline is approaching. Anna's manager, Kendra, reminds everyone also that this feature is very important for our bottom line. And then turns to Anna and asks for a prediction on when she'll be done with her part, an estimate. Now, this moment is a difficult scenario for everyone. And honestly, it's often better to avoid this altogether. We're going to talk about why and what to do about it in this episode. My name is Jonathan Cutrelli, listening to Developer Tea. And my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. You probably have been one of the people in this story. Maybe you are a fourth person that we didn't name. Maybe you've seen this happen in your company and it made you uncomfortable. Or maybe you are the one that has put... the pressure on someone like Anna. Or maybe you are the engineer. Most of us have experienced what Anna experienced. How do we arrive at moments like the one in this story? How does this happen? The stress in this meeting, it can be enormous. And the moment is critical in a project because it represents a moment of intense pressure. And we arrive at these moments. Most of the time, we're not going to be able to do anything. Most of the time, by mismanaging our expectations, by having teams that are relying on estimates too heavily. There's a lot of ways that we can arrive at a situation like this. And it doesn't always look exactly like this. There are other ways that we can arrive in a moment of intense pressure. Not only is the team generally put under pressure by an approaching deadline, for example. And the apparent late deliveries that have already happened. But the individuals in our story each have their own pressures to deal with. For example, maybe you are like Brad, the product owner. And you're trying to figure out when things are going to be done. And it seems like nobody can give you a straight answer. Or maybe you are the engineering manager. And you feel like you're not really doing your job unless you communicate to your direct reports just how important this particular feature is. And try to help people. And try to help them meet their goals. All of this seems reasonable. But it ends up putting pressure on the engineers. And we're going to talk about the fundamental issues of using pressure. This is something that happens all the time. Using pressure as a tool for manipulating priorities. This is what is essentially happening here. Whether this is overt and on purpose. Or whether it's happening accidentally. By communicating all of the importance and the impending deadline. And all of this that's happening in the meeting. Is ultimately going to have the effect of using pressure as a tool for manipulating priorities. Even if this is the engineer's top priority. Perhaps this pressure will make them manipulate even their personal priorities. And have them stay late at the end of a work day to finish something. We'll also talk about ways to avoid this scenario. As well as ways of diffusing pressure when it inevitably creeps into our working processes. But first, let's talk about the issues that pressure causes. The issues of putting pressure on, especially putting pressure on individual contributors. Pressure ultimately results in stress. Stress. Stress. Shouldn't be a huge revelation. If we start putting pressure on somebody. Putting them in an awkward scenario. Where they have to, for example, produce an estimate. For something that is of an unknown quantity. While everybody's watching. This is an emotionally stressful moment. It is a socially pressured moment. It's a professionally pressured moment. There's all kinds of leverage against this person in that moment. To say the right thing. And very often, the truth is a difficult reality to accept. It's a hard thing to say in that moment. For example, in our scenario, Anna very likely should have said, I don't know. I don't know when this is going to be done. I know it's important. I know that it should be done as quickly as possible. But I don't know how long it's going to take. Pressure can also lead people to overwork. We already kind of talked about this and how it happens. The using pressure as a tool for manipulating priorities. If this item is already the top priority on your list. While you're at work. And it doesn't seem like you're going to be able to finish it. Well, adding pressure to the situation might make you intuitively believe. That you need to cut into your personal time. Or cut into your personal priorities. In order to get more done. To finish the project in time. Right? This can lead to further stress. And eventually burnout. And this all compounds into poorer quality work. And if we continue to do this. We also train ourselves to answer pressure. By increasing that workload. To respond to that stress by working more. And ultimately the product that we're working on is going to suffer. Pressure to make a commitment in the moment. Is often formed. As an emotional plea. Rather than a rational one. In most cases. The on the spot estimate is unlikely to be accurate. Right? In this scenario that we presented. This is essentially an emotional plea. Because we're making an argument. And we're waiting for someone to respond. To an argument that they already know the details of. We're not comparing these items to other items. For example. Right? There's no processing of information. There's no kind of algorithmic prioritization process that's happening. Essentially the case is being made for just how important this task is. And overemphasizing this leads to essentially an emotional plea. Rather than a rational one. Now the truth is. When we have these emotional pleas on the table. When we're being pressured to prioritize this. Over other things. But we don't really know why. Other than feeling that pressure. Right? Where we are basically filtering what we're feeling. And turning that into adjustments in what we are prioritizing. Well this gives us mixed signals on how we are supposed to prioritize. The stakes in this situation aren't even clear. For example. What is the actual cost of having to delay the launch? You've told me how important it is. But why exactly is it. The most important thing. Or why exactly is it important to deliver by that particular date? Have we discussed. For example. The possibility of incremental release. With our stakeholder. Maybe that's a way of avoiding the situation. Where we're in a high stakes scenario. Pressure tends to occur as a result of urgency and reactive behaviors to begin with. So it's also likely that we're not only focused only on what we're pressured to do. But also. We might miss out on prospective opportunities and priorities. In other words. Things that nobody's really telling us to do. But that we really have a huge opportunity. If we did them. For all of these reasons. Pressure. Can turn into a poisonous substance. In our teams. Now that doesn't mean that pressure is always bad. And of course. Pressure can be used as a signal. To help us prioritize. Pressure is often the downstream effect of some kind of market force. Somebody wants something upstream from that. And so they're asking for it. They're willing to pay for it. But they need it by a particular time. For example. And this is where our pressure is born. Now that market force. Is important for business to continue. And it's important for us to listen to it. But it's not the only important thing. So we shouldn't. Discard pressure. Or think of it as evil altogether. But instead. We shouldn't consider pressure. The kind of end all be all way. Of moving something from. A normal prioritization cue. To a high urgency one. This is the primary mistake. That gets made far too often. What should we do. Though. What should we do. When we find ourselves. In a pressured scenario. Or to avoid one altogether. That's what we're going to talk about. Right after we talk about today's sponsor. Square. Today's episode. Is sponsored by. Square. You probably know them for their payment devices. These are the little white card readers. That you find at farmers markets. And you've probably bought a coffee. On one of their point of sale machines. Square is already trusted by millions. Of sellers worldwide. That's probably why you've seen it. And Square has APIs. For running every aspect of a business. And they're now making them available to you. As a developer. With a simple rest call. You can tap into Square's enterprise grade. Customer point of sale APIs. To manage employees. Organize customer data. Generate invoices and gift cards. And create loyalty programs. And even better. There's no cost to developers to use these APIs. In fact quite the opposite. You can try out Square's CPOS APIs. Today. For a chance to win. $20,000. In the build what's possible hackathon. For more information. Go to squ.re. Slash cpos. That's squ.re. Slash cpos. Thanks again to Square. For sponsoring today's episode of developer team. So what can we do. About being under pressure. We can't always avoid it. When it happens to us. We can't predict when somebody's going to put us on the spot. In the meeting for example. But perhaps the most important thing you can do. In that moment. Is to search for a relief valve. We may not be able to resolve. The underlying cause of the pressure right away. But it's likely that there's a way. To relieve the pressure. Relieving pressure tends to provide. Flexibility. And it reduces that. That stress that's going to cause. Burnout or. Poor quality work. And creates a more functional operating environment. And sometimes the relief valve. Is actually coincident. With an MVP implementation to begin with. In other words. If you search for this relief valve. It's possible that you'll find. A more efficient way to get done. What you were trying to do. With a more complicated approach before. So this approach is. Not only good for relieving that pressure. But it's also good. As a product principle. To begin with. Another important thing to recognize. Especially for managers. Is that when you are asking for commitments. Make all of your commitments. Asynchronous. In other words. Give the person time. To respond to you. Offline. This allows both you. And the person to go. And do your separate research. And it avoids the social pressures. Of trying to make. An overly ambitious. For example. Estimate about when that work. Is going to be done. This principle can apply. To almost any kind of commitment. For example. When you're hiring. Allow the candidates. To make all of their commitments. Asynchronously as well. If they're going to accept a job position. With you or not. Don't use pressure. As a way of manipulating. Their decision making process. This almost universally. Results in poor decisions. Another incredibly. Powerful way of handling. Pressured meetings in particular. Is to do a pre-meeting discussion. Even if it's. Three to five minutes long. And the intent of this discussion. Particularly for managers and the reports. Is to set expectations about what you believe the meeting. Will entail. This might be a good time for a manager to encourage. The engineer. To feel free. To be honest about. Not knowing how long something might take or. To come up with a reasonable estimate together beforehand. Rather than being put on the spot to do so. In the end. We're never going to be able to completely eliminate. All of the sources of pressure that we face as engineers. But we can find ways. To relieve that pressure or to work with it in. In reasonable ways that use it rather than. Allowing. It to poison. All of the work that we're doing. Thanks so much for listening to today's episode of developer T. Thank you again to square for sponsoring today's episode. A reminder you can win $20,000 in the build what's possible hackathon. For more information and to register head over to SQ you. Dot re. Slash CP. OS that's SQ you. Dot re slash CP OS. You can enter that hackathon today. Thanks so much for listening. And until next time. Enjoy your tea. .