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…

“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.

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.