We Need To Go Meta!
The Power of Higher-Order Projects
This is the fourth issue of fractal productivity. Here are the preceding installments:
Fractal Productivity — A foray into the self-similarity of Accomplishment
Discovering the Personal Program — In search for a missing piece in contemporary productivity jargon
The Personal Program — Real life example of a rare animal
Haven't read these? I recommend you do, as they set the stage for what’s to come.
Throughout this series, I have already given you definitions and examples for my concept of programs. If you are still not quite with me, here are two more alternatives to view them.
One is to call them meta projects. "Meta" in the sense that they sit one layer above projects. So this is like saying that a project sits above tasks.
Another way would be to say that a program is a higher-order project. "Higher-order" in the sense that it's a project for managing projects. This is like saying a project is "a task for managing tasks." So, this nicely highlights its fractal nature.
No matter which definition you choose. The main lesson is this: in personal productivity, we usually only think about either tasks or projects. Most of the time, this is all we need. But it's indisputable that there is at least one more work unit that sits above those. Whether we realize it or not, this unit of work manifests itself in our lives, albeit only occasionally.
Lacking the "program" as a concept can have some major implications. It may increase uncertainty and yield fuzzy commitments. It may hinder communication with others and even lead you to question your whole productivity system.
Now, I understand if you still have some reservations.
Can't we just "break down a big project into smaller ones" instead of introducing a new unit of work?
Can't we say "project with sub-projects" — do we really need a new term for that?
Can't we skip it altogether and try to just always work on small related projects?
So, in this piece, I will address them by laying out seven major advantages of using programs:
Programs make commitments more explicit
Programs put projects in perspective
Programs elicit the true nature of work
Programs ease agile organization
Programs allow you to "go all-in"...
...while fostering the humility to "think small"
Programs may allow for better communication
Let's explore each of them in more depth...
1 | Programs make commitments more explicit
Introducing a concept with a crispy new term can act as a forcing function. As soon as you are aware of its existence, you have to ask yourself whether a given work package is a project or a program. It can't be both. So they force you to reason about it and have to make a decision. That in itself is valuable. But if you identify something as a program, you won't commit to it if you are already underwater. And if you do decide to kick off a program, it's a deliberate choice. So you'll be less likely to over-commit on other things. You start with the awareness that you probably will not be able to "make room for" much else during that time. So the program not only forces you to choose. It also functions as a commitment device. It makes it easier to say »No« to fancy rabbit holes along the way. The same applies to active projects that slowly morph into something bigger. As soon as you realize that your project has become a program, you can act on it.
2 | Programs put projects in perspective
If both "buy new headphones" and "write a book" are projects, taking on such a unit of work is totally ambiguous. By adding the program as a "big" endeavor right in line with projects ("medium") and tasks ("small"), you crystallize your thinking. You end up with a project portfolio more homogeneous in size. You stop having "sub-sub-projects" bigger than full-fledged standalone projects. You won't have to vacillate between extremes when managing and reasoning about your projects. Your estimations may improve. Just like checking off tasks can increase your momentum throughout the day, finishing more small projects can actually increase your momentum and confidence throughout the week.
3 | Programs elicit the true nature of work
When you identify something as a project, you put it in the same mental bucket. No matter its size. And if you have just two units of work in your repertoire (tasks and projects), this blinds you to the true nature of work. If you think about it, no two projects have the same scope. You will not even find two tasks of the same size. While you will continue to work mainly on the project level, you raise your "fractal awareness." It enables us to do Middle-Out planning and thinking. You can still reason top-down from Projects to Tasks, but at the same time, you can now think bottom-up from Projects to Programs. And adding one new concept, the program, does not over-complicate things. Three is a workable number to think in. But it comes with the benefit of eliciting the true nature of work.
4 | Programs ease agile organization
Our mental models inform not only how we think. They also determine how we engage with and shape our environment. For instance, we often combine tasks into a project container to ease physical access and navigation. Similarly, putting related projects under one visual umbrella can make them more manageable. While this seems like adding hard structure and hierarchy, it's actually the opposite. The container is a useful constraint. It allows us to make more (unexpected) connections between the contained items by putting them together visually. It also keeps projects more malleable because we have a bigger container that acts as a safety net. It allows us to rename and reshape the contained items more freely without the danger of losing the bigger connection. So, in a sense, the program makes us more agile.
5 | Programs allow you to "go all-in"...
Medium-intensity projects stretched out over time are a stable strategy to reach goals. Yet, some targets are not reachable with consistency alone. Think external, unchangeable deadlines, or the necessity to "overload" your brain with a topic. In such instances, slow and steady progress will not get you anywhere. Instead, you need to "Walden-pond" yourself to even unlock the possibility of reaching the goal. You need an intensive deep dive with your full attention and dedication. You need not only the output of several related projects but also the emergent synergies that arise when working on them in parallel. If you don't believe me, ask James Clear. In writing his "Atomic Habits," he relied heavily on sprints to meet publisher deadlines. That's the opposite of his habit-based approach. Or take Tiago Forte; he usually advocates projects running on the back burner. Yet, to create his flagship online course, BASB, he had to do the heaviest lift of his life! For you, it may be completing a master's thesis, planning a wedding, or going through a career transition, ... there is no denying that we face heavy workloads now and then. And the program is a powerful way to deal with them.
6 | ...while fostering the humility to "think small"
We all know that the productivity nerd is an overly ambitious creature. Too often, he bites off more than he can chew. She creates projects that are too big in scope. She lacks the necessary humility to engage in "small" efforts. That's why Point 5 may be so appealing. The concept of a program as an "all-in" heavy lift suits our egos. Funnily enough, though, while the program allows us to "go big" it has the opposite effect on the project level. Just like the environment of a project makes it easier to define small tasks, the environment of a program allows us to size projects smaller. And it allows us to do that without feeling like an underachiever. The more ambitious program goal is always there, front and center.
7 | Programs may allow for better communication
Programs may also improve communication. When it comes to cooperation and teamwork, communication is always the bottleneck. Even if you've mastered it personally, conveying knowledge to others is hard. Tacit distinctions in your head may not make it across the language barrier. Sometimes, your explanations leave others more confused. What are you referring to when you say "project"? What kind of effort are you talking about? Something with three tasks or 300? This is where the program can extend our terminology. Think about sentences like:
» That would be a program for me, not just a project. «
» I'm juggling too many things to take on a new program. «
» Sorry, I'm on a program; I'll get back to you in a few weeks. «
» How did I do it? It was only possible because I turned it into a program.«
Such phrases only make sense if people know the size category above projects. If they are, they can communicate more clearly and precisely.
I believe personal productivity to be overly fractal. The concept of tasks vs. projects vs. programs is but one example. In future posts, we will look at many more of them. But this concludes the first series on “work units.” I hope you got something out of it.
Where are you with me? Where do you disagree?
I’d be happy to hear from you in the comments.