Devint

Performance evaluation

Does hiring more developers to speed up delivery actually work?

Eduardo Missaka
CEO and Founder of Devint
Published · Updated · 7 min read
In this article

When delivery slips, the most common answer is to open new roles. Sometimes it works, but depending on the situation it can even make things worse, because the people who already deliver have to stop and teach the newcomer. This guide helps budget owners find out whether hiring solves the problem or just moves it somewhere else.

In short

  • Hiring more developers only speeds up delivery when the team’s limit is capacity, not priorities, dependencies, code review or technical debt.
  • Newcomers take time from the people who already deliver, so the team’s pace usually drops before it rises.
  • Brooks’s Law, from 1975, describes this effect: adding people to a late project can make it later.
  • Hiring tends to pay off when the work can be split, the team is truly at its limit and there is a process to receive the new person.
  • Before opening the role, check the bottleneck, how ready onboarding is and how much time the project still has.
  • Measuring capacity with data beats deciding by impression.

Why ‘hire more people’ is the default answer

When an important delivery slips, the reasoning seems obvious: if the team can’t keep up, it needs more people. The math on paper also seems simple: one more person, one more slice of work delivered each week.

The catch is that this math assumes two things: that the new person is productive on day one and that the work can be split at no cost. In practice, neither is usually true. The result is an expensive decision, one that takes months to undo, made on an impression of the team rather than a reading of what actually limits delivery.

Before hiring: what is the real bottleneck?

Capacity is only one of the possible causes of slow delivery, and the one that most often calls for hiring. The table below helps separate the symptom the leader sees from the likely cause.

Symptom the leader sees Likely cause Does hiring fix it?
The roadmap does not fit the timeline and the team lives at its limit, with no slack for surprises Lack of capacity It can, if the work can be split
Lots of work started, little finished Too many priorities at once No: reduce what runs in parallel
The team waits on another area, an approval or a decision Dependencies between teams No: more people lengthen the queue
Finished code sitting and waiting for review Review as a bottleneck Rarely: the limit becomes the reviewers
Every simple change takes long and breaks something else Technical debt Not on its own: newcomers inherit the same friction

The hidden cost of new hires

In 1975, Frederick Brooks published the book The Mythical Man-Month with an observation that became known as Brooks’s Law: adding people to a late software project makes it later. According to Umbrex’s summary, there are three reasons.

  • Onboarding: newcomers first consume capacity instead of adding to it. Experienced people stop to pass on context, conventions and business knowledge.
  • Communication: the possible channels between people grow faster than the team. A team of 5 has 10 possible channels; with 6, there are 15. More channels mean more alignment, more meetings and more chances for noise.
  • Work that does not split: architecture decisions, integration and complex debugging depend on a few people and happen in sequence. More people do not parallelize them.

The time until a new person delivers is not short either. In an article dated August 25, 2021, Built In reports teams that took seven to nine months to get new hires fully productive. The timeline varies a lot with the product, the documentation and the support available, but the message for decision-makers is clear: the return on a hire does not arrive next month, and the cost arrives first.

When hiring actually works

None of this means hiring is a mistake. It means hiring works better when some conditions are in place.

  • Capacity is exhausted in a sustained way, not just at a peak. The team delivers what it can, the backlog grows, and there is no review queue or waiting on other areas to explain the delay.
  • The work can be split. There are independent items in the backlog that a newcomer can pick up without depending on three colleagues.
  • The project has time ahead. The onboarding investment needs months to pay off. Cory Rylan, in an article from April 7, 2020, suggests growing the team after architecture, conventions and testing practices are established, because that shortens the ramp-up for newcomers.
  • Onboarding is prepared. Up-to-date documentation, a defined mentor and small first tasks make the curve rise sooner. Built In highlights structured onboarding, living documentation and asynchronous communication as practices that shorten that time.
  • The professional’s profile fits the need. For a task that requires little context, a targeted specialist can deliver more than a hire who has to learn the whole product.

Decision roadmap: hire, wait or fix the bottleneck

The questions below follow an order. If the answer is “no” at any step, the path changes before the role is opened.

  1. Is the team’s limit capacity? If not, fix the bottleneck first (priorities, dependencies, review or technical debt).
  2. Can the work be split? If not, more people will not speed things up. Revisit scope or architecture.
  3. Does the team have slack to teach in the coming weeks? If not, wait for the critical window to pass or consider a low-context profile.
  4. Is onboarding ready? If not, prepare documentation, a mentor and first tasks before opening the role.
  5. Were all the answers “yes”? Then hiring tends to make sense. Track the team’s pace over the following two-week cycles to see whether the curve really rose.

Frequently asked questions

Does hiring more developers speed up delivery?

Only when the team’s limit is capacity and the work can be split. If the delay comes from too many priorities, dependencies, stalled reviews or technical debt, a new person tends to lengthen the queue. In the first weeks, they also consume time from the people who already deliver, so the pace usually drops before it rises.

How long does it take a new developer to start being productive?

It depends on the product, the documentation and the support available. In an article from August 25, 2021, Built In reports teams that took seven to nine months to get a new hire fully productive. The safest path is to look at your own past hires and plan with your own timeline, not a market average.

What is Brooks’s Law?

It is the idea, formulated by Frederick Brooks in the book The Mythical Man-Month (1975), that adding people to a late software project can make it later. The reason is the cost of integrating newcomers and the growth in communication, which consume the capacity of the people who were already producing.

How do I know whether my team needs more people or less friction?

Compare what the team delivers with what it can sustain. If people are at their limit and the backlog has independent items, capacity is lacking. If there is a lot of work started and little finished, review queues or waiting on other areas, the problem is flow, and hiring will not fix it.

Does hiring close to a deadline help?

Rarely. The closer the deadline, the less time the onboarding investment has to pay off. In those cases, it usually works better to cut scope, shield the team from interruptions or bring in a specialist for a task that requires little context, instead of training someone new.

Next step

A decision is safer when capacity stops being an opinion. Devint, a performance evaluation platform for software development teams, tracks the delivery pace and time tracking dimensions of the DevScore – our scoring system – which helps separate lack of capacity from flow problems and see the effect of a hire in the following weeks. See how Devint reads your tech team’s capacity.

Sources

See the DevScore applied to your team.

Book a demo