- Delivery
Onboarding an external team without collapsing your internal velocity
The most frequent mistake is starting at full headcount. A progressive ramp costs a few weeks and saves the assignment.
· 4 min read · AzerOps
An IT department decides to reinforce a product team with four external developers. The need is real, the budget approved, the profiles good. Three months later, overall velocity is lower than before the reinforcement.
That is not a hiring failure. It is an arithmetic problem everyone knows and few apply.
Why adding developers slows things down first
Every joiner consumes time from the existing team: questions, code review, business context, architecture decisions to re-explain. That cost is paid by the most productive people on the team, who are also the only ones able to answer.
Four simultaneous joiners on a team of seven immediately saturate review capacity. Merge requests pile up, feedback arrives late, joiners wait — and they are billed while waiting.
The progressive ramp
Weeks 1 to 8: two people, on an isolated domain. Choose a functional scope with few dependencies on the rest of the product. The goal of this phase is not output, it is making the team autonomous on one piece.
A good first assignment is deliberately low-risk: writing the missing tests on the domain taken over, fixing known defects, documenting what is undocumented. That produces real value, it forces people to read the code, and it endangers nothing.
Weeks 9 to 12: ramp to full headcount. Once the first two review the code of the next ones, the internal team's review capacity is no longer the limiting factor.
The mechanism that changes everything: two-stage review
A tech lead on the provider's side reviews their team's code before it reaches the internal team. The latter only ever sees pre-reviewed code, properly split, with an understandable description.
That halves or thirds the perceived review load on the client side, and it is probably the single most decisive factor in a dedicated team's success. Check that your provider plans for it; if their proposal does not mention it, ask.
The conditions on the client side
An available technical counterpart. Not full time, but reachable and able to answer within the day on architecture and integration questions.
A product owner who prioritises. An external team without a prioritised backlog builds what it believes is useful, which is the worst scenario.
The same tools, the same rituals. No separate channel, no parallel meeting, no tracking in a different tool. An external team treated as external will stay external.
The warning sign to watch
If after six weeks the joiners are still asking the same questions, it is not a profile problem: it is that onboarding documentation does not exist. Have them write it, and the internal team review it. It is the only documentation that is systematically useful, because it is written by someone who did not know.