Is there a term to describe the point at which adding more developers to a software project will provide diminishing returns?

I realize that at a high level, it is more complicated that just a number of developers at which the project will be at productive capacity (ex/ state of the project, quality of the added developer), but I am trying to come up with a way to relate this to non-technical management through repetition. I'm basically looking for a term which invokes a strong mental image like "terminal velocity", except for Brook's Law.

  • 2
    I believe that point is called "Now". Seriously though, you should show them a graph, plotting the moment one/five/ten new developers are added and the effect it has on the project timeline (considering lost productivity due to existing members mentoring, new member mistakes and rework etc...)
    – Oded
    Oct 29, 2012 at 14:03
  • 14
    "Nine women giving birth to a baby in one month" is a common analogy used to explain resource vs. timeline issue to management. Oct 29, 2012 at 14:16
  • 2
    @dasblinkenlight - "But what if you have the women work in shifts?" (typical non-technical management response).
    – jfrankcarr
    Oct 29, 2012 at 15:42
  • 6
    but senior management tends to view it as aggressively negative Senior managements agenda in your case is likely two-fold: to decrease the project completion data under any means possible, and to control the developers. Any view that runs counter to their preconceived notions is going to be viewed as negative and dependening on how aggressively you attempt to "convince" them otherwise will only label you as "not a team player" Eg. Management speak for someone who cannot be controlled.
    – maple_shaft
    Oct 29, 2012 at 16:11
  • 1
    Are you (they?) concerned about - Schedule, risk or $, or a combination of these. Find out what they are most concerned about, and address why more developers won't fix that problem (and to be taken seriously, propose an alternate solution). Often it's more subtle than pure money or time schedules.
    – mattnz
    Oct 29, 2012 at 20:30

5 Answers 5


Your question includes the answer: the point of diminishing returns. This is the point where adding more resources costs more than the productive effect of these resources. That's a basic economic concept so your management is expected to know this by heart...

  • 3
    What you've described is what economists call the point of negative returns - where adding resource leaves you worse off. The point of diminishing returns is where adding more resource still increases production, but by a smaller amount. So adding resource leaves you a bit better off, but less than you might expect.
    – MarkJ
    Oct 30, 2012 at 8:27
  • @MarkJ Good point. I guess I am not necessarily looking for either diminishing or negative returns by rule. I'm just looking for the point that the lead dev/project manager would say no to more resources. Unfortunately, that is not always cut and dry.
    – smp7d
    Oct 30, 2012 at 13:11

"Adding manpower to a late software project makes it later. A man-month is a concept of a unit of work proportional to the number of people working multiplied by the time that they work; Brook's law says that this relation is a myth, and is hence the centerpiece of the book." - Source: Wiki-Mythical_Man_Month.

  • 1
    "My golf buddy, who also manages a IT consulting firm, says that he has two 'black belt' programmers who're available right now. They both have masters degrees in computer science. You should be able to bring them in without any problem, right? Maybe you'll learn something about how to schedule your time better."
    – jfrankcarr
    Oct 29, 2012 at 19:29
  • 1
    @kevincline - "I see you aren't a team player. I'm reassigning you to maintaining our 14 year old VB6 app. Here's a copy of Who Moved My Cheese? for you to read."
    – jfrankcarr
    Oct 29, 2012 at 22:06
  • 3
    "I see you aren't a team player.": I had this comment too. My answer was a comparison with soccer: A good team does not try to cram itself into 5 square meters but tries to occupy the whole field so that each player can be more effective; and the players often give the ball back and forth as needed. Working in a team means that the team members coordinate their activities but work on independent, non-overlapping areas of the project. If this is possible you can add more developers and increase the productivity.
    – Giorgio
    Oct 30, 2012 at 6:52
  • 1
    @kevin cline: Maybe this is the reason why eventually it becomes useless to add new developers to a team. Probably one should stop adding new developers if one cannot find an area that is quite independent from the rest of the project.
    – Giorgio
    Oct 30, 2012 at 15:48
  • 2
    The attitude of the team, the size of the project, how good the situation is, the experience of the new members, the current state of requirements, etc. are all important factors to consider here...
    – NoChance
    Oct 30, 2012 at 16:12

Doomed to Repeat

Poor Fred Brooks is like Cassandra from Homer's Illiad. If you read the book that the movie Troy came from, she was the one who didn't care for the (Trojan) horse. She predicts the future accurately, but no one believes her until after the prediction has happened and they have seen it for themselves.

Don't Fight Management / Passive Resistance or Careful Hiring?

My advice is that it is probably not a good day to die, and that if your manager wants you to hire more staff, do it. Suggesting some parameters like getting someone with specific experience and use of rapid screen-out technique will triple the search time and maybe you will reach your deadline before the disruptor arrives.

Minimizing the time you spend on unlikely candidates will save huge amounts of time. For example, any resume without your top three requirements in the first 1/3 of their resume gets tossed, candidates must pass a 30 minute phone screen before any onsite interviews, ignore recruiters who don't pre-screen to your needs. Other techniques abound, make sure anything you use is efficient and effective.

Controlling the Burden of New Hire Integration

If you do make the hire before your deadline and need to deal with a new employee, budget time from people who are not on the critical path to be involved in training. It is helpful to have members of your team see one, do one, show one. If you have a low to medium experience team member, it will strengthen their understanding of your processes, tool set, and code base to mentor a new hire in these areas.

Hopefully, you have some documentation, so assigning the new person to read documentation that will help them ramp up is a good short and long term investment. They should be brought into your processes gradually, and their work should be reviewed by people who can keep them from driving the project on the rocks with bold but harmful changes.

Best and Worst Assignments for New Hires

If you have a separate project or some technology development they can do to prepare for its use in a future project, that also could be a big benefit. Learning your specific tool set, doing their own local builds, unit testing, usability testing, documentation, and participation in reviews are all great candidate tasks for new hires. A new hire may have a perspective that is new and can provide valuable critical commentary about things your team learned to live with and can no longer see.

Less beneficial uses for new staff might include team meetings with managers and non-developer stakeholders, estimation, requirements elicitation and management (unless they are experts after having worked at a competitor), patents, and interviewing new candidates or otherwise helping with staffing.

Keeping Harmony in the Team, Setting Future Expectations

New hire priorities do still come into play. If you have a team that has passed through the forming, storming, norming, performing evolution, you must give the new hire your expectations for his performance and planned responsibilities within the team. You must not make the job of the new hire appear less demanding than other roles on the team. If your team is aggressively pushing toward deadlines, the new hire should have ways to demonstrate he is aggressively pushing toward integration.


I don't know of a standard term for the point of diminishing returns on manpower; since the object is to convince people, try turning a phrase instead:

  • "limits of decomposability" might be especially relevant for a medium-sized project.
  • "communications overhead barrier" evokes the classic Brook's Law for large projects.
  • "the design iteration requirements" as a fancy way of saying "if you want something that isn't crap, it will take some amount time to do it halfway right."

A reasonably close term would be the "range of elasticity": the analogy to hitting the price inelasticity region, when further reducing the price does not increase your sales, should ring a bell with management.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.