The launch is late. Will more engineers help? Usually not where you'd put them.

It is the sprint review in the middle of October. The launch was promised for the last week of January, the remaining work has been re-estimated for the third time, and at the team's real pace it needs about four weeks more than the calendar holds. Somebody suggests bringing in more engineers. Somebody else, usually the most senior person in the room, quotes the old rule that adding people to a late software project makes it later.

Both are partly right. The rule comes from The Mythical Man-Month, a book on software project management first published in 1975, and it has lasted half a century because the reasons behind it are real. Newcomers need time to become useful. The people who teach them are the people the project can least spare. Every extra person adds conversations. But the same book made an exception for work that can be split off without much talking, and that exception is where the useful decision lives. So the questions worth answering are narrower: is capacity your problem at all, where would new people sit, and by what date do they stop being worth adding?

First, check that you are short of hands

Lateness has several causes and only one of them responds to headcount. Before anyone calls a vendor, take the last three sprints and find every ticket that sat still for more than a couple of days. For each one, write down what it was waiting for. The answers usually fall into four piles.

• Waiting on a decision. The layout of the pricing page, the answer to an edge case, which of two flows the product owner prefers. More engineers generate more questions for the same busy person.
• Waiting on someone outside. A partner's API (the interface another system exposes) that is not ready, an app store review, a customer's security questionnaire, a sandbox that keeps going down. Nobody you add can make another company faster.
• Waiting on review, test or release. Pull requests queued for the two people allowed to approve them, one shared test environment, a release that takes a manual afternoon. More people make these queues longer, unless they are put to work on the queue itself.
• Actually being built. The ticket was slow because the work was large or hard. This is the only pile that more capacity shrinks directly.

If most of the stalled time sits in the first two piles, you do not need more engineers, from us or from anyone. You need a product owner with the hours to decide, one named person chasing outside dependencies, or a smaller launch. The third pile is a capacity problem of a particular kind, and the fix is narrow: one or two people who repair the test environment and automate the release can be the best addition you make all quarter, because they never touch a feature.

Find the last useful day

Every added engineer has a ramp: the weeks between first login and the point where they produce more than they cost. During those weeks they are getting access, reading code, asking questions and having their first changes reviewed, and the existing team pays for all of it. For work in the middle of an unfamiliar product, three weeks is a modest assumption.

Now put the ramp against the real calendar, not the one in the plan. A launch in the last week of January usually means a code freeze around the second week of January, so there is time to harden and fix. Between now and then sit two weeks when most of the team is away. Count backwards from the freeze, take out the holidays, and you find the last useful day.

For that calendar, the last useful day falls in mid-November. An engineer who starts on 2 November has a little over five productive weeks before the freeze. One who starts on 7 December is still learning the codebase when it is frozen. Five weeks of delay removed the whole benefit.

The start date is also not the day you decide. Choosing a firm or a contractor, signing, and getting accounts, laptops and repository access approved all take time of their own, and in many companies the access step alone runs longer than anyone planned. If the January date really matters, the decision about help is due this month.

On top of the team, or beside it

Where new people go matters more than how many arrive. On top means joining the core team in the same modules, the same backlog and the same review queue. Beside means taking a separate piece of the remaining work, with its own lead and its own definition of done, and meeting the core team at one agreed boundary: an API, a data format, a set of screens.

A worked example shows the difference. The numbers are assumptions chosen to show the shape, not measurements. Six engineers have eight working weeks before the freeze, which is 48 engineer-weeks of capacity, against 72 engineer-weeks of remaining work. They are 24 short. The budget allows four more engineers from 2 November.

On top, the four need three weeks before they are net useful, then work at perhaps 70 percent of a veteran's pace because their changes keep colliding with everyone else's. That is about 14 engineer-weeks of output. Meanwhile the two senior engineers spend around 20 hours a week on questions and reviews during the ramp, and half that afterwards: roughly 110 hours, close to three engineer-weeks, taken from the people the critical path (the chain of work that sets the launch date) depends on. The net gain is about 11 engineer-weeks. The project is still more than two weeks late, and the two people holding it together are tired.

Beside, the same four arrive as a team with a lead and take a slice the core team had estimated at 20 engineer-weeks: say, the partner integrations and the migration of existing customer data. They only need to learn the boundary and their own slice, so the ramp is nearer two weeks, and their lead reviews their code. The core team spends perhaps four hours a week with that lead. The slice gets built, the core team's remaining work drops by 20 engineer-weeks, and the shortfall falls to about five, under a week at the team's pace. A modest scope cut closes it.

Beside is not free of risk. If the slice turns out more tangled with the core than it looked, every tangle becomes a conversation between leads, and the arithmetic slides back toward the first case. That is why the choice of slice is the real decision.

What a good slice looks like

A good slice can be described on one page, tested without the rest of the product, and changed without anyone on the core team having to agree. In late projects the candidates are usually some of these.

• Integrations behind a written contract. Payments, partner APIs, the CRM sync. If the interface can be written down this week, a separate team can build to it and the core team only has to honour it.
• Data migration and the cutover rehearsal. Large, careful work with little overlap with the new features, and the part most often left until the final fortnight.
• Test automation and the release path. The third pile from earlier: the shared test environment, the manual release afternoon, the regression tests nobody had time to write.
• Back-office tools. Admin screens, reports and support tooling that the launch needs and customers never see.
• Everything that is not the launch. Bugs in the current product, support escalations, the old system that still needs patching. Handing this queue over returns hours to the core team without a newcomer touching launch code at all.

Bad slices are just as easy to spot: the half-built module at the centre of the product, anything whose design is still being argued over, and anything described as “help where needed”. If you cannot draw a line around the work, a newcomer cannot work inside it.

AI shortened the ramp and moved its cost

The ramp is shorter than it used to be. An engineer working with a capable AI coding assistant can have it explain an unfamiliar module, trace a request through the system and draft a first change in the first few days. That part of the old rule has genuinely changed.

What has not changed is the knowledge that lives outside the code: which half-finished feature is about to be cut, why the obvious fix was rejected in March. And the new speed brings a new cost. A newcomer with an assistant can open pull requests in week one, and each of them lands in the review queue of the same two senior engineers. The onboarding tax used to be paid in questions. Now much of it is paid in reviews, and reviewing plausible code from someone who does not yet know the system is slow, careful work.

So the first thing to ask about any added engineer, from any source, is who reviews their code. If the answer is your two most senior people, you have added load to the critical path, however busy the newcomer looks in the commit history. A team placed beside the core brings its own reviewer, and that is a large part of why it works.

Questions for anyone offering to save the date

Whether you ask us, another firm or a contractor, these separate a plan from an offer of headcount.

• Which part would you take? Ask what makes that part separable from the rest. A good answer names a boundary. “Wherever you need us” means the work will land on top.
• How much of my seniors' time? Ask for hours per week, and in which weeks. A good answer is a number, highest in the first week and falling. “None” is a worrying answer: it means nobody has thought about it.
• Who reviews your code? Ask who checks their team's changes before they reach yours. There should be a named person on their side whose job includes it.
• What merges first, and when? Expect something small in the first week or two that proves access, the pipeline and the review path all work.
• What if the slice is tangled? Look for a checkpoint around the end of week two, with the fallback agreed in advance rather than improvised.
• What would you cut instead? Anyone who has looked properly at a late project has an opinion about its scope. A vendor who can only add has not looked.

The cheapest engineer is a cut feature

Every late project has a scope conversation in it somewhere, and the best time to have it is before deciding on help. A smaller launch on the promised date usually costs less, in money and in trust, than a complete one in March. Most boards would rather hear in October that January ships without the reporting module than hear in January that nothing ships.

If help is still the answer after that conversation, start counting from the freeze this week. Help that arrives after the last useful day is not help. It is a second project, staffed by newcomers and run by your best engineers in their spare time, a few weeks before they have none.