AXENTED — Blog Article

Building a Nearshore Team from Zero: 90-Day Playbook

The first 90 days of a nearshore engagement are when the most important decisions get made and when most failures are seeded. Teams that get it right create momentum that compounds. Teams that get it wrong spend months in a low-grade dysfunction that everyone can feel but nobody can diagnose.

This is the playbook we use — week by week, with the specific outcomes that define success at each stage.

Days 1–14: Context Transfer

Nothing productive happens before context transfer is complete. The nearshore engineers joining your team don't have the institutional knowledge your internal team has accumulated over months or years. Making them productive before that gap is closed is a way to produce fast but wrong work.

What this looks like in practice: synchronous walkthroughs of the architecture (recorded for async review), documented decisions about why the system is the way it is (not just what it is), access to all the tools with credentials and permissions fully provisioned before day one, and a clear definition of what "done" looks like for the first real deliverable. The first two weeks shouldn't produce production code. They should produce engineers who understand the system well enough to contribute safely.

Days 15–30: First Real Work

The first real task assigned to a new nearshore engineer should be moderately challenging, have a clear definition of done, and not be on the critical path. The goal is a controlled environment for the first real feedback cycle — the new engineer ships something, gets a code review, receives feedback, and incorporates it. That loop reveals communication patterns, quality expectations, and tool familiarity gaps in a low-stakes context.

The mistake is assigning urgent work first. Urgency compresses feedback loops and makes it harder to distinguish between "this engineer needs more context" and "this engineer has a skill gap."

Days 31–60: Integration into the Team Rhythm

By week five, the new engineer should be in all the regular team rituals — standup, sprint planning, retrospective, code review. The goal of this phase is not maximum output. It's integration: establishing the communication patterns, feedback norms, and working relationships that determine long-term productivity.

Assign a buddy from the internal team — not a manager, an engineer — whose explicit job is to be the first call when the new engineer is stuck. That relationship is the most important social infrastructure of the first 90 days. It normalizes asking for help and creates a feedback channel that doesn't require a formal 1:1.

Days 61–90: Independent Contribution

By the end of month three, the nearshore engineer should be operating with the same degree of independence as an engineer who has been with the team for six months. Not maximum independence — that takes a year. But functional independence: able to take a ticket from backlog to production without requiring a senior engineer to be in every decision.

The milestone that confirms this phase is complete: the engineer has shipped something of real complexity, received normal code review feedback (not mentorship-level guidance), and owned a non-trivial production issue from alert to resolution. Those three events tell you the integration worked.

The Metrics That Tell You How It's Going

Track four things through the 90 days: time from assignment to first meaningful pull request (should decrease week over week), code review cycles per pull request (high numbers indicate communication gaps, not just skill gaps), percentage of questions asked synchronously versus asynchronously (distributed teams should shift toward async over time), and the buddy relationship — are they using it, and is it producing useful feedback?

If any of these metrics plateau or move in the wrong direction after week six, the problem is usually in the context transfer phase, not the engineer. Revisit the onboarding documentation and the architecture walkthrough before concluding there's a capability issue.