Onboarding a Nearshore Dev Team: A 2-Week Plan
Most onboarding failures get blamed on the team's technical ability. That's almost never what happened.
What happened is that nobody decided who answers questions, the first ticket was too big to finish, and by day nine four engineers were guessing at requirements in parallel.
Here's a two-week plan that avoids that. It's written for you, not for the vendor — most of the work in week zero is yours.
Week zero: what you prepare before anyone starts
Do this before the contract start date. If you skip it, week one becomes week zero and you've lost five days.
Name an internal owner. One person on your side who answers questions within the working day. Not a committee. If nobody has the bandwidth, delay the start — a team that can't reach you will build the wrong thing efficiently.
Get access provisioning started. Repos, CI, staging, ticket tracker, design files, VPN if you have one. Access requests routed through IT are the single most common cause of a wasted first week. Start them ten days early.
Write down what you assume everybody knows. Not full documentation — a single page: what the product does, who uses it, what the three main services are, and which parts of the codebase are known to be bad. That last one saves more time than the rest combined.
Pick the first ticket yourself. It should touch real code, be finishable in under two days, and have an obvious definition of done. Not a bug hunt. Not "read the codebase."
Week one: access, context, and a merged PR
The goal for week one is narrow: one pull request merged to your main branch. Not velocity. Not a sprint's worth of tickets. One merged PR proves the entire chain works — access, build, review, deploy.
Days 1–2
Access confirmed and verified by actually using it. The team clones, builds, and runs the project locally. If the build takes two days, that's not an onboarding problem, that's a build problem you now know about.
A working session with your internal owner: product walkthrough, architecture at a whiteboard level, and where the bodies are buried.
Days 3–4
First ticket in progress. Expect questions, and expect some of them to be about things you thought were obvious. That's the point — the questions are surfacing your undocumented assumptions.
Day 5
First PR opened and reviewed by your team. Review it properly. A soft review here teaches the team that your standards are negotiable, and you'll spend the next three months undoing that.
Week two: ownership of a real slice
Now widen the scope. The team takes a small but complete area — a service, a feature, a set of endpoints — and owns it end to end.
The shift that matters is from tasks to outcomes. In week one you handed over tickets. In week two you hand over a problem and let the team decompose it.
By the end of week two you should have: three to five merged PRs, one area with a named owner on the team, and the team participating in your normal ceremonies rather than a separate onboarding track.
The signals that tell you it's going wrong
Watch for these. All four are recoverable in week two and expensive in month two.
Questions have stopped. Silence isn't fluency, it's usually people guessing. A team that asks nothing in week one is a team about to deliver something you didn't ask for.
Every PR is approved without comment. Either your reviewers disengaged or the team is only picking safe work.
The same question arrives from three different people. Nobody is consolidating context on their side. This is exactly what a team lead exists to prevent.
Estimates arrive with no range and no caveats. A team that never says "this might be bigger than it looks" is a team that will tell you about the slip on the due date.
Why the lead changes the shape of this
If you're working with individual contractors, everything above is your job. You answer every question, you consolidate context, you notice when someone is stuck and too polite to say so.
With a dedicated team, a lead absorbs that. Your internal owner has one counterpart instead of four. Questions get filtered and batched — the ones that need a product decision reach you, the ones that need codebase context get answered internally.
That's the mechanism described in our guide on staff augmentation in Colombia: the lead is what lets you buy technical depth without every engineer needing to be your interface.
It also means your week-zero prep matters more, not less. The lead can only route questions to someone who exists.
What two weeks does not buy you
Be honest with yourself about the ceiling here.
Two weeks gets a team productive on a slice. It does not make them autonomous across your whole system — that takes a quarter in most codebases, longer if your architecture has surprises.
It also won't compress if your codebase has no local dev setup, no tests, or no one who understands the deploy path. Onboarding speed is mostly a function of how legible your system already is. If two weeks feels impossible, the onboarding plan isn't the thing to fix.
Where to start
If you're evaluating a partner, ask them to walk you through their first two weeks in detail — not a promise, the actual schedule, and what they need from you in week zero. A partner who hasn't thought about week zero hasn't onboarded many teams.
Book a 30-minute call. Bring your current setup and we'll tell you honestly where your onboarding would get stuck.