The first question is what kind of behind you are
“We're behind” describes at least three different situations that happen to produce the same feeling in a status meeting. They have different causes, different fixes, and only one of them responds to more engineers. Getting this wrong is the single most expensive mistake available to an operations lead in a bad quarter, because the wrong fix costs real money and buys a slower project.
Behind on scope. The work that has been agreed to is larger than the time available, and it was probably larger on the day it was agreed to. Nobody made a mistake in execution. The estimate was wrong, or it was right and then eleven things were added to it. This is the most common case and it is the one where adding people helps least, because the underlying arithmetic does not change: the work still has to be understood by somebody, and understanding does not parallelize the way typing does.
Behind on throughput. The team knows what to build and cannot get it out the door. Deploys are manual and take an afternoon. The test suite is slow enough that people skip it, which means it catches things late, which means every release drags a tail of hotfixes. Code review sits for two days because there are three people who can approve and two of them are in meetings. This case is fixable and it is usually fixable fast, but the fix is not headcount. It is a week of unglamorous work on the pipeline that nobody wants to authorize while the date is on fire.
Behind on knowledge. Somebody has to do a thing the team has not done before — a migration off a database nobody chose, a first machine learning component, a payments integration, a rewrite of the part of the system that everyone is afraid of. The calendar is being consumed by learning, and learning looks exactly like being slow. This is the case where outside help pays for itself fastest, because you are buying a specific answer that a specific person already has, and the meter runs for weeks instead of months.
You are probably here because
- A date you have already communicated externally is now in doubt
- Your best engineer is the bottleneck on four things at once
- You approved a contractor last quarter and it did not help
- Somebody has suggested hiring, and hiring takes four months you do not have
The seam test further down is the part worth reading if you only read one section. It is a five-minute exercise and it answers the question more reliably than any conversation with a vendor, including us.
Why adding people usually makes it later
The mechanism is not mysterious and it is not about the quality of the new people. Three costs land immediately and the benefit arrives weeks after them.
The first cost is that somebody has to explain the system, and the only people who can explain it are the people currently producing the work. A senior engineer joining an unfamiliar codebase of moderate size consumes somewhere between fifteen and forty percent of an insider's time for the first two to three weeks. That insider is, in a late project, almost always the person on the critical path. You have taken your most productive engineer and made them a teacher during the exact weeks you needed them building.
The second cost is coordination. Communication paths grow roughly with the square of team size, so going from four engineers to seven does not add three quarters more capacity, it adds about three times as many pairs of people who need to stay in sync. Some of that is absorbed by structure. None of it is free, and the absorption itself requires somebody to design the structure, which is more work for the same overloaded lead.
The third cost is that a new person's first commits are, on average, riskier than an insider's. They do not know which module is load-bearing, which test is flaky, or which piece of the schema is quietly depended on by the finance export. Review has to be more careful, which slows down the reviewers, who are the people you already could not spare.
Against those three costs sits a benefit curve that is slow at the front. In our experience a strong engineer on a reasonably documented codebase reaches a first meaningful merge in three to ten working days, reaches ordinary productivity in four to six weeks, and reaches full context on a complex domain somewhere past two months. If your deadline is inside eight weeks and the work is not separable, the arithmetic almost never comes out in favor of adding anyone. That is the honest version and it is worth saying out loud before money is spent.
| Kind of behind | Does more people help? | What actually moves the date |
|---|---|---|
| Scope exceeds time | Rarely, and never inside eight weeks | Cut scope explicitly, in writing, with the person who can approve the cut in the room |
| Throughput is choked | No — it makes the queue longer | One to two weeks on deploys, tests and review latency; then the same team ships more |
| Missing a specific skill | Yes, and quickly | One or two people who have done this exact thing before, scoped to that thing |
| A separable workstream exists | Yes, if it has a real boundary | Hand over the whole seam, with its own acceptance test and its own owner |
| Nobody can decide | No — more people means more waiting | Name one decision-maker and give them a standing slot |
| Requirements keep moving | No — you will pay to rebuild twice | Freeze a version, ship it, then reopen |
The seam test
Here is the exercise. Take the remaining work and try to name one chunk of it that satisfies four conditions at once. Not three. Four.
It has a boundary you can describe in two sentences. An interface, a data contract, a screen, a service, a batch job, a file format. If describing the boundary requires walking someone through the whole system, there is no boundary and there is no seam.
It has an acceptance test that does not require your judgment to evaluate. Something a person outside the company can run and see pass or fail. “The importer accepts these forty sample files and produces these forty outputs” is a seam. “It should feel faster” is not.
It has an owner on your side who is not your busiest engineer. Somebody has to answer questions. If the only person who can answer is the person you are trying to protect, the handoff routes straight back through the bottleneck and you have gained nothing.
It does not sit on the daily critical path. If the outside team's work blocks your team every afternoon, you have not offloaded work, you have added a synchronization point to a project that was already late.
When the test fails, the useful move is to spend two days manufacturing a seam rather than two months living without one. Pulling the reporting layer behind an interface, defining a file contract for the importer, extracting the notification logic into its own service — these are small pieces of design work that turn an unhandoffable project into a handoffable one, and they have value even if you never hire anyone.
Four shapes of outside help, and what each is good for
“Augmentation” hides four arrangements that behave completely differently.
A carved-off workstream. The outside team owns a seam end to end, with its own acceptance criteria and its own deploy path. Worth the most when a seam exists. Requires the most up-front definition and the least ongoing supervision. This is the shape that actually moves a date.
A specific-skill engagement. Somebody who has done the migration, the integration, the model work, or the performance problem before. Short, expensive per hour, and often the cheapest thing on this list per unit of calendar recovered, because you are buying weeks of somebody else's prior mistakes.
The unglamorous half. Test coverage, the flaky suite, the deploy pipeline, the bug queue, the migration nobody wants, the documentation. Underrated. It requires very little product context, which means the ramp is short, and it directly attacks the throughput case. A team that gets its deploy from ninety minutes to nine will notice the difference for years.
Embedded engineers on the same board. People who join your standups and pull from your backlog. This is the most requested shape and the least effective one for recovering a date, because it maximizes the coordination cost and minimizes the boundary. It is genuinely good for something else: transferring capability into a team that is going to own the system long term. Just do not buy it expecting the date to move.
How much each shape moves a date — our read
Our judgment from doing this work, not a survey. Scores are relative to each other and assume a deadline inside one quarter.
What it costs, without the vagueness
Commercial rates for experienced engineering firms in the United States generally sit between $150 and $275 per hour, with specialist and short-notice work at the upper end and longer commitments at the lower. Two senior engineers for eight weeks lands somewhere around $95,000 to $170,000 depending on rate and hours. A tightly scoped four-week specialist engagement is often $35,000 to $70,000. Those ranges are wide because the variables are real: notice period, domain, and whether the work is defined or has to be discovered.
Two costs are usually left out of the model and both are yours, not the vendor's. The first is the ramp tax on your own team, which is a genuine ten to twenty percent of a senior insider's month for a two-person engagement. Budget it as a real cost, because it comes out of the same critical path you are trying to protect. The second is the cost of definition — somebody on your side has to write down what “done” means, and that person is usually the same overloaded lead. Neither cost is a reason not to proceed. Both are reasons to proceed with a smaller, sharper scope than the one you were about to buy.
On structure: time and materials is the honest default when the work involves discovery, and fixed price is the honest default when the seam is defined and the acceptance test is written. A vendor offering fixed price on undefined work is either padding heavily or planning to argue with you in week six. A vendor insisting on time and materials for a well-defined importer with forty sample files is not taking any risk at all. What matters more than either is a small first increment with a real deliverable inside two or three weeks, so both sides find out early whether this is working.
Do these four things before you add anyone
Each of them is free, each takes days rather than weeks, and in a meaningful share of cases they end the conversation about hiring entirely.
Cut scope on paper, with the person who can approve it. Not “deprioritize” — cut, in a document, with a name next to it. Most late projects contain fifteen to thirty percent of work that nobody would defend if asked to defend it individually, and it survives only because nobody has ever been made to look at it one line at a time.
Measure the throughput chokepoints for one week. How long from pull request opened to merged. How long a deploy takes and how often it fails. How much of the week goes to interruptions. Teams are routinely surprised, and the surprise usually points at something fixable in days.
Triage the bug list ruthlessly. Bugs that have been open for six months and have not been escalated are not bugs, they are wishes. Closing them is not dishonest; leaving them open is what makes the backlog unreadable.
Protect one engineer completely for two weeks. No meetings, no interruptions, no review duty. This is the cheapest experiment available and it tells you whether you have a capacity problem or an interruption problem. Very often it is the second one, and no amount of outside help fixes that.
When the answer is that you do not need us
There are four situations where we would say so, and it is worth naming them plainly because the honest no is the only thing that makes the yes worth anything.
If the deadline is inside four weeks and the work is not separable, nobody can help you and anybody who says otherwise is selling. The only levers left are scope and the date, and both of them belong to you.
If the problem is that requirements change weekly, adding engineers multiplies the rework rather than reducing it. The fix is a frozen version and a shipping date, and that is a management decision that costs nothing.
If the bottleneck is approval — a security review, a legal sign-off, a decision that has been waiting three weeks for a meeting — then engineering capacity is not the constraint and buying more of it makes the queue behind the approval longer, not shorter.
If the deadline is arbitrary, which more of them are than anyone admits in the meeting, then the correct move is to find out who actually needs the date and why. A surprising number of committed dates dissolve on contact with the question “what happens on the day after, specifically?”
The mistakes we see most
- Adding people in the last four weeks — the ramp is longer than the runway, always
- Buying bodies instead of a seam, so the coordination cost lands and the benefit never does
- Assigning the outside team to the hardest, least documented module because that is where the pain is
- Routing every question through the one person you were trying to protect
- No acceptance test, so “done” is negotiated at the end rather than agreed at the start
- Treating the ramp tax as the vendor's problem when it is entirely yours
- Hiding the trouble from the new team, who then rediscover it in week three at your expense
- Skipping the scope cut because outside help feels like a way to avoid the harder conversation
What it looks like when it works
Week one is not code. It is access, a running local environment, a written statement of the seam and its acceptance test, and a single named person on each side who answers questions. If week one produces a merged pull request, that is a good sign about the codebase and a bad sign about how the week was spent.
Week two produces something small and real inside the seam — not a demo, something merged and deployed behind a flag. The purpose is not the feature. It is to prove the whole path works: access, review, build, deploy, rollback. Every unpleasant surprise in an engagement lives somewhere in that path, and finding them in week two costs nothing.
By week four you should be able to answer one question honestly: is the outside team's throughput inside the seam now higher than the coordination cost they impose on your team? If yes, extend and widen the seam. If no, stop. Stopping in week four is a good outcome, it costs a fraction of stopping in week twelve, and a firm that will not tell you when the answer is no is not a firm worth extending.
Before you add anyone
- You know which of the three kinds of behind you are
- You can name a seam that passes all four conditions
- The acceptance test is written down and someone outside could run it
- An owner on your side is named, and it is not your busiest engineer
- Scope has already been cut once, on paper, by someone who could approve it
- The ramp tax is in the budget as your cost, not the vendor's
- The first increment lands in two to three weeks, not at the end
- There is a written condition under which you stop, agreed before starting
Bottom line
The date moves for one of three reasons: the scope got smaller, the throughput got better, or a genuinely separable piece of work got done by somebody else in parallel. Outside help only ever addresses the third, and only when a real seam exists. Most teams that are behind are behind on scope or throughput, which means the highest-value hour available to an operations lead this week is not a vendor call. It is an hour with a printed backlog and a pen, followed by a week of measuring how long things actually take. If a seam falls out of that exercise, buying help is a good decision and it will work. If one does not, the money buys a slower project and a harder conversation in November.
Frequently asked questions
As a working rule, inside four weeks the answer is almost always no, between four and eight weeks it depends entirely on whether a separable seam exists, and past eight weeks it becomes a normal capacity decision. The reason is the ramp curve rather than anything about the people: first meaningful merge is typically three to ten working days and ordinary productivity is four to six weeks out, so a short runway spends everything on ramp and collects nothing.
Cheaper per hour over a long horizon, yes, and slower to arrive by a wide margin. Filling a senior engineering role in the United States commonly takes two to four months from opening the position to a first day, plus the same ramp curve afterward. If the work is permanent, hire. If the work is a defined push with an end date, hiring for it leaves you with a team sized for a peak that has passed. Many companies need both answers for different pieces of the same problem.
Then the highest-value work available is manufacturing one, which is usually two to five days of design: putting an interface in front of the reporting layer, defining a file contract for an importer, extracting a service that everything currently reaches into directly. That work pays for itself even if you never bring anyone in, because a system with clean seams is easier for your own team to work on in parallel too.
Yes, on day one, in detail. The undocumented module, the test suite nobody trusts, the migration that was abandoned halfway, the person who left in March. A firm that hears it up front prices and plans around it. A firm that discovers it in week three bills you for the discovery and loses three weeks of goodwill. Nothing you disclose early costs as much as the same fact found late.
One question, answered honestly: is throughput inside the seam now larger than the coordination cost imposed on your own team? Concretely, has something merged and deployed, are questions being answered asynchronously rather than in meetings, and has your busiest engineer's week gotten better rather than worse. If all three are no at week four, stop. That decision is cheap in week four and expensive in week twelve.