4 Rules of Thumb for Project Management as an Individual Contributor

As an individual contributor, particularly in software development, managing multiple projects and tasks is a significant part of the job. The wrong approach can leave you feeling worn down and unproductive, while a better approach might result in excellent productivity and momentum.

Projects and tasks

Let’s first talk about the difference between projects and tasks, at least as used in this article.

Projects are typically larger endeavors, requiring days to months to complete. Projects require a deeper understanding of the context and goals, as well as collaboration among team members. Examples include developing a new software feature, launching a marketing campaign, or implementing a company-wide process change.

Tasks are smaller, more focused units of work, spanning hours to days. Projects are made up by many tasks, with each project task requiring an overarching context to complete effectively.
However, tasks can also be standalone, requiring little context. Examples include fixing a bug, creating a report, or updating a website’s UI elements.

The cost of multiple projects

Being involved with multiple projects can be costly due to:

1. Cognitive Load: Context switching is time-consuming and mentally draining. Shifting focus between projects requires disengaging from the current task, and getting into the groove with the new project. You can’t stay in flow if you continuously switch between projects.
2. Coordination Overhead: Managing multiple projects involves coordination overhead, such as communicating updates, attending meetings, and syncing with team members. The more projects you’re involved with simultaneously, the more coordination overhead, and the less chance you’ll have to actually get any work done.

Effective work absorption rate

Projects and tasks also differ in their “effective work absorption rate”, which is a concept that I just made up. The “effective work absorption rate” of a project refers to the amount of work that can effectively put into it. This rate can vary depending on the nature of the project or task, as well as any dependencies involved.

In my experience, projects tend to follow two primary patterns in terms of work absorption:

• Burst projects: These projects have short periods of high work absorption, followed by periods where the capacity to absorb work drops significantly. Burst projects are often oriented towards design or conceptual solutions. For example, designing a website might involve an initial burst of work when creating wireframes and visual concepts, followed by a period of waiting for client feedback. These projects are most efficiently completed in bursts and often span several calendar weeks despite not necessarily taking up many working hours.
• Sustained-effort projects: These projects maintain a relatively consistent level of work absorption over time, allowing for sustained effort without significant dips. Sustained-effort projects are often more implementation-heavy. Examples of sustained-effort projects are: Creating the website you have wireframes for, implementing a reasonably well-specified feature or writing documentation for an already-existing feature. While there may still be occasional dips in work absorption (e.g., waiting for colleague feedback or PR reviews), the overall capacity for work remains relatively stable.

While design and conceptual work often lean towards being burst-heavy, and implementation projects tend to favor sustained-effort, this isn’t a strict rule. Design projects can be sustained-effort if your feedback loop is fast, and implementation projects can become bursty if the work is poorly defined or unexpected issues arise.

With these distinctions in mind, here are four rules of thumb for effectively managing your projects as an individual contributor:

1. Ensure you don’t only have burst projects
   Relying solely on burst projects can lead to periods of downtime and reduced productivity. Balancing burst projects with sustained-effort projects ensures a consistent workflow and maximizes your capacity
2. Have as few sustained-effort projects as possible, ideally only one
   Focusing on a single sustained-effort project minimizes context switching and allows you to maintain a deep understanding of the project, leading to better overall results. If you need to do multiple projects, do them sequentially - not in parallel.
3. Prioritize working on burst projects when you can
   Making the most of high work absorption periods in burst projects will lead to the project taking up less calendar time.
4. Use stand-alone tasks to fill the gaps
   Maintain productivity during periods of reduced work absorption in sustained-effort projects by filling the gap with standalone tasks.

Personally for me, the ideal setup for an individual contributor involves simultaneously managing:

• Zero, one (or maybe two if they have long periods of inactivity) burst projects
• One sustained-effort project
• A selection of small tasks to fill the gaps

I think this setup provides a nice balance between conceptual and design projects that often tend to be burst-heavy, and implementation projects that often have more characteristics of sustained-effort projects.

Of course, all of this is predicated on the fact that you have some degree of autonomy over how you prioritize your tasks. If you have a SCRUM-master breathing down your neck every morning, you might not be able to balance these projects in the manner that works best for you.