The Fallacy of Splitting Time

---

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 (~6 hours) 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?