How to Manage Multiple Projects

The problem is switching, not volume

Someone managing three projects doesn't have three times the work of someone managing one. The tasks themselves usually scale in a fairly linear way. What doesn't scale linearly is the cost of moving between them: reloading context on Project B after two hours on Project A, re-establishing what mattered, what was blocked, and what was said in yesterday's message that you now need to answer. That reload happens every single switch, and it's real time, not a rounding error.

The second thing that doesn't scale linearly is capacity contention. The designer you need for Project A's launch is very often the same designer Project C needs for its review, in the same week. Running one project, that collision can't exist. Running several, it's the default state unless someone is actively watching for it.

A practical approach

Keep one queue, not N boards. If checking on everything requires opening three different tools or tabs, the switching tax is being paid before any actual work starts. A single ranked list across all active projects, even a simple one, beats a perfect board per project that nobody can see next to the others.

Batch by type of work, not strictly by project. If three projects each need a round of email replies, doing all the email in one block costs less than interleaving it with deep work three separate times. Group by the kind of attention a task needs before you group by which project it belongs to.

Rank across projects, not within each one. A priority list that only ranks tasks inside Project A tells you nothing about whether Project A's number-one task matters more than Project B's number-three. Somebody has to make that call explicitly, in writing, or it gets made implicitly by whoever emailed most recently.

Triage once a week, across everything at once. Look at all active projects together, not project by project on different days. This is the only point where a genuine capacity collision, the same person needed in two places the same week, actually becomes visible before it becomes a crisis.

Keep an explicit "not this week" list. Saying no to a project's request isn't a failure of that project; it's the mechanism that keeps the other projects honest. A list that everyone can see is a far better no than silence.

What the switching tax looks like in practice

Someone splitting a day evenly across three projects doesn't get three even blocks of productive time out of it. They get three blocks minus a reload cost at the start of each one: rereading the last few messages, remembering what was actually decided, checking what changed since they last looked. Ten or fifteen minutes per switch is a common estimate, and across six switches in a day that's an hour gone before any real task work happens, with nothing to show for it on any project's board.

The fix isn't fewer projects, which usually isn't a choice available to the person doing the juggling. It's fewer switches. Grouping same-type work, protecting longer unbroken blocks, and triaging across all projects once rather than continuously all cut the number of reloads without touching the amount of work actually done.

Self-check

• Can you list every project with a live deadline this month without opening more than one tool?
• If two projects need the same person the same week, would you find out before or after both commitments were made?
• Do you know, right now, which single task across all your projects matters most today?
• Is there a visible "not this week" list, or does everything simply queue up unspoken?
• Do your status updates take less time to produce than the work they're describing?

Where a tool helps, specifically

The part software genuinely helps with here is collapsing many views into one, honestly, not automating the judgement calls about priority. ShipSprint opens to a single "my day" screen regardless of how many projects someone is on: today's items across all of them in one queue, a one-tap time log next to each, and one tap to flag being blocked instead of a separate message per project. For someone watching several projects at once specifically, the owner command center answers "where are we?" across every team in a single view, with a Monday digest, instead of requiring a status meeting per project to reconstruct the same answer by hand.