Fractal Productivity

A Foray Into The Self-Similarity of Accomplishment

Personal productivity is surprisingly fractal.

It's "self-similar" in many ways, repeating itself on multiple levels.

Take the recurring cycles of weekly, monthly, and quarterly reviews. They sit in a "pinch-to-zoom"-relationship with each other.

Or consider the nature of rest. There’s a pause between single work sessions, work days, and workweeks (e.g., breaks, sleep, weekends).

There are many cases of what I call fractal productivity, but in this piece, I'd like to focus on the most essential one: units of work.

Let's start with some definitions.

A task is a piece of information that tells you what you have to do; it’s a reminder for a single action and the smallest unit of work we talk about.

A project is also a unit of work, albeit certainly a bigger one. It’s a stake in the ground for a certain desired outcome to be reached.

Here’s my spicy take: I think a project is not just a time-bounded set of bundled action items. A project is a zoomed-out version of a task.

Or, coming from an alternate angle, a task is a reduced-sized replica of a project. It’s a fractal representation of it.

A task is a concept we use to chunk together several connected physical movements and mental activities in order to achieve something. And we do that chiefly because this way, they become easier to manage, communicate, and reason about.

Likewise, a project is a concept that helps us group smaller steps (tasks) into a form that is easier to deal with.

So, in some strange way, a project essentially is a task. And a task essentially is a project.

This implies that we can handle both in a very similar way. We can take the principles and best practices for managing tasks and apply them equally well to projects (and vice versa).

Let's look at a concrete example.

Here are some best practices to define & manage tasks:

1. Name them precisely

2. Assign a time constraint

3. Set Priorities & limit the WIP

4. Make them appropriately small

5. Determine the execution context

6. Rephrase lingering items early

7. Beware of pseudo-manifestations

Now let's see what happens if we try to translate them to the project level:

1. Name them precisely — benefits of naming conventions definitely extend from tasks to projects: for the prior, we want to clearly describe a tangible action to occur, for projects, we shift the frame and specify a tangible outcome instead. But this difference is of a rather practical nature. Essentially, in both worlds, proper naming makes the target to be marched towards more concrete and visible; we know more precisely when the unit of work can be considered complete.

2. Assign a time constraint — while in the task world, we often leverage "due" or "do" dates, in the project- world, we apply "deadlines." But essentially, they are the same thing: by adding time constraints, we reduce perfectionism and increase planning accuracy. These dates help us identify the unnecessary steps that can be skipped and force us on the most important ones.

3. Set Priorities & limit the WIP — while for tasks, it makes sense to prioritize and limit them in number on a day level, limiting active projects on a weekly or -biweekly basis can likewise increase our output and completion rate. Just as you don't want 30 items on your to-do list for a single day, you rarely want to work on more than 7-8 active projects in a given week.

4. Make them appropriately small — In terms of tasks, this means reducing the physical actions involved; in terms of projects, it concerns reducing the number of tasks necessary to reach the desired outcome/project goal. The smaller the task/project, the less likely you will procrastinate on it and the more momentum you will gain by actually completing some of them.

5. Determine the execution context — while adding meta-information like required tools, places, people, and energy levels necessary for task completion can have a great benefit by letting you focus only on the relevant sub-set of tasks in any given moment, it is similarly beneficial to have an overview over only currently "workable" projects in front of you.

6. Rephrase lingering items early — tasks that survive the battlefield for more than a few encounters should be reevaluated. Ask: was one of the other best practices violated? We often violate rule 1 and succumb to sloppy, unclear wording. It is the same for projects: if they survive the battlefield for more than a couple of engagements, they probably should be reevaluated. Just like with tasks, rule 1 is the one most often violated. While for a task, it is often not clear enough what the very next physical action step should be, for a project, a really clear "completion state" is often the culprit.

7. Beware of pseudo-manifestations — there is a long list of pseudo tasks I identified regularly creeping into my life. Similarly, "pseudo projects" can manifest themselves and clog up your system, slow you down, and confuse you as you don't progress on them. Raising our awareness of unwanted invaders has beneficial effects on both levels.

Now, you may ask: why bother?

Isn’t this rambling about fractals just some intellectual gluttony?

Did we even say anything at all?

And if yes, what are the practical implications?

For one, a fractal view of productivity—a fractal productivity—can give us a larger vocabulary to understand more of the principles behind any property of accomplishment. It allows us to make more nuanced distinctions, which is essentially how all learning works on a conceptual level.

More importantly, if we can establish that many aspects of accomplishment have a fractal nature, we can open the field up for deeper investigation. We can deduce simple rules from what we know and create new mental models about things we don’t.

So, for instance, if we consider the idea that tasks and projects are not different but the same thing located on another level on a fractal spectrum, we can start asking questions like what happens if we make the magnitude step—from task to project—once more.

By examining how we manage projects, we could learn a great deal about how to approach big multi-project endeavors.

At this point, this area is not well addressed or even talked about in personal productivity circles. So, we will attempt exactly that in the next part of this series.

I'd be happy to hear your take on fractal productivity. Do you have other examples of fractals that are hidden in plain sight?

Let me know in the comments.