Tinkerer

Code and Climate Change. Blog about software development in ClimateTech RSS Icon


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:

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:

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.

Did you enjoy this post? Please share it!