How many concurrent projects can a senior developer handle at one time?

Question

I am trying to find sensible resource-allocation models for developers. The department will have many different projects for different external customers, so I need to make some guidelines in order to avoid people getting angry due to lack of focus, not working on things they want to, etc.

Currently I have suggestion for a model:

• Junior developers – will only work on one project at a time (reason: mainly that they are unable to control their own time use)
• Intermediate developers – will mostly work one project at a time for 50 % or more, but might be 50-50 on two projects
• Senior developers – will work at the most on 3 projects at a time; percentage can be e.g. 50 %, 30 % and 20 %.

It’s the seniors that I am worried about. As the customers might want to buy a junior-group only, I need to provide them with a mentor (senior) to make sure they have the knowledgeprogress and the aid that they need (someone with experience and knowledge about their project). A group of 5 juniors will get a senior at 50 % of the time.

The question is – can a senior handle 3 projects at a time (he will be hired with this in mind – I will not trick someone to believe that they will write code 100 % of the time and end up with 20 %), or is this too much? EDIT: The seniors I plan to use for mentors will not be expected to code at all. They will focus on mentoring and training themselves, e.g. in new and upcoming technologies.

I have a feeling that 2 projects is way better that 3? Or? What if the senior is needed 50 % on the “junior-project” and 30 % on analysis and design on another project. Can he handle one more project with the last 20 %?

(And no – time for training, coffee, etc. will not be part of the 100 %. I have already reduced the “real” amount of working hours with that in mind).

Answer 1

Software development isn't like assembling a happy meal. Why would expose your customers to your pay grades? Why not assign the best team for the job and communicate that to your customers?

As to your specific question, I think it is unwise to have people working on more than one thing at once; projects can pull people in one direction or another and a balance of "50/50" or "33/33/33" will never occur in reality. The problem projects or the pushy managers will get 100% of the resources they want.

You may instead want to focus on when certain talent is needed on a project. Certainly, during the tail end of implementation and testing you will not need your senior people. But, you will absolutely need them during analysis, design and initial implementation.

Answer 2

It depends a lot on the person. Knowing the nature of software projects, the shit WILL hit the fan sooner or later, and when all three of a senior's projects are turning sour at the same time, and three teams of juniors are yelling for guidance, how will you help your senior cope?

Answer 3

I would suggest that no people who are really involved in a project should be on more than 2 at the same time. Anything more than that and you get a serious drop in the quality and quantity of work.

Saying that a neat trick which works for us is to have seniors on multiple projects but acting as mentors/consultants. They help other people out, review their code, research solution for the bottlenecks, participate in spikes and so forth. They are tremendously useful this way but their participation is not counted towards the team velocity and they're outside of the project team proper.

P.S. It also helps to keep senior people from being bored.

P.P.S. A group of junior-only people is a sure recipe for disaster. You need to get at least one senior working full time on each such project.

Answer 4

How many tasks someone can handle has todo with his discipline and job motivation and not with the programming skill.

He can only work on one project at the very moment. Switiching the project makes you loose the context, and this problem happens with every human beeing. Also with senior developers.

Answer 5

This really depeneds, if you want the highest quality in the least amount of time then the answer is one.

From your post it seems that speed of delivery or quality isn't the top priority but learning is quite high on the list, and in that case a senior developer can help and mentor Junior devs in multiple projects. This is usually the tradeoff that is made since it a effective way to "grow" the organization just make sure that the senior dev know's that his role is one of teacher and mentor (as well as peer) and not that of code-monkey extraordinare. It will help him immensly in aligning his priorites.

Answer 6

I find that I can be deeply involved with just one project at a time. I can have meetings and conversations with a half-dozen projects where someone else is actually responsible for delivery.

I can mentor and coach 5-10 other projects without any problem at all. Depends on the depth of involvement.

But when I'm responsible for the work product, I have to focus on just that.

Answer 7

There is a quote that says that 9 women can't produce a baby in one month.

I think this applies here. If a developer is splitting his time 50/50 over two projects, could the projects be scheduled so that the developer works 100% on one and then when he's finished works 100% on the second one?

You get the productivity gains from having a focused developer but the work still takes the same length of time.

Answer 8

Focusing on resource allocation touches on only one of the three aspects of a project. How many projects a senior developer can work on concurrently depends as much on the scope and schedule of a project as it does on their individual abilities. Every developer, senior or not, is going to lose time due to context-switching, as Andre Bossard says.

I don't think there's a neat formula or stock answer to your question because there are so many variables to consider for each project. I'm sure you want all your projects to be of high quality, so I encourage you to allocate resources accordingly. Make it clear to customers that trying to save costs (by requesting a junior-only team) will increase time to deliver and may reduce quality. Laying out the costs of each choice on resources, schedule, and scope so the customer can make an informed decision is the best thing you can do.

Answer 9

If your juniors lack time management skills (not unusual) they need mentoring anyway, even if they are only working on a single project. It's easy to get carried away "gold-plating" the less important modules.

Answer 10

I'd say as many as you can fit on a hard drive. Though that's subjective because you're just diving someone's time/effort up between the projects.

Answer 11

I totally agree with Ilya's answer. Switching contexts or tasks reduces productivity drastically. Joel wrote an interesting article about this phenomenon over at his web site.

Answer 12

as usual, "it depends"

• it depends on the complexity of the project; really difficult projects/problems may tend to consume the senior developers' every waking moment no matter what theoretical distribution is planned; some problems are just hard (or really really interesting)
• it depends on the senior developer - some may thrive on a mentoring-only role, others may become depressed if not allowed to code
• it also depends on the quality of the junior teams -
  • juniors that ask seniors every little question that pops into their heads ("how do i code a loop in java? why isn't my MessageBox showing up on the browser? who do i call to get the internet installed on my computer? what's my password?") are going to drain the brain of even the most patient and benevolent senior,
  • while juniors that must figure out everything for themselves will quietly let the project die while they beat their head against a typo they...just...don't...see.

In short, all senior developers are not equal (ditto for junior/intermediate), you'd better talk to each one individually and construct a compatible team for each project. What is a better strategy: giving the customer a price that's appealing, or providing a team that can do the job? The perception that all programmers are interchangable is a huge part of the offshoring problem in the USA, but if you package up a bunch of juniors at a bargain you are continuing that perception, and probably defeating your stated purpose. Better to do the job right, or not at all, for long-term viability.

Answer 13

Studies in aircraft cockpit design indicate that people can handle 5 + or - 2 tasks at once. Ideally you need to keep it below 5 to keep the risk of the pilot loosing his grip on the situation. I think this principle translates well into everything from GUI design to task management in other jobs. I believe the trick for your problem is to try and keep track of how many tasks the senior developers are trying to manage. On some more complex projects a senior developer could be completely consumed by that one project, where with multiple smaller simpler projects you might get away with 3+ at once.