Today we're talking about how to think about requests and different ways to manage too many requests.
Requests are tied to expectations. In today's episode, we're talking about managing overload of requests and managing expectations so we can focus on our goals and have better working relationships with ourselves and our coworkers.
Giving is hard. When you donate, how do you know what a charity can actually accomplish with your money? Givewell, is solving that problem by connecting your money with charities that will see the direct impact of your dollars spent.
Visit GiveWell.org/DeveloperTea to find out about effective charities and get your donation matched up to $1,000.
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/.
What requests have you received today? It's likely that you've received more requests than you realize because some requests are implicit. These are things that are being asked of us from previous commitments, for example. Some simple ones might be requesting that you wake up on time by a particular hour so that you can make it to your place of work by some agreed-upon hour. Other requests are shared or cultural. For example, our culture requests that you follow traffic laws on your way into work. You may even have self-requests. For example, you might have requested of yourself, to get up early enough to work out or to eat the right kind of breakfast. Of course, on top of all of these implicit requests, we have those that are explicit. And it's not entirely binary either. Sometimes we have requests that represent multiple implicit and explicit requests, and we have to respond to those in reasonable ways. In today's episode, we're going to talk about how to respond to those implicit requests. And we're going to talk about how to respond to those implicit requests. And we're going to talk about how to think about requests, and how you might manage them a little bit better going forward. My name is Jonathan Cottrell, and you're listening to Developer Tea. And my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. Here's the reality. Much of our lives is determined by how we respond to the requests of others, as well as how we form and respond requests of ourselves. And this can have deep implications. And it can have a profound effect on our self-image and how we see the world. Let's say, for example, that you have a request of yourself that is unrealistic or unhealthy. This hints at the fact that not every request is formed intentionally. Now, if that's true of ourselves, then it's also certainly true of others. Other people may request either implicitly or explicitly. And if that's true of ourselves, then it's also certainly that you do something different than what you had planned to do, or that you do something in a way that benefits them. And they may not even know that they're requesting that of you. Requests are tied to expectations. Sometimes we set expectations that cascade into implicit requests that are unreasonable. As managers, we should be thinking more about what our expectations are. And we should be thinking about what we want to convert to in terms of requests. Let's say, for example, that it's Friday and we communicate an expectation that something is done by Monday. Well, this expectation may sound completely reasonable. But when we look at the request, we're asking people to work over the weekend. That is the implication of our expectations. So what can we do to manage the overload of requests? Some of these requests are irreducible. We can't really do much about, for example, our cultural requests. But others are well within our control. They're well within our commitment and well within our ability to manage. We're going to talk about how to do that right after we talk about today's sponsor, GiveWell. Giving is hard. When you donate, how do you know what a charity can actually accomplish with the money that you donated? For example, imagine that you want to help children. You've found two trustworthy organizations, but they run totally different programs. One can save a child's life for every $300,000 donated, but the other one can save a child's life for every $3,000 donated. If you could tell that difference between the two, you would be able to save a child's life. If you could tell that difference ahead of time, you'd almost certainly donate to the one that was 100 times better at saving children's lives with that money. And that's what GiveWell does. It's hard to know what charities will actually accomplish with your donation, so GiveWell spends 20,000 hours each year researching which charities can do the most with your money. They recommend a short list of the best charities they've found and share them with donors like you. Donors like you can have a big impact on your life. If you can't donate, don't donate. Donors like you can have a big impact on your life. Donors like you can have a big impact on your life. Donors like you can have a big impact. GiveWell's recommended charities work to prevent children from dying of cheaply preventable disease and helping people in dire poverty. You can learn how much good your donation can do by visiting givewell.org slash developer T. The recommendations that GiveWell provides are free for anyone to use, and GiveWell doesn't take any cut of your donation. First-time donors will have their donation matched up to $1,000 if they donate through givewell.org slash developer T. Thanks again to GiveWell for sponsoring today's episode of Developer T. So we've established the idea that requests come at us every single day from every angle. And some days are heavier than others. Sometimes the requests are even below the surface. We never really explicitly deal with them. For example, physical requests that are put on us by our environment or even by our age. And how we manage these requests is in large part how we manage our time. As we've discussed previously on the show, the idea that we commit to actions rather than committing to outcomes can have a profound effect on the way that we think about those outcomes, but also the way that we think about our time. When we make a commitment, it can be translated to time on the calendar. Similarly, if we think about all of the kind of expectations that we have of others, the expectations that others have of us, and the requests that those expectations translate to, the requests themselves are very similar to commitments in the sense that when you make a commitment, you're doing so in response. You're doing so in response to a request. A request is then kind of converted to a commitment. And so you should be thinking about requests in terms of, once again, how they translate to your calendar. And I don't necessarily mean that you have to pull out your calendar for every single request that you encounter, but instead, you should be thinking about the commitments that you make and the requests that you're willing to respond to in terms of how they affect your calendar. At the same time, you may want to consider bringing together your calendarijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij thinking, for example. But at the end of the day, the one irreducible reality that all requests have to abide by is time. And so if you can think about all of those requests in terms of what does this mean? What does this mean to my time and to my other commitments? The requests that have already turned into commitments. How can I balance this request with those? Now, here is the reality. Most requests that you receive should either be answered with a no or a maybe. Now, this seems heavy-handed, potentially, because there's so many requests that are necessary for us to commit to, to be able to do our jobs or to be a good person. And so, if you can think about all of those requests, you can think about how a good friend or a good family member. But it is because we have to say yes to those requests that we must say no or delay saying yes to other requests. This is not because we don't want to work with other people or be collaborative, but instead, we want to provide the proper amount of energy to the things that we are committing to. Additionally, when someone makes a request of you, generally speaking, they are not necessarily aware of all of the other commitments that you've made. Not only that, but no one else can possibly care about your time and your commitments as much as you do. Even the people that are closest to you, they can't care as much about your time and commitments. That's not to say that they don't care at all. Let me be very clear. Other people, almost certainly the people that you are collaborating with, they do care about your commitments and your time. That's not universally true, but for the most part, no one wants to run another person into the ground. We don't have these insidious motives. But most of the time, people are more ignorant of your requests and your commitments than you are. And so, for you to be the person who manages the requests and the commitments, that's your ultimate job. That's how you manage your time. And that is the essence of productivity. It's the essence of prioritization, managing the requests that you convert into commitments. Thank you so much for listening to today's episode of Developer Tea. Thank you again to GiveWell for sponsoring today's episode. To get $1,000 worth of your initial donation matched, head over to givewell.org slash developer tea. Thanks again for listening. Today's episode was produced by Sarah Jackson as a part of the spec.fm network. Head over to spec.fm to find other shows like this one. Thank you again for listening. My name is Jonathan Cottrell. And until next time, enjoy your tea.