The short answer
Count the people on your team who can review code against your product knowledge and have time to do it. Multiply by two or three. That is your realistic ceiling for augmented developers, regardless of how much work is in the backlog.
Teams routinely get this wrong in the same direction. There is pressure, the backlog is long, so five people are added to a team of three. Within a month the three are reviewing full time, shipping nothing themselves, and total output is lower than before.
What actually limits throughput
| Constraint | How to check | Typical ceiling |
|---|---|---|
| Review capacity | Who can review, and how many hours | 2-3 developers per reviewer |
| Onboarding load | Who answers questions in week one | 1-2 new people at a time |
| Work that is genuinely parallel | Can two people work without blocking | Varies by architecture |
| Environment and access | How long to first commit | Fix before scaling |
| Product decisions | Who answers what should this do | One decision-maker saturates fast |
The last row catches people out. Developers produce questions as well as code. Five new developers generate five streams of questions, and if they all route to one product owner, that person becomes the bottleneck instead.
Stagger the starts
Adding four people on the same Monday means four simultaneous onboardings, four environments to set up and four sets of the same questions. Adding one every two weeks means the first is answering the second's questions by the time the third arrives.
Staggering costs a little calendar time and saves considerably more in disruption. It also gives you a decision point: if the first engagement is not working, you find out before committing to four.
Sizing against the work, not the backlog
A long backlog is not evidence that more people would help. The question is how much of it can be worked on in parallel right now, by someone who does not yet know the system.
- List the work you would hand over in the first month.
- Remove anything needing deep product knowledge.
- Remove anything blocked on a decision nobody has made.
- Remove anything touching the same files as your team's current work.
- What is left is what an augmented developer can actually start on.
Teams often find that list is shorter than expected. That is useful information. It usually means the constraint is decisions or architecture rather than hands.
When adding people genuinely helps
- There is a well-defined workstream nobody has capacity to start
- A specific skill is missing and you do not want a permanent hire
- Load is temporary and hiring would leave you overstaffed later
- A maintenance or bug queue is consuming your senior people
- A migration or upgrade has a clear scope and an end date
What these share is a defined boundary. Augmentation works best where the work can be described well enough that someone new can pick it up without absorbing your whole product first.