Why Project Managers should protect their teams from too many projects

Let's start by explaining why concurrency doesn't work.?

Concurrency, multithreading, or just multitasking, is the beautiful concept of doing many things at once.

And while it works great for computers with many threads, when it comes to human work, it only leads to reduced efficiency and increased work time.?

There are several reasons for this.

Humans are not naturally multi-threaded

Firstly, humans are not naturally multi-threaded. And yes, of course, you can talk and drink coffee or drive in a car and talk on the phone (on speakerphone, of course!).

I can even walk on a treadmill and type on a computer, for example, this blog, but these are things we do kind of automatically and require little or no contextual change.

By the way - according to official figures, 25% of road accidents are caused by people using their phones while driving. Realistically, the numbers could be much higher.

It's the change of context that is the key, because when it comes to writing code and moving between projects, the change of context is really big.

Below is a graph to help visualize this:

As you see, context change is a huge thing and if you want your team to deliver faster, don't throw too many tasks at them at once.

This is where the role of the project manager (or product owner) comes in, to protect the developers from acting in such a way that the team has too many projects at once.

Conclusion - slow is the new fast

Too many projects at the same time makes people inefficient because it takes a long time to change context. While this doesn't interfere with doing things that require little or no context change, it is very costly for creative processes, and programming is just such a process that requires deep concentration.

Doing more projects at once is simply a waste of time, and that's what prioritisation is for, to finish one and then start the other.

The same goes for doing more calli during the day.

It takes a long time to get back to deep work after a call, so it makes sense to reduce the number of calls or, for example what I practice, is to do them at the end of the day.

This is what prioritization is for.

If done well, will result in greater efficiency for the team and a better quality of the increments they deliver.