This article has kept coming to mind for me this week. I like your concept, but have not been convinced of the "why" of work sizing and coming up with specific terminology. (Well, aside from the fact that I don't want "house reno" sitting on my projects list next to "plant-care" (i.e. doing the tasks required for keeping my plants alive today).
On a practical level, I'd say worksizing is on one level irrelevant, as long as have a umbrella for the work I'm thinking about. For example, in a given week I'd usually have a general aim to make progress towards goals by taking some actionable steps in X project, Y personal program, and Z life admin area. But these work sizes, are essential fulfilling the same tasks: providing a bucket that I want my work to fall into. On the daily level, all that work is going to be down in actions and tasks (whether taking 2 mins or multiple hours/days). But perhaps worksizing is helpful in setting realistic goals about how many things will be complete within a week/month/year and how many one might be able to touch in a day/week?
On a daily level, it's useful to know the umbrellas/handles for different work AND their size: I might do some time blocking to work on X, and so whether that's a task, project, or personal program doesn't really matter, as long as I can call it to mind. Or in a different situation, I might have 15 mins spare before a meeting. At this stage, I don't care what umbrella I'm working on, I want a task that I know can be done in this time frame. Ideally my task management system can be used to easily find something from ANY work size that I can action in this time frame.
The other practical times when I find myself thinking about is worksizing is using Asana (company wide task management tool) - is what I'm creating a project, a task, or a task with lots of subtasks? A task within a project or just a task on my personal to-do list? I'm currently just figuring it out intuitively, but it would be interesting to see if there's any system I can come up with based on work sizing to make it more intuitive (and prevent mis-sizing/styling!)
Sophie, thank you so much for your stimulating thoughts! I really appreciate your engagement with the topic and the opportunity to explore your concerns more deeply. Below, I’ll address your points and offer a few more ideas to ponder.
TL;DR: On a day-to-day level, where we’re primarily focused on “task management,” the distinction between different levels of work may seem less critical. However, when managing larger efforts and long-term initiatives, recognizing layers like “project management” and “program management” becomes valuable. These layers operate on a commitment level, helping with long-term planning rather than day-to-day execution. It’s on this higher level where they prove useful as a way to manage work effectively.
Full Response:
You’re absolutely right that on a daily level, we’re always working on tasks. Whether those tasks are part of a project or a larger program might not feel particularly relevant in the moment. In what I call the “engagement layer,” it’s often enough to have a few “effort buckets” from which we draw tasks and actions to move forward. This is one reason why I moved towards the PEAKER method for organizing my PKM, where I use an “Efforts” space to capture any kind of work bucket.
To address your concerns, I’m not even myself entirely convinced that everyone needs a special vocabulary for these different work buckets. The key is whether such distinctions actually improve how we get things done. We might never directly “work on” a project; instead, we always approach them through tasks. So, labels might not matter as much as the mindset and structure behind them. On the engagement level, we may indeed get by without different types of buckets.
However, from personal experience, I find that different work unit sizes do help, especially with larger or more complex efforts. For example, why does it bother you to have “house reno” and “plant care” next to each other? This suggests there’s an intuitive reason for wanting to separate them—perhaps for mental clarity or prioritization. It might be worth exploring this further.
You mentioned that tasks and actions are your basic units of work, which aligns with my thinking. I see tasks as the “atoms” of productivity. But why separate tasks from actions? I believe it’s because, at times, tasks can become too complex to manage as a single unit. Splitting them into actions—what I call the “quantum” level—helps manage details more effectively. Not every task requires this, but when complexity increases, breaking it down can be beneficial. If you’re interested, I have an essay on this called “Discovery Outline Technique.”
Now, let’s consider bigger efforts. When planning beyond the daily level, like for a month or quarter, tasks are too small and specific—they lack the flexibility needed for long-term planning. This is where projects come in. Projects serve as umbrellas for managing larger, more complex efforts. While tasks further the project, at the project management level, we’re focused on the big picture: How many initiatives can we realistically handle this quarter? This month? This week? This pre-picking of projects helps us see which tasks to engage with daily.
Similarly, as tasks sometimes need to be managed at a more granular level, some projects are straightforward and require little management. However, for larger efforts, we might need a higher level of oversight—this is where programs come in. You can read all about programs vs. projects in my essay titled "The Ultimate Guide to Personal Program Management (PPM)". Here I just want to say: Programs allow us to think even more long-term, in half-years or years. By distinguishing programs from projects, we can more easily manage our workload on these very long time frames. For instance, I recommend having no more than two or three programs active at once, in addition to a WIP limit of seven projects. Again, how I call these biggest of efforts is less critical. For instance, I also use an emoji prefix (💥) for programs to quickly distinguish them from projects and maybe that would be enough. But the fact that I do make this distinction helps me from taking on too much stuff and end up being overwhelmed or disappointed or frustrated with myself.
This is the key: what matters here is avoiding overcommitment. On a daily level, task management helps with this. On a longer level, however, task management is useless. Projects and programs serve in their stead here.
In summary, while tasks are tasks, and their size mainly matters for fitting them into your schedule, distinguishing between tasks, projects, and programs is valuable for long-term planning. These distinctions help manage workload effectively and stay on track with larger goals. I’ve certainly reached more of my goals since implementing this approach.
Let me know your thoughts. Thanks again for engaging so deeply with this topic. I’m curious to hear how you might incorporate or adapt these ideas in your work management system.
Thanks for sharing your thoughts Dennis!
This article has kept coming to mind for me this week. I like your concept, but have not been convinced of the "why" of work sizing and coming up with specific terminology. (Well, aside from the fact that I don't want "house reno" sitting on my projects list next to "plant-care" (i.e. doing the tasks required for keeping my plants alive today).
On a practical level, I'd say worksizing is on one level irrelevant, as long as have a umbrella for the work I'm thinking about. For example, in a given week I'd usually have a general aim to make progress towards goals by taking some actionable steps in X project, Y personal program, and Z life admin area. But these work sizes, are essential fulfilling the same tasks: providing a bucket that I want my work to fall into. On the daily level, all that work is going to be down in actions and tasks (whether taking 2 mins or multiple hours/days). But perhaps worksizing is helpful in setting realistic goals about how many things will be complete within a week/month/year and how many one might be able to touch in a day/week?
On a daily level, it's useful to know the umbrellas/handles for different work AND their size: I might do some time blocking to work on X, and so whether that's a task, project, or personal program doesn't really matter, as long as I can call it to mind. Or in a different situation, I might have 15 mins spare before a meeting. At this stage, I don't care what umbrella I'm working on, I want a task that I know can be done in this time frame. Ideally my task management system can be used to easily find something from ANY work size that I can action in this time frame.
The other practical times when I find myself thinking about is worksizing is using Asana (company wide task management tool) - is what I'm creating a project, a task, or a task with lots of subtasks? A task within a project or just a task on my personal to-do list? I'm currently just figuring it out intuitively, but it would be interesting to see if there's any system I can come up with based on work sizing to make it more intuitive (and prevent mis-sizing/styling!)
Sophie, thank you so much for your stimulating thoughts! I really appreciate your engagement with the topic and the opportunity to explore your concerns more deeply. Below, I’ll address your points and offer a few more ideas to ponder.
TL;DR: On a day-to-day level, where we’re primarily focused on “task management,” the distinction between different levels of work may seem less critical. However, when managing larger efforts and long-term initiatives, recognizing layers like “project management” and “program management” becomes valuable. These layers operate on a commitment level, helping with long-term planning rather than day-to-day execution. It’s on this higher level where they prove useful as a way to manage work effectively.
Full Response:
You’re absolutely right that on a daily level, we’re always working on tasks. Whether those tasks are part of a project or a larger program might not feel particularly relevant in the moment. In what I call the “engagement layer,” it’s often enough to have a few “effort buckets” from which we draw tasks and actions to move forward. This is one reason why I moved towards the PEAKER method for organizing my PKM, where I use an “Efforts” space to capture any kind of work bucket.
To address your concerns, I’m not even myself entirely convinced that everyone needs a special vocabulary for these different work buckets. The key is whether such distinctions actually improve how we get things done. We might never directly “work on” a project; instead, we always approach them through tasks. So, labels might not matter as much as the mindset and structure behind them. On the engagement level, we may indeed get by without different types of buckets.
However, from personal experience, I find that different work unit sizes do help, especially with larger or more complex efforts. For example, why does it bother you to have “house reno” and “plant care” next to each other? This suggests there’s an intuitive reason for wanting to separate them—perhaps for mental clarity or prioritization. It might be worth exploring this further.
You mentioned that tasks and actions are your basic units of work, which aligns with my thinking. I see tasks as the “atoms” of productivity. But why separate tasks from actions? I believe it’s because, at times, tasks can become too complex to manage as a single unit. Splitting them into actions—what I call the “quantum” level—helps manage details more effectively. Not every task requires this, but when complexity increases, breaking it down can be beneficial. If you’re interested, I have an essay on this called “Discovery Outline Technique.”
Now, let’s consider bigger efforts. When planning beyond the daily level, like for a month or quarter, tasks are too small and specific—they lack the flexibility needed for long-term planning. This is where projects come in. Projects serve as umbrellas for managing larger, more complex efforts. While tasks further the project, at the project management level, we’re focused on the big picture: How many initiatives can we realistically handle this quarter? This month? This week? This pre-picking of projects helps us see which tasks to engage with daily.
Similarly, as tasks sometimes need to be managed at a more granular level, some projects are straightforward and require little management. However, for larger efforts, we might need a higher level of oversight—this is where programs come in. You can read all about programs vs. projects in my essay titled "The Ultimate Guide to Personal Program Management (PPM)". Here I just want to say: Programs allow us to think even more long-term, in half-years or years. By distinguishing programs from projects, we can more easily manage our workload on these very long time frames. For instance, I recommend having no more than two or three programs active at once, in addition to a WIP limit of seven projects. Again, how I call these biggest of efforts is less critical. For instance, I also use an emoji prefix (💥) for programs to quickly distinguish them from projects and maybe that would be enough. But the fact that I do make this distinction helps me from taking on too much stuff and end up being overwhelmed or disappointed or frustrated with myself.
This is the key: what matters here is avoiding overcommitment. On a daily level, task management helps with this. On a longer level, however, task management is useless. Projects and programs serve in their stead here.
In summary, while tasks are tasks, and their size mainly matters for fitting them into your schedule, distinguishing between tasks, projects, and programs is valuable for long-term planning. These distinctions help manage workload effectively and stay on track with larger goals. I’ve certainly reached more of my goals since implementing this approach.
Let me know your thoughts. Thanks again for engaging so deeply with this topic. I’m curious to hear how you might incorporate or adapt these ideas in your work management system.
Best,
Dennis
“Moaning the lawn,” excellent!
Wasn't intentional, but decided to keep it anyway :D