How to onboard offshore developers: the first 90 days, planned

The result is predictable: a strong hire producing very little for a month, both sides quietly wondering whether the engagement was a mistake, and a ramp that takes a quarter when it should have taken weeks.

Onboarding is where that ramp is decided. Every week an engineer spends waiting on access or guessing at context is a week you are paying for and not receiving, and it is the one part of the engagement that no partner can do for you, because the context that makes a developer productive lives inside your team. This guide sets out a complete onboarding sequence for offshore engineering, design and AI hires, written for the people who own the outcome: founders, CTOs and heads of engineering at UK and UAE companies.

It picks up exactly where selection ends. If you are still deciding who to hire, start with the shape of the team in how to build an offshore team and come back here once someone has said yes.

Onboarding starts the week before day one

The single biggest determinant of a fast ramp is boring: whether everything was ready before the person started. Treat the week before the start date as a project with a checklist, not a hope.

• Provision access in advance. Repositories, environments, ticketing, documentation, and the communication channels the team actually uses. Every item an engineer has to request after starting costs a day of back-and-forth across time zones.
• Write the starter pack. One document: what the product does, who the customers are, a map of the codebase at the level of areas and owners, where decisions are recorded, and how work is judged. Two pages beats none and beats forty.
• Choose the first ticket now. Small, real and shippable inside week one. Choosing it in advance forces you to notice whether your backlog contains any well-described work at all.
• Name the buddy. One person the new engineer can ask anything without booking a meeting. Make it official, and make sure the buddy’s own workload reflects it.
• Book the first fortnight’s sessions inside the overlap window. Kick-off, codebase walkthrough, product context, first review. If they are not in calendars before day one, the non-overlap hours will eat them.

A good staff augmentation partner will have handled the logistics around the start and confirmed the practical details, working hours, overlap window and setup, during selection. What no partner holds is your product knowledge. Budget real hours from your senior engineers in weeks one and two; it is the highest-return time they will spend that quarter.

Day one: identity and access, done once and properly

Security setup is easiest on the first morning and gets harder every week after. The essentials are the same ones we set out in how to manage an offshore team: company-controlled identity with SSO and two-factor authentication on everything, least-privilege access scoped to the work, production data kept out of development environments, and a written agreement covering confidentiality and IP signed before code is written.

Two onboarding-specific points are worth adding. First, grant access as a reviewed bundle, not a drip. The pattern where each permission is requested, justified and granted separately stretches a one-day task across three weeks and teaches the new engineer that asking is expensive. Second, write the offboarding checklist on the same day you onboard. Access granted in one place is access you can revoke in one place, and the discipline costs nothing while everything is fresh.

Week one: ship something real

The goal of week one is a merged pull request on real work. Not a tour, not a sandbox exercise, and not the hardest ticket on the board. Something small enough to finish and real enough to matter.

This does three jobs at once. It forces every remaining access gap into the open on day two rather than day twenty. It puts the new engineer into your code review flow immediately, in both directions, which is where standards are actually transmitted. And it gives both sides an early, honest signal. An engineer who has shipped in week one believes the engagement is working, and so do you.

Around the first ticket, run the context sessions you booked: a codebase walkthrough from the buddy or lead, a product session on customers and priorities, and a short written summary of each so the material survives the meeting. Recorded walkthroughs are worth the five minutes they take; they onboard the next hire for free.

Weeks two to four: from tickets to context

Once the first work has shipped, widen the aperture deliberately:

• Progress from tickets to a small owned area. A module, a service, a surface. Ownership is what converts a task-doer into a team member, and it is the stage where context starts compounding.
• Bring them into review as a reviewer. Reviewing others’ code is the fastest route into a team’s standards and its reasoning, and it signals trust.
• Keep the written-first habit. Briefs with acceptance criteria, decisions logged where they can be found. The habits that make the overlap window sufficient are built in these weeks or not at all.
• Hold a real one-to-one at the end of week two. Not a status meeting. What is unclear, what is blocked, what surprised them. The answers are a review of your onboarding, not of the engineer.

The 30, 60, 90 day checkpoints

Write the expectations down before day one and review them together at each gate. The point is not surveillance; it is that a ramp measured against nothing can neither succeed nor fail, only drift.

If a gate is missed, act as you would with an in-house hire: a direct conversation, a written improvement expectation, and a decision at the next gate. This is also where the commercial terms behind the hire matter. A placement that is not working should be a replacement conversation with your partner, on terms agreed before anyone started, not a months-long restart. Ours are set out plainly in how it works.

The ramp itself is also a cost, and it belongs in any honest comparison of hiring routes. A structured onboarding that reaches autonomy in 90 days against an unstructured one that takes six months is a larger financial difference than most rate negotiations, which is why ramp time features in our breakdown of what offshore staffing actually costs.

Three failure modes that waste the first month

The idle start. The engineer arrives, and the permissions do not. A fortnight passes in requests and waiting, enthusiasm drains, and the engagement’s first impression on both sides is friction. Entirely preventable by the pre-boarding checklist above.

The tourist onboarding. Three weeks of introductions, walkthroughs and shadowing with no shipped work. It feels thorough and it teaches nothing, because context without application does not stick. Ship in week one; let the context sessions run alongside real work, not ahead of it.

Sink or swim. The opposite gamble: a ticket dump on day one with no starter pack, no buddy and no sessions, on the theory that good engineers figure things out. They do, eventually, by reverse-engineering context your team could have handed over in hours. You pay for the reverse-engineering at the day rate.

All three have the same root cause: nobody owned the onboarding. Name an owner, give them the checklist, and the failure modes disappear.

What is actually different offshore

Honestly: less than the anxiety suggests. The structure above is what a strong onboarding looks like anywhere. The differences are amplifiers, not new rules.

Distance removes hallway osmosis, so anything transmitted by proximity in an office must be written down or deliberately scheduled. The overlap window concentrates real-time contact into a few hours, so those hours must carry the sessions that need back-and-forth, with everything else moving to writing. And ambiguity costs more, because a misunderstood brief is discovered a working day later rather than at the next desk. Teams that already work written-first onboard offshore engineers almost without noticing, which is the theme we develop across the whole of managing an offshore team.

None of this depends on where the engineer sits. It depends on whether someone prepared.

The onboarding checklist

Before day one: access provisioned and tested; starter pack written; first ticket chosen; buddy named; first fortnight booked in the overlap window; confidentiality and IP agreement in place.

Day one: SSO and two-factor on everything; least-privilege bundle granted in one pass; offboarding checklist written; kick-off held.

Week one: first real ticket merged; codebase and product sessions held and summarised in writing; engineer in the review flow both ways.

Weeks two to four: small area owned; reviewing others’ code; one-to-one held; written-first habits in place.

Days 30, 60, 90: written expectations reviewed at each gate; act on misses immediately.

A partner can make the start of this sequence dramatically easier by putting the right person in it, and the criteria for judging that are covered in how to choose a staff augmentation company. The rest is yours, and it is worth doing well: the same engineer, onboarded twice as fast, is simply a better deal.