PARA Part 6: Small-Batch Projects for Focus, Creativity, and Perspective - Forte Labs（EN）

In P.A.R.A Part I, I argued that the Project List was the lynchpin of modern productivity, serving as a dashboard of your current commitments and the bridge between actionable and reference systems.

But formulating a Project List is also one of the most difficult exercises for most people to complete. And I’m not the only one to notice. David Allen has written:

The reason it’s so hard to make a Project List is that it’s not just a matter of writing down what you’re currently working on. Hidden inside this simple exercise is a whole new paradigm for what a project even is.

What a Project List calls for are “small-batch projects.”

Here’s a definition:

Let’s take a look at each of these three elements one at a time.

P.A.R.A. implies a major change in how we define projects — making them much, much smaller.

To make it possible to dynamically flow pieces of knowledge between notebooks, it’s not enough to save the inputs in small, discrete notes. You must also make sure the outputs — the projects — are small and discrete, or else your system will get clogged up and stagnant.

This isn’t an arbitrary requirement by the way — it describes how the world is moving anyway. Everywhere we look, knowledge work is rapidly becoming more “project-based.” People, teams, and organizations come together briefly to execute projects, and then quickly disperse once it’s finished (sometimes called the Hollywood Model in reference to how films are made).

I believe the move to project-based work is a more fundamental shift than remote work, distributed teams, multi-teaming, lifestyle businesses, or digital nomadism. The atomization of work into discrete projects is the key needed to unlock the true potential of all these other trends.

But this isn’t a matter of doing the same old projects with outsourced contractors instead of full-time employees. It isn’t as simple as chopping up our typical projects into tiny pieces. Doing so without a corresponding change in mindset and methods just creates massive amounts of extra overhead work.

The fundamental nature of projects is evolving to make this type of collaboration possible. And its evolving because the environment in which they exist is itself changing.

The modern concept of a “project” was born in large, traditional companies, which are like factory farms: everything is designed for efficiency and scale. The primary threats are internal: bureaucracy, politics, cost-cutting, deprioritization, and competition for resources. To survive this environment, projects became large, bloated, meticulously planned, long-running, with vague objectives. All the things we hate about modern mega-projects are actually features they adapted to survive the endless path through the bureaucracy.

But put this fattened cow in the jungle of the digital economy, and it’ll get slaughtered. A “project” in the new economy has evolved to become a lean, agile tiger: small, adaptable, omnivorous, willing to hunt but preferring to watch for opportunities.

With project-based work, remote teams of contractors wait until the last possible moment to jump onto a project, and once they do, they optimize for speed and intensity. This requires shedding as much of the decision-making, consensus-seeking, approval-seeking, and status-updating as possible. It requires reducing the project down to the minimum essential core of productive activity.

Thus making our projects smaller is not a question of marginal improvement. It determines whether our projects survive. Whether they become good ideas that never quite see the light of day, or impactful results delivered in a steady rhythm.

The most important component of a small-batch project is its desired outcome, which describes the criteria for success. What exactly needs to happen for this project to be considered complete? This is to avoid the biggest risk one faces as a contractor — a half-dead zombie project that staggers on for months with no clear resolution. This is a far bigger risk than the project outright failing, which robs them of both the opportunity cost of pursuing other projects, and the learnings that would have come from clear success or failure.

There’s a good reason most people are tremendously resistant to writing out clear success criteria, even for their personal projects: that would be suicide in a traditional company. When you break out the 20 or 30 outcomes you’re pursuing, you become much more accountable for their progress. Instead of reporting that you’re “still pluggin’ away at Mega-Project X” for the 20th week in a row, you have to explain why “write outline” is still on your list after a whole week.

What you’re doing, in Toyota terms, is “lowering the water level” on your work commitments. This exposes the crud and the excess fat in your workweek: the excuses, the procrastination, the vagueness, the miscommunication, the lack of responsibility. You will only consider doing this if you value learning at the expense of comfort.

If you really want accountability, make a Project List exactly as I’ve recommended, and then show it to everyone who will listen. Show it to your boss, to your clients, to your direct reports, to your spouse. This takes courage, humility, and openness to hearing feedback. You’ll either gain trust as people learn they can take you at your word, or you’ll hear very quickly what isn’t working.

Defining a desired outcome is only meaningful if you also decide “by when.” It’s too easy to declare ambitious goals with a forecast of “someday.”

And again, our resistance to doing this makes complete sense in the context of traditional organizations. In a large company, putting yourself on the hook for a delivery date for a project you don’t completely control is crazy. Much better to keep everything hazy, so blame for delays can be passed around and diffused. Survival in a large company depends far more on avoiding blame than producing results.

But as we move to an economy of more-or-less free agents, accountability is devolving to the individual. No longer do you have a boss, manager, or colleagues to look over your shoulder and make sure you’re on track. No one cares if you had a productive day.

As implicit accountability fades away, you now have to replace it with explicit accountability. You have to put yourself on the hook for something. This starts with being honest with yourself about what you’ve committed to, and by when. Like any muscle, your word needs a hard surface to push up against.

One of the key tenets of P.A.R.A. is that you can manage vast amounts of information, on one condition: that you organize it by horizons of actionability, not by topic.

By staging your files according to how actionable they are (or when they’re likely to become actionable), you allow yourself to focus your attention on one horizon at a time. Paradoxically, the smaller your projects and the cleaner the edges between them, the larger the amount of information you can manage on all horizons. You can only focus on something that is distinct from its surroundings.

If everything is potentially actionable at any given time, of course you’ll experience information overload. Of course you’ll want to limit your exposure, cut down your consumption, and dial down your commitments. But information overload is not a feature of the external world. It’s not even a feature of how much information you consume. It is a function of how much you allow to occupy your attention at any given moment. By narrowing your attention to only one actionable stack most of the time, you allow the other stacks to grow exponentially larger with no impact on your attention.

But this all depends on having very clean edges between the stacks. You need to know exactly where the Projects stack begins and ends, so you’re not using precious attention to figure out that boundary on the fly.

The three components of a small-batch project — scope, outcome, and deadline — ARE the edges of your projects. They determine the exact moment when a project becomes active, and the exact moment it is considered complete. It is these moments that trigger their transfer to the Archives, to make room for more salient information.

This is much less intuitive, but clean edges are also essential for creativity. This may seem counterintuitive: haven’t we been taught that creativity requires messiness?

Consider that your collection of notes is a network — each note is a node, with the hyperlinks, tags, and common keywords forming connections between them.

There is a property of networks that is essential for new ideas to take root and thrive, known as the “small worlds” property. Instead of a perfectly even, densely interconnected global network (as in the leftmost image below), it is much healthier to have small “neighborhoods” that are distinct and separate from the wider network (as in the rightmost image below):

Think of how Facebook started: they launched first at Harvard and other elite universities, waiting until they’d built up a critical mass in these smaller networks before moving to others. If Facebook had launched globally from day one, they probably wouldn’t have succeeded. There wouldn’t have been enough connections on such a huge scale to keep people coming back.

The notes, notebooks, and stacks of P.A.R.A. are the small worlds of your knowledge network. Each note provides a little contained playground for a fledgling idea to first take flight. When it’s ready, it can expand into its own notebook, helping it attract and collect related ideas. The stacks act like seawalls preventing early ideas from being drowned out by more “important” and “urgent” notes.

The clean edges of your organizational system can increase the likelihood that your riskiest, most original, and most subtle ideas are protected and incubated to maturity.

One thing you’ll notice when you start scoping your projects smaller is that you have many more of them, and they come and go much more quickly. At first this might seem like a step backward in your productivity. You’ll be spending more time creating, titling, prioritizing, scheduling, and archiving projects.

I’ve come to understand that this is exactly the point. Increasing project turnover is an explicit goal of adopting small batches.

Think about the practice of performing a Weekly Review. We all know we should do it. We all know we would benefit from it. But most people don’t do it regularly. The truth is, unless you have small-batch projects, there’s no need. The answer to “What will I be working on this week?” is the same answer as last week.

What rapid project turnover creates is the need to review these projects on a more regular basis. You better believe that if half your active projects get completed in a given week, you’ll most certainly see the value in doing a Weekly Review to activate a new batch. This trains you in a higher level skill: project portfolio management. You become less attached to the success of any particular project — why worry about one arrow in your quiver when you command an army?

As you spend more time reviewing and planning your small-batch projects, more opportunities for strategic improvement will come to light. Operating more often from this higher perspective, you’ll start to think in terms of systems and principles, instead of being dominated by a single, massive mega-project that never seems to end.

In his wide-ranging book on the nature of satisfaction, Gregory Berns came to a startlingly simple conclusion: “I have come to understand novelty as the one thing that we all want.”

Lying at the nexus of commitment, motivation, fulfillment, curiosity, pain, and pleasure, novelty seems to be what our brains are wired for. But seeking novelty can sometimes feel at odds with productivity. We are encouraged by habit formation experts to lock down our environment and remove all uncertainty, to avoid taxing our willpower.

Small-batch projects promote a different set of habits that benefit from novelty, instead of being threatened by it. These are habits more expansive and powerful than your daily routine: constantly moving into zones of greater leverage; transferring momentum from one project to another; designing projects so they are more than the sum of their parts; timing projects to take advantage of external events. These are the dark arts of productivity. “Dark” only because so few have access to the project throughput required to practice them.

The ability to accelerate project turnover simply by reducing the size of projects gives you the ability to produce novelty on demand, for even the most boring administrative tasks. If I encounter a project I’m resistant to, I simply keep making it smaller until the reward feels more tangible than the pain. This gives me control of the drumbeat of fulfilled deadlines, which I tune to maximize my sense of self-efficacy.

This may feel like cheating. But once we realize that there is no inherent unit of work, we become free to choose the one that makes us feel like we’re making progress.

Choose wisely.