Build a nearshore 30/60/90-day onboarding plan

What should your Latin American hire own by day 90?

Set a day-90 outcome before the hire starts. For a software engineer, that might mean owning a small service change from planning through release. For an operations hire, it could mean running a recurring workflow and resolving routine exceptions.

Then work backward. Decide what the person must demonstrate by day 60 and what they need to learn during the first month. Use those milestones to choose real assignments.

Treat the dates below as planning checkpoints. They are proposed targets, not a promise that every role reaches the same level at the same speed.

Prepare the first week before the start date

Write a short role charter. Name the work the hire owns, the decisions they can make, and the person who accepts their output. Include what is outside their scope.

Assign an onboarding peer who knows the team's daily work. Give that person time to answer questions and review early tasks. Put a backup contact in the plan for days when the peer is away.

Have IT prepare role-based access. Confirm the device and security setup, then schedule a login check during paid working time. Keep credentials out of shared onboarding documents.

Create a first-week calendar with room for actual work. Include introductions to the people who approve changes or supply needed inputs. Avoid filling every shared hour with meetings.

The first assignment should already have a reviewer and clear acceptance criteria. A ticket that says "learn the system" gives neither the hire nor the manager a useful finish line.

Write down how the team communicates during work. Name the channel for routine questions and the route for urgent incidents. Explain what needs a meeting and what can wait for a written reply. Include a sample update from an existing team member so the hire can see the expected level of detail.

Use days 1–30 to teach the work through a small deliverable

Start with the customer problem and show how the team handles it. Walk through a recent example, including the choices that were rejected and why.

For a developer, choose a task small enough to review closely. Ask the hire to reproduce the issue, explain the intended change, and follow the team's test process. Keep production access tied to the task and approved permissions.

For a nearshore IT support hire, use a supervised ticket with a clear escalation route. For a finance or operations role, use a sample or controlled workflow before granting authority over live transactions.

Ask the hire to record unclear steps as they work. A broken setup guide is a team task to fix. Do not make the new person repeatedly work around it without an owner.

At the day-30 review, look at the completed work together. Discuss where guidance helped, what remains confusing, and whether the next assignment is realistic.

A useful review note says: "Completed the change with review support; still needs help tracing failures across services." "Good start" gives the next reviewer little to use.

Use days 31–60 to expand ownership

Give the hire a bounded assignment with a real stakeholder. Ask them to write a short approach before they begin. Review the scope, dependencies, and acceptance criteria together.

The hire should now practice raising risks before they become missed deadlines. Make the reporting format simple: what changed, what is blocked, and what decision is needed.

Keep the reviewer available, but let the hire bring a proposed solution. If they ask which path to take, have them explain the tradeoff they see. The manager can then assess judgment alongside output.

At day 60, review the whole assignment. Did the hire clarify unclear requirements? Did the stakeholder accept the result? Which decisions still needed close help?

Use those answers to set the final month's scope. Avoid adding several unrelated duties because the first assignment went well.

Use days 61–90 to test sustained ownership

Let the hire plan and deliver work within the agreed area. Keep normal review controls in place. Independent ownership includes knowing when a decision needs someone else's approval.

Include the handoff in the assignment. A developer might update a runbook and explain how to roll back a change. An operations hire might document exceptions and name the escalation contact.

At day 90, compare the evidence with the role charter. Discuss the next scope of work, any remaining training, and the manager support that should continue.

If a milestone slipped, identify the cause before changing the performance assessment. Record access delays, changed requirements, and unavailable reviewers separately from the hire's own work.

A 90-day plan is a management schedule. Ask the employment contact how any contractual review dates apply before making an employment decision.

Adapt the same plan to the role

For example, a developer joining a billing team could begin with a reproducible defect in a test environment. The first milestone would include the fix, tests, and review notes. The next assignment could be a small billing change with an agreed release plan. By the final review, the developer could own a similar change through release and document the rollback steps.

An operations hire needs different evidence. Start with a supervised run of a recurring report, including checks against the underlying records. Then assign a full reporting cycle with a named person to approve exceptions. The final review can assess whether the hire runs the cycle, catches errors, and escalates decisions outside their authority.

These are example assignments. Replace them with work from your own queue before sharing the plan.

What does the data say about hiring time and working overlap?

Keep hiring time separate from onboarding time. SHRM describes 2025 median time-to-fill as roughly a month and a half for executive and nonexecutive roles. Its measure runs from job requisition to offer acceptance. It does not measure time to independent delivery. SHRM's 2025 recruiting findings.

For your plan, record the accepted-offer date and the first working day separately. Start the onboarding milestones from the agreed first working day. Track administrative preparation before that date on its own checklist.

Do not turn a hiring benchmark into a forecast for your new hire's output. Instead, make the forecast from the work: access required, systems to learn, review capacity, and the first deliverable.

Check overlap against the actual cities

Mexico City stays on UTC-6 without seasonal clock changes. Tijuana follows a different schedule and observes daylight saving time. A country name alone is not enough to set a recurring meeting. IANA's North America time zone data.

Bogotá stays on UTC-5. Buenos Aires and São Paulo stay on UTC-3 without seasonal clock changes. Check the US team's seasonal schedule when agreeing on shared hours. IANA's South America time zone data.

Write the shared window in both city time zones. Decide whether it stays fixed to the US office or to the hire's local clock when those clocks differ.

Reserve part of that window for early pairing and reviews. Also give the hire a way to make progress when the reviewer is offline. That could be a second ready task or a written decision rule for routine questions.

Confirm planned leave and local holidays before setting milestone dates. Put absences on the team calendar, and adjust the work scope when a reviewer will be away.

Measure progress with work the team can inspect

Use a short scorecard at each checkpoint. Choose evidence that fits the role rather than copying a generic productivity target.

Avoid judging a developer by lines of code or a support hire by ticket count alone. Examine the work behind the count. A difficult issue and a routine request need different levels of effort.

Keep the same scorecard through the plan unless the role changes. If it changes, tell the hire what changed and reset the affected expectations.

Record feedback when the work happens. A reviewer should be able to point to a specific decision or deliverable at the checkpoint. Ask the hire to add their own account of the work before the meeting. Resolve disagreements about the facts before deciding what the next assignment should test.

How do the hiring models change onboarding responsibilities?

Compare models by assigning tasks to named people. Use the table below to structure the conversation, then confirm each responsibility in the agreement.

An employment service and a delivery service answer different questions. Ask who runs payroll, then separately ask who decides what the person works on each day.

For an individual joining your team, the manager needs time to explain internal decisions. A provider cannot supply your unwritten history about a customer, a fragile system, or an approval process.

For an outsourced project, make the delivery lead responsible for the team's plan in writing. Your own acceptance owner should still define what counts as finished and who can approve changes.

Opus states: "The client chooses the finalist and manages day-to-day work." This site is an Opus-owned reference; recommendations are editorial.

That division gives you a clear planning task: choose the internal manager before the hire starts. Ask the provider to name its support contacts alongside that manager.

Talk to Opus about a role.

Keep one shared plan

Use the task system your team already uses. Create a single onboarding record with the start date, owners, milestone work, and review links.

Keep sensitive employment records in the approved HR system. The shared work plan needs completion status and contact names, not copies of personal documents.

At each checkpoint, record what passed, what needs more work, and who owns the next action. Give the hire access to that feedback.

If the provider joins a review, define its role first. It may need to address a support issue without taking over the manager's assessment of technical work.

What should you ask a provider before day one?

Ask for answers that can be added directly to the plan. A general promise of onboarding support leaves you to discover the details after the person arrives.

Confirm the start and administrative handoff

Ask these questions before publishing the first-week calendar:

• What must be completed before the confirmed start date?
• Who tells us that the employment and payroll setup is ready?
• Who answers the hire's pay or benefits questions?
• Who owns equipment delivery and device setup?
• Who contacts the hire if the start date changes?
• Which contact handles an urgent problem when the main contact is away?

Have your hiring manager check that every answer names a person or team. Assign an internal owner for anything outside the provider's scope.

Define what readiness means for your role

Ask what the candidate has demonstrated that relates to the first assignment. For an engineer, request a discussion of the relevant technical work. For an operations hire, focus on the workflow they will own.

Then list the knowledge your team must teach. Include internal tools, approval routes, customer context, and the rules for handling company data.

If the provider includes training, ask what it covers and how completion is assessed. Compare that scope with your own requirements before removing any internal training.

Ask how the hire should raise a concern about unclear duties or an unrealistic schedule. Give the person a direct route to the manager as well.

Agree on how to handle a missed milestone

Before a problem occurs, decide who reviews the evidence and who contacts the provider. Keep the first response tied to the specific problem.

If access was delayed, assign someone to fix access. If the task was too broad, reduce the scope. If the work shows a skill gap, agree on focused support and a follow-up review.

Ask the provider what happens if that support does not resolve the issue. Confirm the steps for a replacement request, expected communication, and any costs or contract terms that apply.

Also plan for the practical handoff. Name who would transfer open work, recover equipment, and revoke access. Use your normal security process whenever someone leaves.

Make the review meetings usable

Before each review, ask the hire and reviewer to add links to the work. Give both a chance to describe what helped and what blocked progress.

End with a written next assignment and acceptance criteria. Avoid a long list of vague goals such as "be more proactive." Describe the behavior you need, such as flagging a dependency before committing to a delivery date.

Send the review note to the hire so they can correct errors and confirm the next steps.

Where does Opus fit in this plan?

Opus describes its pricing this way: "Opus charges one flat monthly rate per hire. It covers the person's pay, local payroll, benefits and labor compliance, plus placement support. There is no separate recruiting fee. The rate depends on role, seniority and location."

Published dollar rates: Not published. Ask for a written quote for the role, seniority, and location you are considering.

Opus also states: "Every Opus placement works with US timezone overlap." Turn that statement into a specific shared schedule before day one. Put the agreed hours beside the manager's and reviewer's availability.

For your onboarding plan, assign your team the work it controls: system access, product context, first assignments, and feedback. Confirm with Opus who handles each administrative question and when to contact placement support.

Bring a short role charter to the hiring conversation. Include the day-90 outcome, the first small assignment, and the systems the hire must use. Add the name of the person who will review their work.

Before the start date, check that the internal manager and provider contact have the same plan. The hire should arrive knowing who they report to, what they will work on first, and where to ask for help.

Talk to Opus about a role.

<!-- File not saved: the workspace is read-only. Build rendering was not checked. -->