What is a task? You might say it's something that you need to get done, it requires action. I agree. This is a good definition and yet I have an insatiable desire to pick things apart and find their limits. So what are some things that require action that you would NOT call a task?

How about habits? What about projects? You ever seen a "sub-task" in the wild?

Projects are collections of tasks, that's a fairly intuitive definition. And Tiago Forte does well to draw barriers around projects being completable and time bound. In his view, if something is ongoing indefinitely, it's called an AREA but we won't get into that for this article.

You might start to pick up where I'm going. There seems to be a lot of subjectivity on what's called a task. And my brain does NOT deal well with this. I need to know the rules so I can at least know when and why I'm breaking them. To some people, “make a cake” might be a project, but for others, it's just a task. Context is obviously playing a key role here. Baking a cake is certainly a project for someone like me but for a baker, it's one of many things on their task list.

One method for making and assigning tasks that I really don't like is step-by-step instructions. There are rules and exceptions but task management becomes an absolute bore and chore when a bunch of little tasks are created for each step. You end up not actually needing to consult each one and when you've baked the cake, you just go through and check all the little steps to get there. It feels a little cheap too - not as satisfying.

Did you ever do that exercise in school where you had to write every step of making a peanut butter and jelly sandwich? Were you the one who wrote it all out in 3 easy steps or were you the person like me that wrote down every step, every breath, every eye movement, ad noseum? That's my point - if PB and J is the project, what's worth writing as a task list? Or for that matter - and an important piece to this whole rant - when is PB and J a project and when should it just be a task? Everyone knows how to make one.

It begs the question, why do we write task lists in the first place? If there are infinite permutations for how one can draw a circle around a pool of action, then a "task" is not an objective thing of the universe. Its a concept we use to understand and interact with the world, like minutes and hours. Time is a real thing (although even time starts to bend under particular circumstances) but minutes and hours are concepts. Ancient societies counted in base 12 and divided the day into 24 hours . But we count in base 10 - what if we would have divided the day into 20 hours? The point is, it’s subjective. Much the same with tasks - action is part of the universe, but drawing a circle around it as a concept - well that seems to be in the eye of the beholder. I only wish we had some standard idea of what one was, even it was arbitrarily contrived.

It's important to consider the practical use of task lists - they're for documenting important details. You write things down so, at the very minimum, you won't forget. But you can also write them down to prioritize, to strategize, to clear your mind and focus, and even to delegate. Yes, enter player number 2 - the collaborator.

Now peanut butter and jelly just got interesting. Let's be real, you only need one task for PB and J aptly titled "make a peanut butter and jelly sandwich". You understand the assignment. Anything more than that is tedious at best and distraction at worst. But when you have to work with someone else on it, now you've got to organize. You need to distribute responsibility, maybe even be strategic with different skill sets, giving certain parts to certain people. Maybe you're collaborator is a tactical jelly spreader and you are the mastermind of peanut butter to jelly ratios. Maybe you slice while they spread. Maybe you're at home and they're at the store. You start to see how you many ways we can slice this PB and J (yeah I said it).

NOW, it's actually helpful to write the different stages or steps of the process. It's actually critical so you don't work over each other and you understand who does what do you can crank that sammich out STAT.

Tasks are for communicating desired action. KISS. Keep It Simple Stupid. Dont introduce noise to the signal.

Now, let's poke a big hole in what I just said.

Follow that logic and all you have to write down is "make a million dollars" right? Well, if you know how to do that without any further planning resources, power to you, let's talk. But you can go too far and make tasks that are too big manage. The truth is, we feel good when we complete something and we should hack that a little. And sometimes it's mentally hard to start something when it's too big, when you can't deliver on the thing you desire to do. You need to break it down into manageable pieces. You have freedom on how you do this and you can still draw different sizes of circles around the different pieces to make sense of them - but I dropped the key word in there, did you catch it?

Deliver.

What can you deliver? What can you wrap up and call complete? What can be a finished part of the project that is intuitively understood? Think about handing it off to someone else to continue the work. Will they easily understand where you left off so they can pick it up?

I like to think of this as a Minimum Viable Deliverable. MVD.

It's a play off off Minimum Viable Product, a common concept used for product development. Especially for software engineers contracted to build a program within budget, it's important not to start building the Burj Khalifa only to run out of funding with 1/5 of it complete and none of it livable. Instead (and much easier to accomplish with software), you build an MVP, something to deliver to the client that is fundamentally a complete but minimal product that accomplishes the basic mission. And then iterate.

In a similar vein, you don't want a task so large that you set out and aren't able to complete anything whole and useful from it. It's not that you're trying to get away with the least amount of work, we're not talking about the actual action itself. We're talking about the act of task management and how to write an effective task list. Make it deliverable and intuitive, and make it minimal. Communicate only what's necessary to whom it's necessary for.

Embracing the subjectivity of tasks has been helpful for me. Instead of seeing a project as a collection of pre-defined tasks, it’s now up to me to decide how to tackle it. We’re just taking one slice at a time until the delivery criteria of the project is met. This might sound silly but the best way I’ve started to think about it is like an apple. There aren’t really pieces to an apple - but you can’t eat the whole thing in one bite unless you’re a horse. I think about pulling out my pocket knife and slicing the apple bit by bit and eating it one piece at a time. Rather than trying to deconstruct a project as if its made of bricks, I’m just taking a slice here and there. I’m finding one piece that can get me closer to project completion. I’m not thinking about how to slice away the core when I’m on the surface. I’ll get there when I get there.

So, if you're like me find the subjectivity of defining a task a philosophical dilemma - well you're a nerd. But also, I hope you're comforted by me basically saying that there is no objective answer to be found in reality, but we can work on our definition and dial it in. We can approach problems differently. Thinking in terms of minimum viable deliverables helps me keep it simple but also useful. task listing is a form of communication, a syntax of its own, and with it in our toolbelt, we're that much better at achieving our desired actions and outcomes.