Happy Wednesday. In today's episode, I'm going to share with you a small framework, very simple framework that you can use to deal with some complexity that you might be experiencing in your day-to-day work, in your day-to-day role. And I want to share this with you because there's something I've been using in my job that I think is, it kind of simplifies a lot of different, much more complex self-management techniques and prioritization techniques that you might find. This is a very simple framework that I'm using. And it relies on essentially one primary tool, one primary tool I use that everyone has. If you have a computer, you have this. Even if you have a notebook, you have this. A little bit harder to manage, kind of the longer run on the notebook, maybe a little bit harder to learn from your history in a notebook. I do find that for parts of this, having some duplication is okay. All right. So what that means is... I want to use your notebook for parts and pieces of what I'm about to talk about. But the system is so simple that you can kind of intuitively pick it up. As you are going through your day planning, as you're going through your week planning, whatever your planning exercises are to get your stuff ready. And a lot of the power here comes from the simplicity. That's the important thing first to note. A lot of the power in this setup that I'm giving. Is in its simplicity, in its portability. You can kind of add and remove from it how you would like to. But the basic idea here is to think about the life cycle of information. That's the core kind of insight that I want you to take away or take with you as you move into your work. As you try to apply this method. So the method is very simple. Make sure you have some kind of text editor. Hopefully you're opening one right now. If you're driving, of course, don't worry about it right now. Come back to this later. If you have... If it's just a notes editor, then this might be a little bit more difficult. Something like Notion, something like Obsidian, something like Reflect. Any of these would work fine. The idea is to... Is to have some kind of way to jump between notes. Your Apple Notes can do this, but it's a little bit more unwieldy. A benefit of Apple Notes, of course, is that it's... You know, if you're in the Apple ecosystem, it just kind of transfers from device to device pretty easily. But you can get that set up for, of course, Notion. All these other tools essentially support that as well. All right. So this is a... This is much more kind of concrete, practical than we normally get on the show. But the reason that I'm giving you all this information is so you can go and try this out. Realistically, this is a very kind of... A principles-driven approach to managing your incoming information. Right? That's really what this is about. So that's the first step in this exercise. I want you to identify all of the possible incoming channels that you care about. For example, you may have incoming channels for each of the teams that you're on. Or you may have incoming channels for each of your reports. Maybe an incoming channel to capture information that you care about for your direct manager. You may have an incoming channel for information about your home or about your family. You get to decide what this incoming kind of inbox is. Now, the important thing about these incoming channels is that whenever you encounter information that is relevant to that channel, you start here. Right? This is a free-form text document. There's so much you can do with this free-form text document. It starts as raw thoughts in this space. So the first step, again, is to identify where do you have... Kind of commonly have information incoming. That is relevant to a particular thing. All right? So try to create these kind of... Maybe you have short-lived incoming documents, notes, whatever you want to call these things. There's free-form text, a short-lived incoming document for a project, for example. Now, this might sound familiar to you if you've used kind of the get-things-done method. The difference here is that we're not really counting... We're not really creating tasks yet. This is information, pure information that you may or may not know what you're going to do with it yet. It's not necessarily actionable. It may just be information that you need to document, file away for reference later. Of course, that filing does take effort, but you have these incoming documents to start here. Now, my recommendation is to actually name these notes. With the word incoming in them. And that's important for your quick fuzzy searching or whatever. So you can quickly jump to the note. Whenever you're in a meeting, you always have your incoming note available to you when you're in your meeting. If you're actively working on a ticket, if you're actively working on a project, you have an incoming document open, ready to take notes as you're working. So the important bit here is that we encounter information in the moment. As we're in a meeting, we are encountering information. As we're working on a ticket from the backlog, we're encountering new information. As we're taking an interview, we're encountering new information. These are all in process. And it's difficult to comprehend that information in the moment and to create some kind of action on the basis of a meeting. Because you're not going to take notes. You're not going to take notes. You're not going to take notes. You're not going to take notes. of that new information. Because it's so new, we haven't necessarily synthesized it into what we want to do about it. So if you're like me, then taking down this information for synthesis and analysis after the fact is a critical part of your workflow. And that's what I'm suggesting you do here with these two or with these incoming documents, right? In your notes sections, you can kind of adjust this however is useful for you. You might create sections in these documents to help you kind of go through that process. Maybe there's a raw incoming information section, and then you might have more refined thoughts that go towards the bottom of the document. That may be your process. Or if you use some of these note-taking applications, you can nest documents underneath. So it's possible that you could nest these incoming, kind of refined incoming or raw incoming. The whole idea here, though, is to have a very easy way to take in information that you know could be actionable. You don't know what the action is yet. But if you're, again, if you're like me, you probably have a bunch of these notes that you've started knowing that there might be something in there, but you didn't really, go back to it. There wasn't really a clear process for how do I return to the notes that matter? And so this is how we end up with all of these artifacts that are all kind of everywhere. You have all these Google Docs that are connected to your calendar meetings and stuff like that. This can be unwieldy, and you never really know what is important here. Where's the actual information that I need to pay attention to? So this method that I'm providing you here is one way to start down the list of things that you need to pay attention to. And so this is how you start down the path of collecting that information and separating it at one level. There's just one level of separation here. We don't necessarily have to attach information to a meeting. That meeting is likely about a category that is more or less top level in your life. And again, those kind of top level categories might be teams, it might be people. It's just the context that you care about that has sufficient information incoming that you would consider it a category. So this means you're probably adding to these documents on a daily or at least a weekly basis. That's kind of the heuristic for, you know, when these documents become useful. If you're not adding to it enough over time, it's likely that this information is fractured or fragmented to the degree that it's not incredibly useful to you. It's probably adding more kind of digital clutter than it is helping you be more productive. So we've already kind of separated the incoming recording of this information away from the analysis of the information. So next, you need to find the time that makes sense for you to do that analysis. This incoming information is only as valuable as it is refined. In other words, if you're just taking these notes, and then you never go back to them, you never do anything with that information. While it may help kind of solidify that information in your brain, there's some, you know, research that actually says that writing things down, even if you turn around and throw that piece of paper away, can actually help you remember things a little bit better. Even if that's true, it's much more valuable if you can actually convert these things into actionable locations. What are those locations? That's what we're going to talk about in a minute. We're going to talk about right after we talk about today's sponsor. This episode of Developer Tea is sponsored by Unblocked. How long do you think it should take to write seven lines of code? A couple of minutes? Maybe an hour? Or what if it takes five days? Is that okay? You might be tempted to think the developers on your team need help actually writing their code, but that's almost never the case. The biggest drag in software development isn't actually writing the code, it's having enough context to know what code to write in the first place. In a perfect world, your engineering team wouldn't waste time, days even, searching for the context to understand your application, but on average, most developers spend more than two hours a week trying to find information about how a codebase works. That's why there's Unblocked, to give your engineering team the answers they need to get their jobs done at the speed they and you both want. Your code base is a compilation of thousands of past decisions and discussions that live across tools like GitHub, Slack, Jira, Confluence, and more. Unblocked surfaces this history next to your code, so everyone on your team has the context they need. And when someone has a question, Unblocked answers with the accuracy of your most experienced engineers. Get started today at getunblocked.com. That's getunblocked.com. Let them know that you heard about them on your team. So we're talking a little bit about ways of dealing with incoming information. And I know that this is at the risk of sounding like, you know, just another productivity podcast. That's not our intention here. Instead, the goal here is to improve the quality of your product. So if you're a product developer, you're going to want to improve the quality of your information gathering. The offshoot of this is possibly a productivity increase. But really, the goal is instead to focus on the quality of the information and the quality of your actions. The most important part of this is recognizing that information requires some kind of response in order for you to glean any value from that information. In other words, the information you learn in a meeting. It may be that there's something for you to do with that information and you need to understand what it is that you need to do. It starts with gathering the information in the first place, but then moving on to that analysis part. All right, so it may be that at the end of a meeting, you review the notes for 10 minutes and you try to figure out, okay, what parts of this actually are actionable for me? What can I do with this information? What does it imply? What can I connect it to? Are there other parts, other things that I've been working on that this connects to? I'm going to give you a basic framework for what to do with this information once you've collected it. Once it's in your incoming document, what do you do with it? And there may be a lot of answers to this question. I don't want to oversimplify how you deal with information. I'm going to give you a basic framework for what to do with this information. But I am going to provide a simple pathway of prioritization. Okay, a very simple pathway. As you're reading through these incoming pieces of information, and hopefully you're doing this soon enough after the information has landed that you haven't lost the context, and it's really acting as more of like a reminder of the information itself. But as you're reading through this in kind of analysis mode after the fact, I encourage you to try to find one of the most important parts of the information that you've collected. And that's the four locations for this information. Okay, and so these four locations are mostly centered around your most critical asset, which is time. This is an asset that you cannot increase, and you cannot decrease, and everyone has the same amount of it. So this asset is your most critical because it is the most limited, and the one that you have more critically, the least control over. Right? So these, this orientation to time and information flow over time is kind of the core principle of this, of this framework in the first place. So as you're reading through this information, I want you to try to ask yourself, where on a timeline is this actionable? When specifically should I take action? I'm going to give you four buckets for this. Okay. Now, next, later, and never. Now, next, later, never. We're going to talk about each of these. What fits in now? Most of the time, the things that are in now, specifically as it relates to incoming information, okay, most of the things that end up in now tend to be urgent. And this is only because of the structure of the structure of the structure of the structure. Okay. The whole purpose of this exercise, if you just got off of a meeting, where you learned that there's a critical bug that needs to be addressed in your production software, that's causing, you know, thousands of, of users problems, this is a, now, problem, right? This is something that requires immediate attention. Now, I do think it makes sense here to mention the relationship between urgency and importance, and identify the fact that, Not everything that is urgent is important. Not everything that's important is urgent. The Eisenhower matrix is what this is, if you want to Google that later. But in this case, we're kind of ignoring that matrix for the moment. If you want to incorporate something like that to decide, okay, you know, what ordering do I try to impose on the list of things that are next? That's okay. But we're not trying to get into how do you prioritize a long list of things. There are plenty of other frameworks that can do that. Most of the time on the day-to-day, you probably don't have the ability to get to more than a couple of very important things. And so this kind of four-bucket prioritization method should be sufficient for most days. But the weakness here that I'll kind of identify in this method is, it is in some ways, it could lean towards being more reactive. So I'd encourage you to balance this out with longer-term thinking and planning that you put into your incoming list. Okay, this is another kind of source of information. Don't just use, you know, these external channels where other people are driving that information. You can drive that information yourself. Right? So the raw thought. The thoughts that you have about an important topic. You know, about a project that you want to be proactive about. You can have raw thoughts that you put into your incoming document in the same way that you would during a meeting or, you know, during a working session. Okay, so we've arrived at this idea that we have four buckets. First is the now. We've already kind of covered this. This is critically important things that take precedence over anything else that you're doing. Okay. So, unsurprisingly, only one thing can be done at a time. So whatever's in now is the only thing that can be in now. The next most important things, hopefully you guessed it, go in next. In a perfect world, the things that go in next are limited to maybe one or two things. Now, this sounds crazy because we're all used to identifying lists like backlog items. Items for a sprint. But the truth is, most of the time in our lives, we have enough unpredictability that we need to make decisions on a much shorter basis. So you need to be able to, you know, adjust what is in next. You might have something come up that you need to deal with. And next needs to stay flexible and small in order to quickly make those decisions in the moment. So that's now and next. Between the two of these, you should be looking at maybe three or four important things that you need to get done in a given day. And that's probably going to be most of your day. That's the interesting part of this. I would challenge anybody who disagrees with this. Go through your day. Try using this framework for a week. And let me know how many times you get past the later or next. Rather, column. If you don't get past it very often, then you've probably reached kind of the expected utility of the now and the next column. Now, you're putting too much in the next column if you don't get to it for, you know, a couple of days. Right. This is very unlikely, especially if you go past a week. Right. This framework is flexible. There's no hard line rules here. It's possible to use this framework. Up to, you know, three or four, maybe five days at a time where now and next covers five days worth of tasks. But I wouldn't go much more beyond that because now the granularity, because we only have four buckets of granularity here, if you have more than a week's worth of work that's in next, it's unlikely that you have enough prioritization between those items. And that brings us to the last two buckets. One is later. Okay. So this is. This is essentially saying we, you know, there's more important things to deal with. This is not something I'm going to actively invest time thinking about. We're going to put it into later. We're going to deal with this at a later time. All right. And finally, never. This is the kind of information that comes in that we might be able to take action on. But because we can't take action on everything, we need to have a way of. Of. Of actively choosing not to take action on a significant chunk of the incoming information that we receive. This is very much in keeping with the concept of a not to do list. If you've heard of this concept, we've talked about it on the show before. And the idea is to actively choose things you will not spend your time on. These are things that tend to be a little bit insidious. They tend to be interesting enough that we might consider spending our time on them. Right. This is the part that makes it difficult to parse sometimes. We imagine that this thing that seems like a good use of our time, we take a note on that. We imagine that we might participate in it. But when we look at all of our priorities, we simply don't have enough time to actually participate in that thing. Or there are more important stuff that comes before it. So if we were to try to put it into the next column. If we were to try to prioritize that. We're going to cannibalize our other more important things. It was a very basic idea of the not to do list. So we explicitly say, never. We're not going to do this thing. We've decided not to do it. And we reduce or just simply remove it from those incoming documents. So the end state here is to have a final document that kind of shows your highest priority things for the day. All right. This. Should be a list. It again, it's kind of an active list. Uh, you know, if something comes in faster than you can process it through your incoming document, that's okay. You may have, you know, something that comes in that you have to deal with immediately. Uh, that you didn't really have, you know, a moment of incoming to deal with it. You just know that you have to go and do it. You know, this, this method allows for flexibility for those kinds of things. Really all this does is it provides you a very simple. Uh, surface for dealing with your day to day. This is much, uh, much less overhead than trying to implement a full get things done, uh, process through, you know, um, something like to do list. There's a space or there's a place for those more involved methods that have longer running, you know, the, the, the weaknesses of the method that I've presented today. Like for example, you know, uh, one of the weaknesses is it doesn't really track deadlines. So. You may have something that doesn't really come up in your, uh, information gathering today or next week, but you know, you have to do it. You have to do it by a certain deadline. You have that tracked, uh, but it's not in your next, it's in your later column. And you haven't really, uh, you know, you haven't really taken a direct action on that thing, but you know, you'll have to. Right. This, this is a kind of a weakness of the system because, uh, you know, you can't really sort very easily with this. There's not a lot of granularity in the. Information. This is why I say, you know, this is really a supplemental. You could use your to do list. You could use your backlog. You could use whatever these other tools are to inform this tool, to inform this kind of mini framework. It's really intended to be zoomed in on today, tomorrow, maybe the next day. Again, this implies that, you know, maybe not necessarily weakness, but a designed, uh, uh, restriction here is this is not really useful for long-term planning. Right. This. Is not the goal of this particular framework. This is to, to wrangle the things that you do need to take action on in the, you know, in the short term. I hope you find this useful. I hope you find the idea of kind of pairing this with other frameworks that you might already be using. Uh, interesting. Uh, I'd love to hear more about it. You can join the developer T discord community, head over to developer t.com slash discord to join today. That's totally free. It will always be free. Uh, and when I also think today's sponsor unblocked. Uh, your developers know how to write code already. That's why you hired them in the first place. That's not what they need help with instead, but they're missing is the context to know what to write and unblocked gives engineering teams, the answers they need to get their jobs done without having to wait on or interrupt their teammates. You can get started for free. Get unblocked.com. That's G E T unblocked.com. Thanks so much for listening to this episode of developer T and until next time, enjoy your team. See you soon.