I had a conversation with a client last week that I've had a hundred times before. They wanted one of our developers split across three projects. "It's only a few hours on each," they said. Sounds reasonable on paper. In reality, it never works out. And the reason it doesn't is the thing most managers consistently underestimate: every time someone switches context, you're burning real productive time that never shows up on the spreadsheet.
Here's the simple version. A developer working on one project gets roughly 6 hours of productive work in an 8-hour day. The other 2 hours are meetings, emails, transitions. That's normal.
A developer working on two projects gets roughly 4 hours of productive work per project per week. Not half of 30 hours. Less. Because every switch between projects costs 15-30 minutes of reloading context. Where was I? What was the decision we made on Tuesday? What's the current state of the branch?
A developer working on three projects gets roughly 2-3 hours of productive work per project per week. The context switching overhead eats almost a full day.
23%
average productivity loss when individuals work on two or more projects simultaneously
Source: American Psychological Association, Multitasking: Switching Costs, 2020
The maths:
- 1 project: ~30 productive hours/week
- 2 projects: ~20 productive hours/week total (not 30)
- 3 projects: ~15 productive hours/week total (not 30)
That's not a linear split. It's a degrading curve. And the degradation gets worse, not better, with complexity. Enterprise software is complex. The mental model a developer needs to hold for a single enterprise project is substantial. Asking them to hold three simultaneously is asking them to do badly at three things instead of well at one.
Why Managers Don't Believe It
Because it's invisible. The developer still looks busy. They're typing. They're in meetings. They're committing code. The output feels normal from the outside. What you can't see is the twenty minutes they spend every morning re-reading yesterday's Slack thread to remember where the conversation left off. The thirty minutes rebuilding their mental model of the database schema they haven't looked at since Tuesday. The bugs introduced because they confused a pattern from Project A with a convention in Project B.
Context switching doesn't look like wasted time. It's distributed across everything, which makes it invisible to anyone who isn't doing the work. But your people feel it, and the output shows it.
Tim Hatherley-Greene
Chief Operating Officer
What We Do About It
At RIVER, our default is one developer per project at a time. Exceptions exist - brief support requests, code reviews across projects, urgent production issues. But the default is focus.
When a client asks for split allocation, we have the conversation. We show them the maths. We explain that they're not getting 40% of a developer for 40% of the cost. They're getting maybe 25% of a developer's productive output. And that 25% is lower quality than the 100% because attention is divided.
Most clients, once they see the numbers, prefer to have the developer full-time for a shorter period rather than part-time for a longer one. The total cost is similar. The output is dramatically better.
The uncomfortable truth: every time you split a developer across projects to "maximise utilisation," you're optimising for the spreadsheet, not for the humans doing the work. Utilisation looks perfect. Productivity drops. The spreadsheet lies. Give people focus, and they'll 10x their output compared to spreading them thin.