Hey everyone, welcome to Developer Tea. My name is Jonathan Cutrell. In today's episode, we're going to be talking about flexible decision terms, flexible decision terms. Today's episode is sponsored by FreshBooks. FreshBooks is the ridiculously easy to use. Online accounting software designed to help creative entrepreneurs get organized, save time and get paid faster. We're going to talk about what FreshBooks has to offer to Developer Tea listeners later on in today's episode. But first, I want to jump in through this topic because I have a lot to say about this particular concept. A new article comes out every week, it seems. Talking about the reasons developers need to stand up for themselves and say no. I was actually sent one of these articles by one of my co-workers today, which has really inspired me for today's episode. Most of the time, the tone of these articles, the tone that these people are portraying reveals really strong discontentment with whatever their situation is. And eventually, almost all of these articles leads to one common end point, which for the sake of this episode, we will call the shutdown. Basically, someone comes to you, the developer with a request, and they have a request maybe for a feature, a timeline estimation, or maybe assist a technical question. Perhaps it's, for example, a designer asking whether or not a concept they've designed is feasible, or maybe it's a manager asking for an update regarding a client lead. And the advice comes from a good place. This advice to say no, stand up for yourself, comes from a good place, because with all of these requests, with all of that incoming request traffic, we have to learn a way of mitigating the lack of productivity that can occur from the constant interruption. And we've talked about focus in the past, and this is tightly related to focus. A lot of the time, we think that the best way to gain focus is to shut everyone out, to close our doors, to say no to everything, to get everyone out of our way, because we don't have enough space to think. And these people don't understand what it takes to be a developer. How many of you are right now, you're listening to this episode, and you're feeling the emotion of the developer who is constantly being battered with these questions. It's a very common situation. And sometimes that means denying the request, right? Sometimes no, is the right answer. And that's okay. A recent article came out that a team member shared with me has already told you. And I'm not going to call the author out directly by name. And honestly, there's so many of these that calling them out by name wouldn't necessarily even matter. But the article mentions the fact that we live in a culture that encourages a constant yes mentality, a hyper positive mentality, where we feel the peer pressure to accomplish as much as possible. And this truly can leave us exhausted. I totally agree with this particular point, by the way, in this article. And even in our leisure time, we are driven to accomplish something. The article references the need to track steps or check in at every coffee shop we ever visit, just to beat our friends so-called experiences or check our Twitter constantly for retweets or favorites. And this doesn't leave us much room for contemplation. And eventually, it totally wears us out. We have no energy to put into the things that we need to put it into. And therefore, we have this massive, devoid lack of focus or devoid of focus. So the natural response that we have is to swing back the other direction and start saying no all the time. No to as many things as possible. We go hyper minimalist with our time, with the way we spend our time. And in the article, the author mentions a manager, for example, coming to your cubicle and asking for a rough estimation of a new feature. And they suggest that you simply say no. And a lot of us as developers, we find relief in that concept that we can look at a manager directly in their face who is asking us for this rough estimation that we are not really even able to give them at that moment. And we simply say no. Now, I want to analyze this a bit because I think there is a better way. I think there is a more complete solution to this problem. And we're going to analyze it right after we take a quick sponsor break. Today's episode is sponsored by FreshBooks. FreshBooks has invoicing. You can use FreshBooks to create and send an invoice in literally about 30 seconds. And then your clients can take that invoice and pay you online, which often means you end up getting paid a lot faster than if you had to wait for them to send you a check. If a client forgets to pay you on time, FreshBooks will handle the awkwardness and send them a reminder. FreshBooks will also help you take care of your finances, your expenses. You can track your receipts with their mobile application. And FreshBooks can automatically import expenses directly from your bank account. So you can use your online banking as usual. And FreshBooks will have a track of that online banking just like you do. You can track your time with FreshBooks. So FreshBooks will automatically create an invoice for you. And you'll know what you did and when you did it. All of the details about your cash flow are kept in one place. So FreshBooks knows exactly what invoices you sent when you sent them and who's paid you and who owes you what. This is perfect for those of you who don't love to open up a bunch of spreadsheets. So to claim your free month, this is the important part. If you haven't been listening yet, listen up to this to claim your free month of FreshBooks. You can go to FreshBooks.com slash Developer Tea. Make sure you enter Developer Teain the how did you hear about a section so that FreshBooks knows where you're coming from. That's FreshBooks.com slash Developer Tea. And of course that link can be found in the show notes at spec.fm. Thank you to FreshBooks for sponsoring today's episode. So we're talking about flexible decision terms in today's episode. We haven't talked about those just yet because I'm laying out this problem for you. So far we've discussed the motivation for the episode. I've talked a lot about these things in the past, in past episodes of Developer Tea. But it can't be overstated that the average developer is seen as closed off. And that can be detrimental to a developer's career. It can put a ceiling on your career and you won't even know it. And this show believes in long, happy careers for Developer That have upward mobility if you want it. If there's one goal I have on the show, it is to help cultivate better, happier, higher earning, more productive developers in the world. And the truth is a lot of our habits are adopted out of a basic reaction rather than out of reason and logic. And because there's such a strong demand for developers, we aren't talking about this stuff very much. And we feel free to do these things like the total shutdown. Right? We feel free because we have relative job security. We can go anywhere that we want to go. It seems everyone is a software company. So let's examine our previous scenario and consider everything that's going on because I believe that developers can be better than that. We can change the perception away from that closed off perspective and start changing that narrative about what a developer is. So let's examine that. We have a manager, perhaps a project leader who's coming to your desk and asking for a rough estimation of a new feature. The author of the article recommends that you simply say no to that manager. Let's take a step back for a second and put ourselves in the manager's shoes. If I'm a manager, I'm searching for your help. That is the top of this problem. I have a problem that needs to be solved and I'm searching for your help. I have a certain amount of money that has been allocated to solve that problem. I want to know if I can exchange that amount of money for a solution. So I go to the person who will implement the solution. That's you, the developer. Now, here's where things get a little bit ugly. When I approach that developer, I get an immediate shutdown. Now I'm left with unanswered questions. And in a situation where I can't even help the client and I can't communicate with the developer. On top of that, I don't have the expertise necessary to answer the questions myself that I need answered. So what's my next move? I'm kind of stuck, right? Who can I turn to? If the developer shuts me down, my only choices are to guess, decline the client's requests, or hire a new developer who will answer my questions. Now, you may be thinking that rough estimates are the enemy here, not the manager, or the client, or the developer. But the reality of this situation is that an excellent developer, a successful developer, will instead of shutting that manager down with a flat no, they'll look for the underlying problem. When that manager comes to them asking for a rough estimate, they're looking for help. And an excellent developer recognizes that the manager is looking for their help. And it may be that the underlying problem is harder to solve than a rough estimation provides, or it may be that the rough estimation is the correct solution to that particular situation. But the wrong answer in almost every case is to shut that manager down entirely. Now this doesn't include situations where someone is asking you to invest your money outside of your everyday job. In this discussion, we're talking primarily about people you have already chosen to work with, whether that is a client or a co-worker. But on the flip side, if someone is asking you to volunteer your time, sometimes a flat no is the most correct answer. But a successful developer understands this simple concept. The answer to any request can almost always be yes given the right scenario. The answer to most requests can almost always be yes given the right scenario. I like to call this the yes if, the yes if, yes if we have enough resources, yes if I have enough time, yes if the range that you're asking that estimation to be in is wide. And the yes if, is really what I mean when I say flexible decision terms. We have a tendency to think in binary and we make a lot of assumptions about what is being asked of us as developers. These are some of the shortcuts that are brains are taking. For example, in a rough estimation situation, we may assume that the manager wants that rough estimation immediately or by the end of today and they want it to be within a certain percentage of variation. But it could be that the manager would be okay with the rough estimation taking a week and it being a very wide range. If we extend the terms of the decision, in other words, if we stop thinking that the request is based on the current circumstances and instead think about the circumstances that must be true for the request to be fulfilled, we can begin to empower others instead of shutting them down. Make sure you catch this. Flexible decision terms means that we are thinking not about the rigid current circumstances, but instead about the circumstances that must be true for the request to be fulfilled. And the interesting thing is this is mostly a language shift. Even in the article that I mentioned earlier, the author talks about explaining the caveats for why they shut down that particular request. The biggest difference in that developer in the article is that they were waiting for someone to inquire the why question. They're waiting for someone to ask why after that shutdown. But a good developer, an excellent developer, will explain what is necessary to fulfill a request rather than shutting down directly out of the gate. And here's the crux of the whole issue by replacing your nose, by replacing your immediate shutdowns with yes ifs. By replacing your nose with yes ifs, you may end up in a better situation in the long run anyway. For example, if a client comes to you and asks for something that requires a very large budget, if instead of saying no that's too expensive or no that's going to be really difficult, if you instead say yes if you're willing to pay a substantial amount of money, that client might be ready to write a large check to you that day. There are countless examples like this where yes ifs wins out over no. And on top of this it doesn't take hardly any more effort to say yes ifs. Essentially just giving reasoning for why this is not possible with today's current circumstances. And you're giving what the the circumstances that you need to be true to fulfill that request. Yes if wins out over no. So the next time you get a seemingly off the wall or extreme request from a client or a coworker, don't shut them down immediately. This is toxic thinking. Don't shut them down immediately. Instead discuss with them the feasibility of their request, the timeline, the resources necessary to accomplish it, the uncertainty that exists around that particular request, and the external factors and the risks. It is likely that the person who is requesting your energy would be much happier to sit and discuss those things than to be shut down entirely. And in the end you will have a better relationship with your clients and with your coworkers. And ultimately you're going to become a better developer. Thank you so much for listening to Developer Tea today and thank you to today's sponsor FreshBooks. FreshBooks is the ridiculously easy to use online accounting software designed to help creative entrepreneurs or developers get organized, save time and get paid faster. If you want a free month of FreshBooks 100% free, go to freshbooks.com slash Developer Tea and enter Developer Teain the how did you hear about us section so they know that you're coming from us. Thank you so much to FreshBooks and thank you for listening. If you're enjoying Developer Tea, make sure you leave a review in iTunes. This is the best way to help other developers find the show. And if you have not already done so, take out your phone or open up iTunes on your computer or wherever you are listening to this episode. Take it out and subscribe to Developer Tea. This will make sure that you don't miss out on future episodes of Developer Tea. We talk about this kind of topic all the time. So if you enjoyed today's episode, you're likely to enjoy future episodes as well. Thank you so much for listening to Developer Tea and until next time, enjoy your tea.