Size matters.
That’s probably my biggest discovery from a decade of delving into matters of personal performance. The size of your work and the size of the "work units" you decide to manage significantly impact your output.
I've written a decent amount about work unit sizes. I've written about anything from the tiniest of actions to the grandest quests a person could take on. In between, I've written a whole series on smart task management and another one on personal project management. And then, of course, there is also my ultimate guide on personal programs as, to date, my biggest contribution to our community.
Actions, tasks, projects, programs, aspirations—these units of work have been like a red thread running through everything I have published here on Fractal Productivity. I’ve approached them from several different perspectives and iterated many times that I am convinced they sit on a spectrum, that they are the same thing, only situated across different levels of magnification— different magnitudes or “sizes.” In other words, I have been claiming that work units are self-similar across scales. That they are a conceptual fractal.
The big question I haven’t attempted to answer so far is whether and how one can determine the size that works for a given piece of work. Put differently, can someone, from a mere description of some work to be done, know, with relative certainty, how to structure it? Can it be known where it is to be put on the spectrum of work units—whether it should be tackled as a project, a program, or simply a set of tasks? And then, going further, can it be known what is the “best” way to break that work down into actionable pieces?
Chances are that you’ve never asked these questions. I know for a fact that all the productivity systems I have analyzed and the authors behind them have, at best, scratched the very surface of even attempting to give some answers.
At the same time, I have repeatedly seen people struggling to get the size of their work items right. We continuously make things either too big or too small. We confuse tasks for actions and projects for tasks. We define macroscopic god projects so big that they drag on for ages and microscopic nanotasks so small they waste the paper they’re written on. And, in between, we create all kinds of chimeras that fit no description at all.
I’ve come to believe that knowing whether something should be an action or a task, a task or a project, a project or a program is difficult because people don't tend to think in “size classes.” Even those who preach productivity don't tend to talk about the dynamics of work units. And that’s why I found that for most people, a “task” is something very different from a “project.” People think tasks are single “action items” that live in a task manager or on a to-do list, and "projects" are somewhat bigger efforts that may involve tasks to get them done. They don’t see that tasks are but “mini projects” and projects are nothing but big tasks.
People always talk about their struggles with perfectionism and procrastination and disorientation and forgetfulness. Yet, they don’t realize that these challenges are all, at least to some extent, solvable by resizing work. If I fall for perfectionism, I can increase the size of my work units, which lets me zoom out and refocus on what matters. Perfectionism is a symptom of being stuck in the weeds and dealing with work times that are too small. In contrast, if I fall for procrastination, I need to go the opposite route and decrease the size of my work. I need to break it down into more manageable pieces that clearly and directly tell me what I must do.
In other words, I think that many of the productivity challenges we face today are work-sizing problems. If we fall into these all-too-common traps, it’s quite likely that the work size we used was inappropriate. The thing is, without realizing that work units sit on a spectrum and that we thus have to define very clear “size classes” for ourselves — a clear set of “work units” we like to deal with in the game of work — we end up confusing the most basic concepts. We create project-sized tasks and task-sized projects and then wonder why we don’t get anything done, albeit the fact that we actually do so much “management.”
The reality is that most people are limited to two or, at most, three different types of work units. A GTD practitioner, for instance, may be well-versed in "next actions" and "tasks," but he can’t see anything beyond that. Meanwhile, a PARA user may see nothing but projects, an ailment I’ve been calling project obsession. People with project management backgrounds in business may be more nuanced and know about units like work packages. However, they may fail to see the nitty gritty world of tasks and actions. So, whenever these people tackle an effort of unusual size that doesn’t fit nicely into the confines of their meager system (which, frankly, happens all the time), they struggle.
You've probably heard a thousand times that you should "break things down into manageable pieces." You may have heard just as often to "think big" or "go big or go home." But have you actually been able to act on this advice? Maybe some of the time, when things fell naturally into place, but on other occasions, you surely ended up with a bigger mess than before. I know I did for the longest time. I often micro-managed too many small things. Other times, I missed critical details because I wasn't as granular as needed. Sometimes, I pre-mapped a lot of unnecessary work and started to fill vast backlogs of things to do, which stressed me out. And more times than I can count, I ended up with “awkward sizes,” work wrongly mapped out to the narrow confines of my incomplete vocabulary.
So, “break things down” just doesn’t cut it. Deciding what constitutes a manageable and proper task, breaking down larger efforts, and determining the granularity of work units demand more careful consideration. However, this crucial dimension of work management is still continuously neglected. Most personal accomplishment solutions breeze past the intricate challenge of effectively defining work units because they don’t see the necessity or struggle to express it. This is why I have proclaimed “Work Sizing Is Trivial” as one of the five biggest false assumptions of contemporary personal productivity literature.
This isn’t surprising, though, as writing about work sizing, while seemingly trivial, is actually extremely challenging. This is exactly why I haven't written this essay any earlier and why there is a big chance that I am about to lose you at some point in the remaining part of this essay.
Why is it so hard to talk about the work sizing? To some extent, this comes down to the linguistic challenges involved: we lack proper vocabulary, a shared common language, and the exact details of each other’s worlds.1 However, the real challenge lies in the nature of the work itself. Work can usually always be broken down further, and it can be broken down in an endless amount of different ways. It can be broken down once or multiple times. It can be broken down into a few sub-parts or many. The same work can also be described from numerous perspectives. It can and will be described with very different worlds by different people, especially if they don’t share the same vocabulary.
When breaking down work, most people rely on their intuition. That’s the message we get from all the productivity authors glancing over this key aspect of managing work. And this is not even that wrong, as we will see shortly. But what happens next is problematic. We take with our personally known work units — again, these are often just “tasks” and “projects ”— and we route everything we tackle into either buckets. Everything “small” is made a task. Everything bigger becomes a project. After all, that’s all there is, right? The limits of my language are the limits of my world…
I used to press work into such a dual system for a long time. I decided whether to break something down into a task or a project purely on the practical grounds of whether I wanted to complete it now and in “one go” or drag the work over a longer time. And often, this worked. But just as often, it didn’t. I also did a fair share of “copying” others, of calling my projects what they “should” be called because others did so. And that, too, worked some of the time.
It all certainly seemed like a matter of luck. If my work naturally fit into my binary buckets, I had no problem structuring my work. Unfortunately, it didn't go well when dealing with “off-sizes.” So, at the time, I was just puzzled as to why my system sometimes worked and, at other times, failed spectacularly. Sometimes, I would define a task and crush it easily that day. Other times, I would define tasks and postpone them for weeks, only to discover that once tackled, it was just as easily completable as the other task, if not even easier. Projects were even more problematic. Some projects almost seemed to complete themselves, while others ended up never-ending stories and eventually got aborted.
One of the first things I tried to improve beyond this random success approach was to use “fix the time and flex the scope.” I tried to make all my tasks and projects fixed in size. For example, all tasks needed to be doable within an hour, and all projects needed to fit into a fortnight. Anything that entered my system that surpassed these ceiling lines had to be broken down into separate work items and approached separately. This attempt was based on the idea that our first attempts at sizing efforts are always too big and that we often bite off more than we can chew. To counteract that, according to the theory, we should simply force ourselves to go a lot smaller than what's intuitive. For instance, let’s say you are intrigued by the idea of writing a book. But you’ve never done it; in fact, you’ve never even written a long-form essay. So even though the book is the “real work,” it is what you really want to do (you don’t want to write essays); you force yourself to tackle a single long-form essay first as a kind of training wheel or “stepping stone.” In this case, you don’t do the “real work” but find a smaller (and different) piece of work that is more approachable and likely to succeed. It may overlap (e.g., the topic of the essay may be similar to that of the book or a subpart of it), but it’s not done as a part of the real work but as a separate thing.
This “go-smaller” sentiment is generally very popular these days. It swings more extreme in the current hype of “tiny” and “atomic” habits, where the idea is to make a new target behavior ridiculously small—so small that it becomes a no-brainer. Smaller things are clearer; they make what we should do next more obvious and empower us to take action. Often, we fail to make progress because what we are trying to achieve seems too daunting or is hidden in “abstract” and cryptic words. Therefore, the reasoning goes that work needs to be more “concrete.” The problem, however, is that if they are "too concrete," they lose their magic and the excitement and inspiration that drive us forward. Tiny things may help us build momentum, but they can’t help us sustain it. Writing an essay instead of a book is not the actual work; it’s not even “a part” of the work. Doing one pushup daily instead of 40 straight is not the actual work. Doing one pushup is not even 1/40 of being able to do 40 pushups straight. It’s something else entirely. The idea of going small, of course, is that the tiny somehow eventually and magically spirals up over time into something bigger. It is indeed intended just as a “stepping stone.” Sometimes, it can work out that way, but maybe it won’t. Because if we go too tiny, we risk getting too bored with the granular. We also risk getting lost somewhere along the way and losing sight of the bigger picture completely. So, going always and for everything, with the same fixed work unit, e.g., the 2-week project or the 10-second habit, is not a great way to ensure progress, especially if that means that we go with something smaller than the actual work.
After my “fix time flex scope” phase, I came across a slightly more advanced idea of sizing efforts based on one’s current skill set. Here, the idea is that if we are an expert in our field, we may get away with bigger units, but if we are a noob, we better split it up because there is so much we don’t know, and we need more “details.” If a beginner sizes his work too big, he or she gets stuck in analysis paralysis and drowns in unknown unknowns. The whole work appears too challenging, and one likely gives up. This sizing of work based on competence seemed to be another thing people did. The implication: for one person, writing an essay is a very big effort; for another, it’s business as usual and thus a smaller thing. So, the first person makes it a project, and the second turns it into a simple task. Much like with sizing based on competence, we could also factor in the novelty of the thing itself, its risks, or other potential factors. Whenever we know less, we go with smaller work items to ensure progress and the discovery of the actual work that needs to be done. But does this really help? Does it help that the same effort some of the time is a task for someone and other times it's a project for someone else even though both of the times it's the exact same thing? After all, the work didn’t change; the person executing did (as that person became more competent). Should changing ourselves change how an objective piece of work is scoped?
To some extent, I’d say yes. If I can get along with a short description of a task to get the work done, I should not try to blow it up into something bigger, like a project, if that is not really necessary. But I’d say such situations are the exception rather than the norm. More importantly, for many, this advice translates into something like “turn what comes easy into a task and what’s harder into a project,” which is not helpful at all. There are very long but easy projects and very short but hard tasks. The former would then be in what felt like a never-ending task, and the latter may become a minuscule project drowned in overhead.
So, while these two recommendations — “flex scope” and “size-by-skill” – read nicely, they are anything but clear regarding their execution. They cannot even be compared across people, so whether or not these recommendations work cannot theoretically be determined.
So, for me, the question remained: is there a right size for any given, objective piece of work? Can there even be such a thing as “a size that always works”?
After thoroughly wrestling with this question, I propose the following answer to this dilemma and the questions posed through this essay:
The size that works is always the one that is most mentally visible.
Let me expand on that a bit. I’ve previously defined mental visibility as a property of a highly accessible knowledge structure. Something is mentally visible if it is cognitively present or “top of mind” all the time or at least whenever relevant. Something like your spouse or dog's name certainly falls into this category. You can easily retrieve them from memory in, let’s say, 99% of cases. But more than that, you cannot only retrieve them from long-term memory; they seem so readily available that it feels as though they are always kept in working memory. Regarding work and work units, mental visibility thus refers to descriptions and work sizes that come to mind naturally when prompted to think about a certain piece of work.
How can one reliably find the most mentally visible size for a piece of work? Most of the time, this can be easily done by asking oneself what feels right and most natural to talk about. You could ask yourself, for instance, what keywords would come up again and again if you were trying to communicate your effort to someone else. What is the most obvious way to talk about this overall effort, and, if need be, what are the most obvious parts it falls into?
Let’s look at an example. I am currently renovating a house right down to the core. It's a huge endeavor that involves hundreds of hours of work and spans two or more years. This is much bigger than the efforts I usually tackle. So, it doesn’t naturally fit into my normal productivity system. Still, I argue that the most natural way to talk about and thus manage this endeavor is under a single handle, such as "house renovation" or even just “house.” It’s one cohesive whole; I do it all or not at all. It’s thus the most natural size. It’s how I choose to talk about this effort and how others approach me about it: “How’s the progress on the house?”.
To recap, the most mentally visible work descriptions are the most “natural” and the most “obvious” ones. They are unlikely to be forgotten, and even in the case of total amnesia, they are easily recoverable, as one would naturally end up arriving at them again. In the case of the book composition effort from above, the most mentally visible unit would be the whole book itself. In the case of the “40 pushups straight challenge,” it would be exactly that: a “40 straight pushups challenge”.
Now, mental visibility pertains to the whole and the work's overall structure, i.e., how you break it down into parts. Using the most mentally visible description as the basis for splitting it into manageable pieces has the advantage that not only the whole but also the parts are always present in your mind without any “tension” or confusion. It makes it easier to think and talk about them. As for our examples, the book project would most likely be split into chapters, or maybe “parts,” depending on the circumstances. The 40 pushups would, at least in my mind” be best split into milestones such as 10, 20, and 30 consecutive reps. So, there is some nuance here. Not everyone will spit an effort the same. And how about the house renovation? Well, that could be broken down into smaller parts like "teardown," "new roof," "buildup," and "garden," and then even further. Note that even if you are the only person involved in an effort, breaking things down into components that can be easily talked about is highly preferable as future you is not present you is not past you. In other words, it helps you communicate either with others or yourself over time.
Note that in all the above cases — the book, the 40 pushups, the renovation — it wouldn't be natural to only talk about the parts in isolation. Whenever I talk about the "new roof," it is always in light of the renovation, as there wouldn’t be a "new roof" effort if it weren't for the bigger thing. Of course, if I was already living in that house and would tackle only the renovation of the roof or maybe the heating system in isolation, then, of course, it would be natural to talk about this effort as such, and it would not naturally run under any bigger “umbrella” effort. But as for my current situation, the renovation is the “master” label and the most natural size. Thus, it is the size that is most mentally visible. That means my effort is most naturally called after and managed under a single work unit called "house renovation," as this is the size that works best to talk about it and thus also to reason about it.
Now, maybe all the above reasoning seems overly self-evident to you. After all, what alternatives are there in discussing a house renovation or a book as a whole?
Note, however, that with the “go-smaller” and “size by skill” approach I mentioned earlier, you wouldn’t necessarily end up here, especially if all you knew were the work units "tasks" and "projects." If you opted for the fixed-scope approach, you would need to split the two-year renovation effort into up to 56 separate projects, which is obviously ridiculous!? As for the skill-based approach, knowing only about tasks and projects, you’d end up making it a project. The colloquial use of the term “project” is so vague it even sounds very accurate. It is perfectly acceptable to talk about a house renovation project. Note, however, that if you tell someone that you are working on a “house renovation project,” that person will not learn anything about the size of your endeavor. Maybe you are only renovating a few rooms, only the outside, or slowly renovating the whole while living there. In fact, it would be quite unlikely that someone would figure that you are renovating the thing down to its core over two years without living in it. That’s not our natural conclusion from a term like “project” employed in a personal context. So, if you wanted to convey size, you’d likely end up qualifying the term and say something like “mammoth project” or “megaproject.” That is, however, just a minor hiccup. The real problem is that you now have to put the house renovation on your project list and see it sit right next to ridiculously small things like "clear out the kitchen."2 You end up using the same term and concept—the project—to refer to both a relatively tiny effort that isn't exhausting and will only take a few hours at most, with no (monetary) risks whatsoever, and something as monumental, exhausting, and potentially risky as a core renovation of a house.
Why is that a problem? After all, we can call these things "efforts" and be fine with it. Isn’t a “project” simply a temporary “effort” of some sort? Well, in colloquial speech, this is very much true. But practically speaking, if that’s your definition of "project," I’d say your definition is pretty much useless. For one, in that case, your definition should also include tasks as they, too, are temporary efforts, which means you end up with but one size category in your repertoire. If, in your mind, the term “project” is nothing but a synonym for "effort" or "endeavor," then you can’t draw any practical value from that term. You can just as well forget about it. A “house renovation project” is simply a “house renovation effort” — and it could be any size. In other words, you have no clear terms and concepts, no clear mental models of work structures at all. While you will quickly recognize the words "task" and "project" when you read them somewhere, in your mind, they will map to no more than "effort," which will often make you gloss over what an author is trying to tell you.
So, long story short: if you aren’t clear about work unit sizes, you have no real boundaries between them, and with blurred lines, you will end up mis-sizing things. Even if you have clear boundaries between tasks and projects and are inclined to structure your work in a way that naturally wants to go and is mentally visible, your accomplishment system just isn’t powerful enough to handle it. Again, you’ll end up mis-sizing things, bringing upon you all kinds of ailments, among which perfectionism and procrastination and disorientation a just the most popular ones.3
In contrast, if you have any conception of "work units" in your mind, then you must have at least a vague notion of your usual size classes. How “big” one of your tasks usually is. How “big” your projects usually are. And if that is the case, the "house renovation" poses a serious challenge. Because it's way bigger than the usual efforts you call "projects.” It doesn’t fit into your system.
So, to recap, if you do have a concrete size class for your projects (how big and long they usually are), you can't fit the house renovation inside. But you also can't break the renovation down into several small, sequenced projects, as that would not result in a mentally visible and "natural" way to talk about the effort. So, the only way out is to use a richer set of work units in your system. In this case, we need a class size above the project, such as the "personal program." The most natural thing to do here would be to turn our house renovation into a program and break it down into projects that contain tasks. With this, order and concepts are restored.
And how can the program best be divided into projects, and how can projects be divided into tasks? Again, the answer is to think about how to break things down into their most "natural" components.4 In my case, I ended up with something along the lines of "clear-out", "teardown," "new roof", "buildup," and "garden." These were the most obvious parts of the overall effort that came to mind; they are also the terms everyone involved understands. Work then gets broken down the same way again and again as needed.
Now, if you have followed me so far, you may have noticed that with this process, you likely end up with a hierarchy of natural and mentally visible pieces of work on one side. On the other hand, you have a clear set of your personal work units, which, in my case, are actions, tasks, projects, programs, and arcs of aspiration. But these two worlds may not neatly fit together. For instance, my "project" work units are something rather small; for me, projects are a matter of weeks, and except for maybe the "new roof," several of the parts of the renovation program couldn’t be modeled as single projects in my setup. So, these parts did neither fit my program level (they are too small for that) nor my project level (too big for that). But they were the most natural components of the effort and thus valuable. What does one do here?
The answer is to bridge the gap by introducing temporary work units in between. In my case, I represented some parts as a novel unit between project and program that will only exist for the duration of the program. These intermediary units are a basis for talking and reasoning about the effort in a structured way. And they are as well a basis for spawning new projects. For instance, as of writing this, we are working on "buildup." One project that spawned from this was "facade," another one was "new kitchen." For these two projects, "buildup" was the generator. But “buildup” itself is neither a project nor a program. It’s an intermediate scaffolding that doesn't coincide with any of my usual work unit sizes. It’s a temporary and nameless work unit, a “helper construct” to break the house renovation down naturally and then map it nicely into my productivity setup.
And why do I do this? Because I want to follow the most natural effort structure to talk about because this makes it the most mentally visible, and that makes it the size that works. In my system, “buildup” doesn’t have the same prominence as projects and programs and only exists temporarily. Still, it is a visible component during the house renovation effort nonetheless. I used the term “buildup” in quarterly goal-setting sessions, planning documents, and outlines. The lesson here is that natural components should take precedence over the available units in your system, i.e., you adapt your system to accommodate the natural hierarchy in the work that wants to be managed, not the other way around.
So, the general idea should be starting to get clearer: start from and break down work based on what is most mentally visible (by deducing what is most naturally talked about) and then bridge this work onto your personal and permanent work units by creating temporary helper units in between, if need be.
What if things are more complicated? What if we don't know how to break something down further? Or if we don't define our work by ourselves?
As you surely notice, my above examples have been very simple. While not many ever take on a renovation project of this size, it is still a relatable example. But that's mostly not the case with our bread-and-butter work. In my profession, things are rather different from the examples above. Most of the work is given to me; the scope and "work to be done" are pre-defined (if often ill-defined) when I receive it. Sometimes, the work is even broken down into smaller “acceptance criteria” for me. Even though this is so, in most cases, my work starts as a black box—the first step of any work item I tackle usually involves a lot of reading and delving, researching and crunching. Until I get a good grasp of the problem or requirement, I can't even start to rename, rescope, or refractor it (break it down). Even once I understand the work to be done, there often are no immediately obvious natural ways to break it down. "Define & break down work based on what's mentally visible," as presented above, is a top-down approach that only works if we have a good grasp of what the work entails. Here, we need to do the opposite: come from the bottom. We discover much of our work along the way while working at it and must map it out as we go.
However, I recommend the same approach for this situation: find the most mentally visible components, the most natural ones to talk about. Only, this time, you start by defining the smallest units, such as the next action items and tasks you discover along the way. And as your “work to be done” grows and becomes clearer, instead of breaking it down into natural parts, you instead find the most natural clusters within the work. I often use my Discovery Outline Technique for this. Here, we start with a flat outline that, over time, gets more nested and iterated on. When we have the whole picture, much of the work may already be done. Or maybe it won't. But in any case, we move with the pre-defined units in our repertoire that come naturally to us and try to find work items that are natural to discuss.
So, adding this bottom-up approach to the mix, we can refine our general approach a bit: scope (declare, break down, and cluster) work based on mental visibility, then bridge it into your permanent work scopes (work units you like to work with).
This process is an act of what I call work unit scoping or work scoping, for short.
Work Scoping has two main tenants: First, it is a "declarative" approach, meaning it moves what to work on — effectiveness — instead of how to work — efficiency — to the center of one’s attention. Second, it embraces the fractal nature of reality by ensuring that the work units we deal with always remain of a constant size. This allows us to treat them the same or at least similar in all cases.
With work scoping, the size classes that come most naturally to you will be called your permanent "work scopes." Again, as an example, my permanent scopes are that of actions, tasks, projects, programs, and arcs of aspiration. I have a very clear definition of each of these terms and know their typical “size.” They are not just “efforts” in my head. I fledged out this setup over the years. It suits my natural work style, and it comes naturally to me. So whatever effort I take on gets managed through and with these size classes. Occasionally, I need to add temporary work scopes to the mix, as I showed with the scaffolding items "teardown" and "buildup" during my house renovation program. At work, I have somewhat different and a few more scopes that are only added to the mix in that context. So, the overall setup is somewhat flexible and doesn’t need to be fixed throughout all of live’s domains. However, overall, it is important to have a rather clear picture of the sizes one personally likes to work with. The most important thing is that these size classes remain constant. They should always contain items of roughly the same size.5
Work scoping as a practice ensures that the most natural way to talk about an item of work lands in the right size class and isn't bent to make it work. It is a somewhat "idealized" concept that does not usually fully match exactly the messy reality we live in. What is important is not to follow the rules 100% all the time but to be aware of them to spot size violations more easily. Constant work unit sizes help you to get clear, unstuck, and generally more productive. They help you avoid the "miss-sizing" and misrepresenting of work and, thus, avoid all the kinds of productivity issues mentioned several times throughout this essay.
So, let us now draw it all together and come back to the questions raised in the very beginning:
Is there a way to know the size that works for a given piece of work?
Can someone, from a mere description of some work to be done, know, with relative certainty, how to structure it?
Can it be known where it is to be put on the spectrum of work units—whether it should be tackled as a project, a program, or simply a set of tasks?
And then, going further, can it be known what is the “best” way to break that work down into actionable pieces?
My answer to these questions is YES, given three prerequisites:
one has learned to model work based on mental visibility
one has crystal clear, disjunctive, and permanent personal work units defined
one can bridge 1&2 through work scoping (e.g., by using temp. work scopes)
Modeling work based on mental visibility takes some practice. Still, it gets easier with the proxy of answering what is “most easily talked about,” especially in cases where we can work top-down (where a lot is known about the work to be done). In bottom-up scenarios (where little is known about the work to be done), we must first discover the right words, which is usually a bit trickier. In either case, however, we must bridge these natural work themes to the sizes we would like to handle work with. For this, a personal setup of constant work units is needed. Arriving at these “permanent work scope” takes time and experimentation, but getting there will sharpen one’s intuition of the shapes and sizes work can take. Matching between the natural structure of work and one's work scope is probably the key element and maybe the hardest to master. But I deem it necessary to repeatedly find the "size that works" for all the kinds of work tackled over a lifetime.
I know this piece was more abstract and maybe hard to follow. This is so partially because of the general linguistic challenge involved. But to some extent, it is also that I have personally not yet fully reached the final consensus on how it all works and is best put into words. This piece was just my first foray into an attempt at an answer. Whether I succeeded or not, you have to decide for yourself.
Anyway, thanks for reading. Any feedback is highly welcome.
As a self-help sub-genre, we lack proper vocabulary, so we often rely on common speech and colloquial usage of words. Worse yet, our vocabulary is downright confusing. Except maybe for the term "action," which is generally seen as something rather small, most of the terms we use to describe work are vague, especially in terms of size. The term "task" is commonly used for a transactional item on a to-do list ("Clean car") but can just as well be used to refer to something big and special ("Your task is to save the nation"). The same goes for "project". For some, a project is everything that consists of at least two actions. Others define it in work sessions or weeks. In many cases, it refers to something much bigger, lasting many months or even longer. Over the last months and years, I have tried introducing a vital and coherent vocabulary. However, many readers won't be familiar with it, so they might have very different notions of some terms. So, I have to repeat and repeat and repeat my definitions in order to get an exact message across.
Another tricky aspect of talking about size is that talking about "work” is, in general, very difficult. If I were to confine myself to a single profession like software engineering, I could use a more precise language, but by doing so, I would again lose most of my readers, as they aren’t engineers. This is why, as personal productivity authors, we must resort to something everyone is familiar with when trying to come up with proper examples. Something taken out of everyday situations. Cleaning the garage, moaning the lawn, and bringing out the trash are things that everyone understands. But this type of work is too trivial and has too little substance to prove any big points. Every “work” makes for easier writing, but it is hardly translatable to the much more nuanced knowledge work we do.
Then there is the fact that as knowledge workers, every one of us probably has a somewhat unique job. So, even if all of my readers were in the same kind of business, they were to understand all the jargon needed to make very relevant and concrete examples. Even if they had similar mental models, I would still need to generalize my examples, as no one works my exact job at my particular company. The only way this barrier would disappear is if I were to mentor someone within my company one-on-one. Otherwise, I always have to ensure that many readers with different backgrounds and circumstances understand what I’m talking about.
In general, Getting Things Done (GTD) leads to unnatural communication. While the “physical next actions” are superb to talk about, GTD “projects” are where the problems arise. In GTD, a project is anything consisting of multiple actions. When something involves two things to do — two next actions — it turns into a project. This often makes projects rather tiny and awkward in scope. It also makes projects very unclear in size — from a few minutes up to many weeks or even longer — which weakens this higher-order unit. It would be impossible to model my house renovation program with GTD straightforwardly and without extending the method somehow.
Granted, the "sizeless" project approach has one advantage: you’ll have no problem talking about efforts of any magnitude. Tackling the book effort or the house renovation poses no challenge for you. You create new project buckets and be done with it. However, I'd argue that, in that case, you are not managing these efforts at all. You draw no practical value from turning something into a “project.” You could just as well call them tasks, and your tasks become the sub-tasks. There’d be no difference at all.
It would be best if you didn't try, for instance, to break down work into parts of "equal size” artificially; you don’t need to end up with equally sized "6-month renovation projects" so that they neatly fit your calendar. There most likely won’t be a useful and natural label for such 6-month periods, and calling them "phase 1", "phase 2", "phase 3", etc. would neither be descriptive nor motivating. Breaking down an effort into similar-sized parts sometimes works by chance, like when writing a book with roughly the same-sized chapters, which makes for a natural way to divide a book composition effort. But in most cases, such as for the house renovation, this doesn’t work. So it’s best if you don’t try to impose such artificial divisions and instead go with what feels most natural
Note that when I say “size,” this is usually largely based on a temporal dimension, but it can also factor in other factors, such as the effort or risk involved. How you define your classes is largely based on how you prefer to work. However, I found time to be the most important and easiest way to divide work. Note: I mean “time on task,” not “calendar time.”
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!)
“Moaning the lawn,” excellent!