The Fallacy of Splitting Time

June 15th 2022

There's an illusion many people have around splitting time across projects. I see it all the time, and I often fall for it myself. Here's a simple example:

There are two projects, both deemed important by the business, and both need a UI developer. Unfortunately, only one UI developer is available. The manager has an idea though: why not just let the UI developer split his time across both projects. Sure, this will slow the pace a bit for each project, but at least they'll be moving in the right direction.

So what's wrong with this? While it's true that the UI developer should be able to contribute in some productive way to each project, what's faulty here is the hidden assumption. The manager typically expects in this scenario that each project will effectively be getting one half of a developer worth of productivity. In reality, both projects will get less than one half (and possibly much less). Here's why...

The amount produced by a developer can be calculated like this:

Productive Time = Total Time - Overhead

Total Time is the number of hours you're on the clock - say, 40 - and Overhead can be split into two pieces. The first is the Fixed Overhead - things we need to do as part of our job, like checkpoints with the boss, company meetings, etc. (see bullshit). This type of overhead just comes with the particular company we work for, and there's not much we can do about it. Assuming a Fixed Overhead of 10%, that would leave 90%, or roughly 36 hours, left over.

The other type of overhead that needs to be subtracted out is specific to the project, and so we can call this...wait for it...Project Overhead. This is the time we need to spend in order to just keep pace with the project as it's moving along, and includes things like reading emails/IMs, attending meetings (stand-ups, backlog groomings, etc.), and other basic communication and coordination necessary to understand the current state of things. And this is where the fallacy comes into play. We often forget that each project has its own overhead - work that needs to be done before we can start doing anything truly productive - and when you add all of these overhead activities up, it's not uncommon that this could sum to 15% or more of your time per project. Given the example above, this would leave the UI developer with only 60% total productivity, or 30% for each project.

And this is why each project team will get less than half of a full developer's worth of work.

Now it's important to note that Project Overhead is variable, and is primarily a function of how many people are on each project team. The larger the team, the more knowledge that needs to flow back and forth, and so the more time that's necessary to absorb this knowledge. On big teams, it could easily take 20% of your time to coordinate with your team before you can contribute something of value. And again, if you're splitting your time across two big projects, this premium would be paid twice.

The flip side, however, is that on solo projects, there is effectively no Project Overhead, and so the fallacy doesn't really apply. You can happily float back and forth between the two, because there's basically no switching cost (aside from the nominal costs of booting up your local dev environment, loading the project details into your brain, etc.). In my experience though, these types of solo missions are rare.

Finally, the problem is especially bad when a developer gets split across 3 or even more projects (which I have seen). This is pure insanity. After incurring the Project Overhead costs for each of the projects, the developer has almost no Productive Time, and basically can't get anything done. And it's not their fault.

So why do we fall for this fallacy? I think there are two reasons. First, I think it's fair to say that as a group, we developers like to get our hands dirty on lots of things. It enables us to learn more, which is something we enjoy, but also something we know is good for our career (and earning potential). And so we accept being split across multiple projects out of self interest and optimism. And full disclosure, I do this shit to myself all the time.

The second reason is that the ones making this decision for us to split our time are typically the managers, and managers aren't always tapped into the same reality that we live in. The reason, I think, is that a manager's work is Overhead (in the way that I've defined it). They keep up to speed with what people are doing and how projects are tracking, and this is incredibly valuable to the organization, but the need for them to have dedicated time to produce something is much lower than for other roles (which includes not just developers, but BAs, designers, etc.). And so because they don't require a solid chunk of Productive Time for themselves, they might forget that we do. Note: I'm just spitballing here!

In the end, I'm curious what people think. Do you agree that this is a thing? How pervasive is the strategy of splitting time across projects? Do we generally understand the effects on productivity? And are there other things at play that reduce productivity when splitting across projects?

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (2)
June 20, 2022
This is amazing and I couldn't agree more. Matter of fact it kinda join the work I did on my PhD thesis about providing ways to automate all the overhead (or at least keep the devs out of it) and then increase the productive time.

Which make me wonder, there should be a clear distinction also between the project overhead and a specific collaborative task overhead.
Thanks! I would be very curious to see your PhD thesis, if you wanted to share the link.

Interesting thought about further distinguishing overhead.
June 28, 2022
Hi Ben,

I've recently found myself on the receiving end of the 3 project insanity (while providing support for 2 more projects) all within one quarter... Yikes.

It was my first meaningful quarter in a new company and to be honest the first time I've been thrown into such a situation. It (now predictably) didn't pan out great. So I'm wondering what your tips are for devs that are being pushed into the split work fallacy?

I consider myself more experienced now because of the last quarter so I feel I can "fight back" such pressure with reason. But would be great to hear your approach on pushing back. Thanks!
Thanks Neb!

One thing I've seen developers do is to keep track of their meeting load, and then show it to their managers. (Actually, this one developer I knew used to put it up on his whiteboard in his office...back when people used to actually *go* to work - haha). Anyway, I thought this was a pretty simple/elegant solution for communicating how much "overhead" he had (although of course there are tasks in the "overhead" bucket outside of meetings). If your manager was aware that your weekly meeting load was, say, 15 or 20 wouldn't be a big leap to see that productivity will be affected.

If you can't avoid splitting across projects, in my experience it's better to set expectations and boundaries with the different teams, and if you can, carve out big buckets of time that you work on the different projects. For example, Monday and Tuesday for project #1, Wednesday and Thursday for project #2, and Friday for project #3. This at least reduces the real-time context switching that is such a productivity killer (and, for me at least, stresser). In consulting, this strategy has worked way better for me than trying to juggle multiple projects all day, every day.

Anyway, thanks for the comment and good luck!