We're going to start today's episode with a familiar story. Our hero developer will call her Anna as you 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 will name him Brad. And 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 in estimate. At this moment, this 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 Cutrell, 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 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. 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. All right, 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 meaning 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. 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. This 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 is 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. And a 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 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. 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 over emphasizing 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 an 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-stake 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 to kind of end all be all way of moving something from a normal prioritization queue 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 their 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 Developer To use these APIs. In fact, quite the opposite, you can try out Square's CPS APIs today for a chance to win $20,000 in the build what's possible hackathon. For more information, go to squ.re slash cps. That's squ.re slash cps. Thanks again to Square for sponsoring today's episode of Developer Tea. 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 stress that's going to cause burnout or poor quality work. It 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. 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 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 Tea. 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 squ.re slash cps. That's squ.re slash cps. You can enter that hackathon today. Thanks so much for listening and until next time, enjoy your tea.