The 90-Day Offshore Engineer Onboarding Playbook

Most offshore engagements that fail do not fail because of the engineer. They fail in the first three weeks, on the client side, in ways that are entirely predictable and almost entirely preventable. This is the playbook we hand clients at kickoff, written as what you do rather than what we promise.

Before day one — the week that decides the month

Access, requested and granted before the start date. Repository, CI, cloud account at the scoped level, ticketing, chat, VPN, password manager, the design tool if relevant. Access requested on day one is access granted on day four, and you have paid for three days of an engineer reading documentation they cannot act on.

A working local environment, verified by someone. Not "here is the README" — have someone follow it from scratch that week. Setup instructions rot faster than any other documentation, and the first person to discover it is always the new engineer, who is also the least equipped to fix it and the most reluctant to say so.

One named owner. The person who decides what this engineer works on and answers their questions. Not a committee, not "ask in the channel". Named, and told they are it.

The first task chosen deliberately. Small, real, shippable in three days, touching the deployment path. A genuine bug fix or a small feature — not a toy, not a doc update, and not a six-week epic. The goal of week one is one thing merged and deployed.

Week 1 — ship something small

The engineer's job this week is to get one change through the entire pipeline: branch, review, merge, deploy, verify. It does not matter how small. What matters is that every step gets exercised while someone is available to fix whatever is broken.

Your job is to be reachable during the committed overlap hours and to answer questions fast, even obvious ones. The tax on a question that goes unanswered for nine hours is paid by you.

Expect roughly 50% output. Budget for it rather than being disappointed by it.

Set the standup up properly: in the overlap window, short, and with a written update posted regardless so that the offset does not swallow context.

Weeks 2–4 — real work, tight feedback

The engineer should now be taking normal tickets. Two things matter.

Review quickly and specifically. A pull request that sits for two days across a timezone offset costs four calendar days. Reviews that say "looks good" teach nothing; reviews that explain the local reason for a convention compress ramp time faster than any onboarding document.

Let them ask why. An engineer who understands why the system is shaped as it is will make better decisions unsupervised, which is the entire point of hiring seniority. Treat the questions as investment, not overhead.

By end of week four, expect roughly 80% output and a decreasing question rate.

Weeks 5–8 — hand over ownership

Give them something to own outright: a service, a pipeline, an area of the codebase. Ownership is what turns an augmented engineer into a team member, and it is the fastest route to the escalation rate dropping to near zero.

This is also when the engagement should start producing things you did not ask for — a flaky test fixed, a runbook written, an alert tuned. If that is not happening by week eight, say so early rather than at review time.

Weeks 9–12 — check the direction, not the activity

Review against outcomes, not hours: what shipped, what improved, what broke less. If the answer is thin, the cause is almost always one of four things.

The four mistakes that waste the first month

1. No technical owner. The engineer works on whatever is asked most recently and loudly. Output looks busy and goes nowhere. This is the single most common cause of a failed engagement, and the only fix is to name someone.

2. Onboarding treated as the engineer's problem. Access trickles in, the environment is broken, documentation is stale, and the engineer spends three weeks being politely stuck. They will not escalate — they are new, they are external, and they assume it is them.

3. Work that is too big or too vague first. A six-week epic as a first task means six weeks before you learn whether this is working. Three small shipped things in week one tell you more than a month of an epic.

4. Treating them as external. An engineer excluded from architecture discussions, planning and the reasoning behind decisions will make worse decisions, and you will conclude the model does not work. It was not the model.

What a good supplier does in these 90 days

• Provides the engineer's access scope and security posture before day one, so your onboarding is not gated on a questionnaire
• Keeps the named engineer named — no quiet substitution
• Tells you when the problem is on your side, which is what this page is
• Offers a two-week paid pilot with an exit clause, so week two is a real decision point rather than a sunk cost
• Replaces a genuinely wrong fit free inside 14 days, and does not argue about it

Ours does all five. The terms are published rather than negotiated per deal.

A 90-day checklist

Before day one: access granted · environment verified by someone · named owner told · first task chosen · overlap hours agreed in writing Week 1: one change shipped end to end · standup in the overlap window · questions answered same day Weeks 2–4: reviews turned around within the overlap window · reasons explained, not just verdicts · output expectation 80% Weeks 5–8: something owned outright · unprompted improvements appearing Weeks 9–12: reviewed on outcomes · direction corrected early · handover expectations written down

Related

• The hidden costs of offshore engineers nobody quotes you
• Why the cheapest offshore rate usually costs the most
• Hire dedicated developers