How long does it take an offshore development team to become productive?
A well-onboarded offshore development team ships its first production change within two weeks and reaches the throughput of an equivalent in-house squad by the end of the third month. Teams that are still dependent on daily hand-holding after ninety days almost never recover — the problem is nearly always onboarding design rather than engineer quality.
European companies tend to under-invest in exactly the first thirty days, then compensate with process for the following year. The pattern below front-loads the effort: heavy investment in weeks one to four, deliberate withdrawal after that.
What does a good 90-day plan look like?
| Phase | Goal | Success signal |
|---|---|---|
| Days 1–30 | Environment, context and first merged code | Every engineer has shipped to production at least once |
| Days 31–60 | Ownership of a real surface area | The team runs its own sprint without a European facilitator |
| Days 61–90 | Autonomy and on-call participation | The team proposes work rather than only receiving it |
What should happen in the first 30 days?
The goal of month one is a merged pull request from every engineer in week one — trivially small if necessary. Nothing else establishes as quickly that access, tooling, review and deployment actually work end to end.
- Access before day one. Repositories, CI, ticketing, cloud accounts, VPN and design tooling provisioned and tested before the engineer's first morning. A week lost to access requests is a week of momentum you never get back.
- A written system map. One page per service: what it does, who owns it, how it deploys, how it fails. Recorded walkthroughs beat live sessions because they survive the time-zone gap and the second and third engineer.
- A named buddy in Europe. One person, not the whole team, responsible for unblocking each new engineer during the overlap window.
- Starter tickets chosen for coverage, not value. Pick work that forces the engineer through the whole pipeline — code, test, review, deploy, observe.
- The definition of done in writing. Tests, review, documentation, monitoring, rollback. Do not leave it to be inferred.
If the engagement covers a whole squad rather than individuals, decide upfront which model you are running — the accountability differences are set out in dedicated team vs project-based outsourcing.
What changes in days 31 to 60?
Month two is about handing over a surface area with a name on it. Give the team an owned service, feature area or customer journey — something with a boundary, a backlog and an on-call implication. Ownership is what converts contractors into a team.
Three shifts belong to this phase:
- Move the ceremonies. Stand-up, planning and retro run at times that suit the offshore team, with the European members joining, not the reverse. This single change signals more about status than any speech.
- Reduce synchronous dependency. Every question that had to be asked live in month one should have a written answer by the end of month two: architecture decision records, runbooks, a decision log.
- Start reviewing in both directions. Offshore engineers reviewing European code is the fastest way to level context and the clearest signal that they are peers.
The daily overlap window is the scarce resource here. Spend it on decisions and pairing, never on status reporting — the patterns in managing a remote development team across time zones apply directly.
What does the team own by day 90?
By the end of month three the team should be planning its own sprint, participating in on-call for its own services, and proposing roadmap items rather than only consuming tickets. The European lead should be reviewing outcomes weekly rather than unblocking daily.
Deliberately withdraw support in this phase. Stop attending their stand-up. Stop being the default reviewer. If quality holds, onboarding worked; if it collapses, you have found the gap while it is still cheap to fix.
What does the European side have to do?
Onboarding is usually described as something done to the offshore team. In practice most of the required work sits on the European side, and it is the part that gets skipped.
- Name one owner. A single European engineer accountable for the offshore team's ramp-up, with it written into their objectives. Shared ownership means nobody does it.
- Protect the overlap window. Keep the shared hours free of internal European meetings. If your lead is in a planning session every morning, the offshore team is blocked every morning.
- Rewrite the tickets. Tickets written as instructions produce literal implementations. Write the problem, the constraint and the acceptance criteria, and let the engineer choose the solution — that is what you are paying seniority for.
- Fix the documentation you were tolerating. The gaps an offshore team hits in week two are the same gaps your local hires absorbed silently over months. Fixing them helps everyone.
- Say what good looks like. Share an example pull request, an example architecture decision record and an example incident write-up. Examples transfer standards faster than any style guide.
How do you onboard the second and third engineer?
The first cohort is onboarded by people; every cohort after that should be onboarded by artefacts. If adding a fourth engineer costs as much European attention as the first did, the team is not scaling — it is being rebuilt each time.
The mechanism is simple: whenever a new joiner asks a question that is not answered in writing, the answer goes into the repository before the ticket closes, and the existing offshore engineers own that. By the second cohort, time to first merged pull request should be under two days with no European involvement beyond access provisioning.
Which metrics tell you onboarding is working?
| Metric | Day 30 target | Day 90 target |
|---|---|---|
| Time to first merged pull request | Under 5 working days | Under 2 days for new joiners |
| Pull requests needing a European reviewer | 100% | Under 30% |
| Blocking questions per engineer per day | 3–5 | Under 1 |
| Change failure rate | Baseline | At or below in-house baseline |
| Work items proposed by the team | 0 | At least 20% of the sprint |
Track blocking questions per engineer per day above all else. It is the cleanest measure of whether context has genuinely transferred, and it falls before any velocity metric moves.
Does onboarding differ for a dedicated team versus individual engineers?
The first thirty days are identical — access, context, a merged pull request — but months two and three diverge. Individual engineers joining your existing squad onboard into your rituals and inherit your team's ownership. A dedicated team needs its own ownership boundary, its own on-call rotation and, critically, its own technical lead who is accountable for quality rather than for status reporting.
The mistake is buying a dedicated team and then managing it as five individuals. If your European lead is still assigning tickets to named offshore engineers in month three, you are paying for a team and getting augmentation. Hand the squad an outcome and let its lead distribute the work.
Why does offshore onboarding usually fail?
Rarely because of skill. The recurring causes are structural: access granted piecemeal over three weeks; no named owner in Europe; tickets written as instructions rather than problems; an account manager inserted between the two engineering teams; and a first assignment so peripheral that the engineer never touches the real system.
One more, less obvious: hiring for the rate card. An engineer who cannot operate autonomously will not be rescued by a good onboarding plan. Vet the individuals as rigorously as you would a local hire — the loop in how to vet a senior software engineer works unchanged offshore.
ILMTEC's senior engineering talent service places pre-vetted India and UAE engineers into European teams with this onboarding structure built in — your tooling, your rituals, your definition of done, with the first production change expected inside two weeks.
