A project is behind, so the plan is to add engineers. Three months later it is further behind, and the people who were productive before are now spending their days answering questions. This outcome is common enough to have a name, and the mechanism behind it is not mysterious. Adding people increases the supply of one thing: hours available to write code. If code writing is not what the project is short of, the extra hours have nowhere to go, and the cost of directing them lands on whoever was already the constraint.
We sell embedded engineers. That makes the following an inconvenient argument for us to make, so it is worth stating plainly: on a majority of the slow projects we are asked to staff, the first useful intervention is not more people. It is finding out what the engineers already there are waiting on.
Start by measuring waiting, not working
Take the last five tickets that reached production. For each one, mark the calendar time from the moment work started to the moment it was live, and then mark how much of that time someone was actively working on it. On a healthy team the two numbers are close. On a slow project they are not. A change with two days of work in it takes three weeks, and the difference is spent waiting for an answer, a review, a test environment, or a release window.
That gap is the diagnosis. If eighty percent of elapsed time is waiting, doubling the number of people doubles the number of things waiting. Queues get longer, not shorter, and the person everyone is waiting on now has twice as many people waiting on them.
The five constraints that adding people makes worse
Decision latency
The most common constraint we find is that engineers are blocked on questions only one person can answer, and that person has a day job. A ticket sits for six working days waiting for someone to say whether a partial shipment should generate an invoice. The work itself is an afternoon. Multiply by every ambiguous ticket and the project moves at the speed of the stakeholder's calendar.
Diagnostic question: how many open tickets are blocked on a question rather than on work, and what is the median age of those questions? Fix: give the team a decision-maker with real authority and a standing slot, not an ad hoc one. Where a decision is reversible, authorize the team to choose, record the assumption, and proceed. More engineers here simply produces more unanswered questions.
One person who reviews and merges everything
Most teams have a senior engineer who reviews the important changes, owns the release, and is also expected to deliver features. Their review queue is the throughput ceiling for the whole team. Adding developers increases the volume of code entering that queue while reducing the time that person has to work through it, because they are also the one onboarding the new hires.
Diagnostic question: what is the median time from a change being opened for review to it being merged, and what share of merges go through one person? Fix: widen review authority by area rather than seniority, agree on what actually needs a senior look, and take feature delivery off the bottleneck reviewer's plate before adding anyone to the team.
An environment only one person can operate
In a surprising number of organizations, deploys happen because one engineer runs a sequence they hold in their head, or a staging environment exists that only they can restore when it breaks. This is invisible on an org chart and decisive in practice. Every additional developer increases the frequency of deploys, environment resets, and merge conflicts, all of which route through the same person.
Diagnostic question: can a developer who joined this month deploy to staging, on their own, on their first day? Fix: automate the release path and make environment provisioning repeatable before adding capacity. This is usually two to four weeks of unglamorous work and it raises the ceiling for everyone already on the team.
Architecture that prevents parallel work
Some systems cannot absorb more people because every meaningful change touches the same module. A single pricing engine, a god object, a shared database schema with no boundaries. Two engineers working in that area produce conflicts; five produce a permanent merge queue and a shared fear of touching anything. The work is not parallelizable, so parallel workers do not help.
Diagnostic question: over the last fifty commits, how many touched the same three files? Fix: carve out one seam that lets a second stream of work proceed independently, whether that is a service boundary, a module with an owned interface, or a separable workflow. Do that first, then staff the second stream. Staffing before the seam exists creates coordination cost with nothing to show for it.
Requirements too vague to build against
When the specification is a paragraph and a screenshot, engineers fill the gaps with guesses. Some guesses are wrong and are discovered in review, in testing, or in production. That rework is proportional to the number of people guessing. Adding developers to an underspecified project increases output and decreases delivered value at the same time, which is the least pleasant failure mode on this list because everyone looks busy.
Diagnostic question: what fraction of completed work has been reopened or substantially reworked in the last two months? Above roughly a quarter, the constraint is clarity. Fix: put an analyst or a product owner in front of the engineers and require that work is not started until acceptance criteria exist and someone has agreed to them.
Symptom, constraint, and the useful response
| Symptom | Real constraint | What adding people does | What to do instead |
|---|---|---|---|
| Tickets sit for days between activity | Decision latency: nobody available to answer | Creates more unanswered questions and a longer queue | Name a decision-maker with authority and a standing slot; let the team decide reversible questions |
| Work is finished but not merged | One reviewer and release owner for everything | Adds volume to the bottleneck's queue and takes their time for onboarding | Distribute review by area; remove feature work from the bottleneck reviewer |
| Deploys are scheduled around one person's availability | An environment or pipeline only one person can operate | Increases deploy demand on the same single operator | Automate the release path and environment setup before adding anyone |
| Constant merge conflicts in the same area | Architecture that serializes all change | Produces coordination cost and fear of touching the module | Create one owned seam or interface, then staff a second stream behind it |
| High rework rate; features built twice | Requirements too vague to build against | Multiplies rework in proportion to headcount | Add analysis capacity, not build capacity; require agreed acceptance criteria |
| A clearly scoped stream sitting unstarted | Genuine capacity shortage | Increases throughput, which is the point | Add people. This is the case where headcount is the right answer |
Where adding people genuinely works
Capacity is sometimes the real constraint, and when it is, adding engineers works quickly and predictably. Three conditions have to hold at once. There is a workstream that can proceed independently, with an interface or boundary that lets it be built and tested without constant negotiation. There is an owner for that stream who is not already the bottleneck for something else. And the requirements are specific enough that the work does not need daily arbitration from a stakeholder who is not available.
The second condition is the one that gets skipped. A new stream is created and assigned to the same senior engineer who already owns review, releases, and the hardest feature. The stream then runs at the speed of that person's remaining attention, which is near zero, and the conclusion drawn is that outside engineers do not work out here.
- A separable workflow (a portal, an integration, a reporting surface) with a defined boundary to the rest of the system
- A named owner with capacity, who is accountable for the stream's outcome and can answer questions the same day
- Acceptance criteria that exist before work starts and are agreed by someone who can defend them later
- An environment the new engineers can deploy to without booking time with anyone
- A review path that does not terminate in the same person for every change
A one-week diagnosis
- 1
Pull the last five delivered tickets and split elapsed time into active work and waiting. Waiting is the number that matters.
- 2
Categorize each block of waiting: decision, review, environment, dependency, or unclear requirement.
- 3
Measure median time-to-merge and the share of merges owned by one person.
- 4
Ask a recent joiner to deploy to staging unaided, and time it. If they cannot, the pipeline is the constraint.
- 5
Count reopened or reworked items over the last two months as a fraction of completed items.
- 6
Only after those five answers exist, decide whether the shortfall is capacity. If it is, staff the specific stream you can describe on one page.
This takes about a week and costs almost nothing compared with a quarter of misdirected headcount. It also tends to produce a smaller, sharper request: two engineers on a defined stream rather than five general-purpose developers on a project that cannot absorb them.
When we are asked to extend a team, this is the conversation we would rather have first. If the constraint turns out to be decisions, review, or environments, the honest answer is to fix that and revisit staffing afterward. Saying so costs us a larger engagement, which is the reason it is worth trusting.
Common questions
- How long does it take a new developer to become net positive?
- On a system of any real complexity, expect four to eight weeks before someone contributes more than they consume, and longer where the domain rules are undocumented. During that period they draw down the existing team's time for context and review. That cost is unavoidable, which is why it should be spent on a stream that will still matter in six months rather than on an emergency.
- Our deadline is in six weeks. Will adding people help?
- Almost never at that horizon, because onboarding cost lands inside the window and the benefit lands after it. The realistic levers six weeks out are cutting scope, removing the queues in front of the work that is already underway, and clearing the decisions the team is blocked on. If you add anyone, add analysis or decision-making capacity rather than build capacity.
- How do we tell the difference between a capacity problem and a decision problem?
- Look at whether your engineers are busy or blocked. If the backlog is full of well-specified work that nobody has time to start, that is capacity. If tickets are sitting in progress with open questions attached, or piling up in review, that is a decision or bottleneck problem and more engineers will make the queue longer.
- Is it better to add contractors or hire permanently?
- That depends on whether the work is a bounded stream or an ongoing responsibility, not on which is cheaper per hour. Bounded, separable streams with a clear finish are well suited to outside engineers; core ownership of a system the business depends on indefinitely is not. Both options fail identically if the underlying constraint is decisions, review, or environments.
- What if the bottleneck engineer will not give up review authority?
- Usually this is a reasonable position built on experience with changes that caused damage, so treat it as a quality problem rather than a control problem. Agree on which categories of change genuinely need their eyes, get the rest covered by automated checks and peer review, and expand authority as that record holds. If the position does not move at all, accept that team throughput is capped and stop spending money on headcount that cannot get past the gate.
- Does this mean we should never add developers to a late project?
- No. It means the decision should follow a diagnosis rather than substitute for one. When there is an independent workstream, a non-saturated owner, and clear requirements, adding engineers raises throughput reliably and is the correct move.