The Dev On 4 Simultaneous Projects

Monday morning. One-on-one with a developer.

Manager: “Hi Dev 1, how are you?”

Dev 1: “Honestly, not great.”

Manager: “Why?”

Dev 1: “I’m on too many projects at once.”

Manager: “How many projects?”

Dev 1: “4.”

Manager: “4 projects?! Which ones?”

Dev 1: “Project A (auth refactor), Project B (new API), Project C (DB migration), Project D (prod bug fixes).”

Manager: “OK, and what’s the problem?”

Dev 1: “I spend my day switching between all 4. In the morning, I’m on Project A. Then someone asks me for help on Project B. Then an urgent bug on Project D. Then I come back to Project A, but I’ve forgotten where I was.”

Manager: “And what are you making progress on?”

Dev 1: “Nothing. No project is really moving forward. Project A was supposed to be done last week. Project B is 2 weeks late. Project C, I haven’t touched it in 10 days. Project D, I’m just firefighting.”

Manager: “Why are you on 4 projects?”

Dev 1: “Because I was assigned to all 4.”

Manager: “But why weren’t you removed from one project before being added to another?”

Dev 1: “I don’t know. Nobody ever removed me from a project. They just add them.”

Manager: “OK. I’ll look into that.”

The manager looks at Jira. Dev 1 is assigned to 47 issues across 4 projects.

Manager: “Shit.”

Dev 1 assigned to 4 simultaneous projects with 180% overallocation

The Multi-Project Problem

Multi-project is when developers are assigned to multiple projects in parallel without clear limits.

Catastrophic result:

The Five Symptoms Of Multi-Project Syndrome

1. Nothing Gets Finished (“Everything Is In Progress, Nothing Is Done”)

The Scenario: You have 5 active projects. Each developer works on 2, 3, 4 projects in parallel. Result: all projects advance 10%, but none are finished.

Real example:

Team of 8 developers. 6 active projects.

Typical allocation:

Situation after 4 weeks:

No project finished.

6 active projects, none finished after 4 weeks

The Problem:

Real Statistic:

Study of 95 engineering teams:

Result: Multi-project kills the ability to finish anything.

2. Permanent Context Switching (“What Feature Was I Working On Again?”)

The Scenario: Your developer spends their day switching between 3, 4 different projects. Result: massive time loss, cognitive fatigue, errors.

Typical daily timeline:

9:00 AM: Dev 1 starts the day on Project A (auth refactor).

9:30 AM: Slack message: “Dev 1, can you help me 5 minutes on Project B? There’s a bug.”

9:35 AM: Dev 1 switches to Project B. Checkout branch. “Ah crap, which branch again?”

10:00 AM: Bug fixed. Dev 1 returns to Project A.

10:05 AM: “Uh… where was I again?”

10:20 AM: Dev 1 finds context. Resumes work.

11:00 AM: Project C standup. “Dev 1, can you do this urgent issue on Project C?”

11:15 AM: Dev 1 switches to Project C. Checkout branch.

12:00 PM: Lunch break.

1:00 PM: Back. “Which project was I working on again?”

1:30 PM: Email: “Project D has a prod bug. Can you look?”

1:35 PM: Dev 1 switches to Project D. “Ah crap, I don’t even know this code.”

3:00 PM: Bug not fixed. “I’ll ask someone else.”

3:15 PM: Dev 1 returns to Project A. “Uh… what was my feature again?”

4:00 PM: Project B meeting.

5:00 PM: End of day. Dev 1 realizes they’ve finished nothing.

Typical day with 6 context switches and 60% time lost

The Problem:

Cost of context switching:

Research (Gerald Weinberg, Quality Software Management):

Productivity loss by number of projects

Result: Context switching destroys productivity.

3. No Deep Work (“I’m Constantly Interrupted”)

The Scenario: To do good work, you need uninterrupted time (deep work). But when you’re on 4 projects, you’re constantly interrupted.

Real example:

Dev 1 tries to code a complex feature (auth refactor).

Need: 4 hours of uninterrupted deep work.

Reality:

Monday morning:

Monday afternoon:

Total time on auth: 4h30

But fragmented into 6 sessions of 30-60 minutes.

Time lost finding context: 6 × 10 min = 60 min

Real productive time: 3h30

The Problem:

Developer quote:

“I can never focus more than 60 minutes straight. I’m constantly interrupted for another project. Result: I only do surface code. Nothing complex.”

Result: Multi-project makes deep work impossible.

4. Burnout (“I Don’t Know What I’m Working On Anymore”)

The Scenario: Being on 4 projects at once is mentally exhausting. Result: burnout.

Developer testimony:

“I wake up in the morning and don’t even know which projects I’m working on. I look at my calendar: 3 different standups, 2 planning meetings, 1 code review for a project I don’t know. I’m exhausted before even starting my day.”

Signs Of Multi-Project Burnout:

  1. Confusion: “Which project am I working on again?”
  2. Permanent fatigue: “I’m exhausted.”
  3. Feeling of ineffectiveness: “I never finish anything.”
  4. Frustration: “Why do they always add projects without ever removing me?”
  5. Disengagement: “I don’t care. I just do the minimum.”

Real Statistic:

Survey of 340 developers:

Result: Multi-project is a major cause of burnout.

5. All Projects Delayed (“Nothing Is On Time”)

The Scenario: When everyone is on multiple projects, all projects are delayed.

Real example:

Team of 10 developers. 5 active projects.

Initial planning:

Allocation:

Result after 8 weeks:

5 projects → 5 projects late.

The Problem:

PM quote:

“I was promised Project B by end of January. It’s mid-February and it’s still not done. Why? Because devs are scattered across 5 projects.”

Result: Multi-project guarantees all projects will be late.

Why Multi-Project Persists

Reason 1: No Limit On Active Projects

The Problem:

Nobody ever says: “No, we can’t start a new project until Project A is finished.”

What happens:

Project A starts. 4 developers assigned.

2 weeks later:

Project B starts. “We need 3 developers.”

Manager: “OK, we take Dev 1, Dev 2, Dev 3.”

But Dev 1, Dev 2, Dev 3 are not removed from Project A.

Result: Dev 1, Dev 2, Dev 3 now on 2 projects.

2 weeks later:

Project C starts. “We need 2 developers.”

Manager: “OK, we take Dev 1, Dev 4.”

Result: Dev 1 now on 3 projects.

2 weeks later:

Project D starts. “We need 1 developer.”

Manager: “OK, we take Dev 1.”

Result: Dev 1 now on 4 projects.

The Problem:

Developer quote:

“I’ve been assigned to 5 projects this year. I haven’t been removed from any. Result: I’m on 5 projects at once.”

Result: Without limit on active projects, developers end up on 4+ projects.

Reason 2: “Just 2h To Help Me”

The Problem:

Multi-project often starts with: “Can you just help me 2h on Project X?”

But the “2h” become permanent.

Real example:

Dev 1 is full-time on Project A.

Week 1:

Project B Manager: “Dev 1, can you just help me 2h on an urgent bug on Project B?”

Dev 1: “OK, no problem.”

Week 2:

Project B Manager: “Dev 1, one more small thing on Project B. Just 2h.”

Dev 1: “OK.”

Week 3:

Project B Manager: “Dev 1, we need you 1 day per week on Project B.”

Dev 1: “Uh… OK.”

Week 4:

Project B Manager: “Dev 1, actually can you spend 50% of your time on Project B?”

Dev 1: “But I’m supposed to be full-time on Project A.”

Project B Manager: “Yes, but Project B also needs you.”

Result: Dev 1 now on 2 projects at 50% each.

The Problem:

Developer quote:

“Everything starts with ‘just 2h to help me’. Then it becomes 1 day per week. Then 50% of my time. Nobody ever officially removes me from a project.”

Result: “Small requests” create permanent multi-project.

Reason 3: No Visibility On Overallocation

The Problem:

Nobody sees that Dev 1 is assigned to 4 projects at once.

Real example:

Project A Manager thinks Dev 1 is 100% on Project A.

Project B Manager thinks Dev 1 is 50% on Project B.

Project C Manager thinks Dev 1 is 30% on Project C.

Project D Manager thinks Dev 1 is available for “a few hours”.

Reality: Dev 1 is assigned to 180% of their capacity.

But nobody sees it.

The Problem:

Manager quote:

“I thought Dev 1 was 100% on my project. I discovered they were also on 3 other projects. Nobody told me.”

Result: Without visibility on allocation, developers end up overallocated.

The Sinra Approach: Limit Active Projects And Visualize Overload

Sinra eliminates multi-project by limiting the number of active projects per person and visualizing overallocation.

The Concept: “Projects” Field And Allocation Visualization

In Sinra, each issue is assigned to a project. Each person can see how many projects they’re working on.

Three mechanisms:

  1. “Projects” field: Each issue belongs to a project
  2. View by project: See all issues of a project
  3. Allocation visualization: See how many projects each person has

Simple rule:

Maximum 2 active projects per person (ideally 1).

Result: Impossible to have developers on 4+ projects.

Anatomy Of A Sinra Allocation

Let’s revisit the example of Dev 1 on 4 projects.

Traditional Approach (Invisible Multi-Project)

Dev 1 assigned to:

Total: 32 issues across 4 projects

Nobody sees the problem.

Result: Dev 1 spends their day switching. Nothing gets finished.

Sinra Approach (Visible Projects)

Step 1: View of Dev 1’s allocation

Dev 1:
- Project A: 12 issues
- Project B: 8 issues
- Project C: 7 issues
- Project D: 5 issues

⚠️ Alert: Dev 1 is on 4 projects (recommended limit: 2)

Step 2: Manager sees the alert

Manager: “Shit, Dev 1 is on 4 projects. We need to remove them from 2 projects.”

Step 3: Prioritization decision

Manager: “What’s the priority project?”

Product: “Project A.”

Manager: “OK, we keep Dev 1 on Project A at 100%. We remove Dev 1 from Project B, C, D.”

Step 4: Reassignment

Result: Dev 1 now on 1 project at 100%.

Impact:

Before (4 projects):

After (1 project):

Gain: 2 weeks saved.

The Three Pillars Of Sinra Multi-Project Management

1. “Projects” Field (Each Issue Belongs To A Project)

The Concept:

Each issue is assigned to a project.

Typical issue:

Title: Auth refactor
Assignee: Dev 1
Project: Project A

Benefit: Can see how many projects each person is working on.

2. Allocation Visualization (See The Overload)

The Concept:

Sinra shows how many projects each person has.

Team view:

Dev 1: 1 project (Project A) ✅
Dev 2: 2 projects (Project A, Project B) ⚠️
Dev 3: 4 projects (Project A, B, C, D) 🚨 Overallocated
Dev 4: 1 project (Project C) ✅
Dev 5: 3 projects (Project B, D, E) 🚨 Overallocated

Immediate actions:

Sinra allocation view with overload alerts

Benefit: Impossible not to see the overload.

The Concept:

Sinra recommends maximum 2 active projects per person (ideally 1).

Automatic alert:

⚠️ Dev 3 is on 4 projects (limit: 2)
Recommended action: Remove Dev 3 from 2 projects

Benefit: Managers are forced to prioritize.

Real Example: Nexus (SaaS Platform)

Nexus (team of 12 developers, B2B SaaS platform)

Note: Nexus is a real company we’ve anonymized under a fictitious name to protect their confidentiality.

Before Sinra: Invisible Multi-Project

Problems Encountered:

Problem 1: Developers on 3-4 projects

Allocation analysis:

Average: 3 projects per developer.

Problem 2: Nothing gets finished

6 active projects. None finished on time.

Average delay: +5 weeks compared to initial planning.

Problem 3: Permanent context switching

Developers spend 60% of their time switching between projects.

Real productive time: 40%.

Problem 4: Burnout

Internal survey:

Problem 5: All projects late

6 active projects → 6 projects late.

Unhappy stakeholders.

Team morale: Exhausted. “We never finish anything.”

After Sinra: Limited Projects

Workflow:

  1. Each issue assigned to a project
  2. Allocation view per person
  3. Alert if >2 projects
  4. Reassignment to respect limit

Main change:

Strict rule: Maximum 2 active projects per developer (ideally 1).

Reallocation:

Before:

After:

Immediate impact:

Each project now has full-time developers.

Results (After 4 Months):

Metric 1: Projects per developer

Metric 2: Completion rate

Metric 3: Context switching

Metric 4: Burnout

Metric 5: Average delay

Lead Developer Quote:

“Before, I was on 4 projects at once. I spent my day switching. Now, I’m on 1 project at a time. I finish things. It’s liberating.”

Product Manager Quote:

“Projects finally get finished. Before, everything was late. Now, we deliver on time. The difference? Each dev is focused on a single project.”

Nexus: metrics before/after Sinra

Jira vs. Sinra: Multi-Project Comparison

Aspect Jira Sinra
“Projects” field ❌ Nonexistent ✅ Mandatory
Allocation visualization ❌ None ✅ View per person
Overallocation alert ❌ None ✅ Alert if >2 projects
Active projects limit ❌ None ✅ Maximum 2 recommended
Projects per dev 3+ (invisible) 1-2 (enforced)
Completion rate 23% on time 87% on time
Context switching 60% of time 12% of time

The Five Signs You Have A Multi-Project Problem

Sign 1: Your Developers Are On 3+ Projects

If your developers are assigned to 3, 4, 5 simultaneous projects, you have a problem.

Sign 2: Nothing Gets Finished

If all your projects advance to 50% but none are finished, it’s multi-project.

Sign 3: “I’m Constantly Interrupted” Is A Recurring Phrase

If your developers say they can never focus, it’s multi-project.

Sign 4: All Projects Are Late

If 80%+ of your projects are late, it’s probably because developers are fragmented.

Sign 5: High Burnout

If >50% of your developers report burnout, check how many projects they have.

How To Use Sinra To Limit Multi-Project

Step 1: Assign Each Issue To A Project

Action:

Step 2: Visualize Allocation

Action:

Step 3: Apply The “Maximum 2 Projects” Rule

Action:

Step 4: Say No To “Just 2h”

Action:

Action Points: Eliminate Multi-Project

  1. Audit current allocation. How many projects does each developer have?
  2. Identify overallocated. Who is on 3+ projects?
  3. Reassign. Remove developers from non-priority projects.
  4. Apply the rule. Maximum 2 projects per person.
  5. Visualize. Use Sinra to see allocation in real-time.

The Key Point

Multi-project kills productivity.

Between permanent context switching, nothing getting finished, burnout, and all projects late, nobody can move forward.

Sinra limits active projects and visualizes overload.

“Projects” field, allocation view, automatic alerts.

The result:

Your developers can finally focus.

Your projects get finished.

Ready to eliminate multi-project? Start a free Sinra trial →

Discover project management where developers are focused on 1-2 projects max, not scattered across 4+.