A 30/60/90-day plan for onboarding remote developers

What should a busy buyer put in the onboarding plan?

Assign an engineering manager before the developer accepts the role. Give that manager time to prepare a first task, arrange access, and book reviews. A start date without an available reviewer leaves the new hire waiting for someone to help.

Use the schedule below as a planning template. Adjust the work to the role and your release process. The milestones are proposed checkpoints, not promises about how fast every developer should become productive.

Prepare the work before day one

Write a short role note that explains why you hired this person. Name the team, the product area, and the work you expect them to own. Include what they should leave alone until they have more context.

Choose a technical buddy who can answer setup questions and explain local conventions. The buddy should know who approves access and who reviews the first change. Assign a backup for days when that person is away.

Prepare these items before the start date:

• A device plan, including delivery and setup responsibilities.
• An access checklist with an approver for each system.
• A product walkthrough using a realistic customer task.
• A first ticket with acceptance criteria and a named reviewer.
• A shared calendar showing working hours and planned absences.
• A written route for reporting a blocker or security concern.

Keep privileged access separate from basic setup. Give the developer the permissions needed for the assigned work. Expand access through your normal approval process as responsibilities grow.

Test the setup instructions with someone who did not write them. Check whether they can find the repository, install the required tools, and run a test using approved credentials. Record who can fix each failed step. If equipment will arrive late, agree on permitted work and revise the first assignment before the start date.

Use days 1–30 for guided delivery

Start with the product. Show the developer what a customer tries to do, where that action appears in the code, and how the team detects failures. Then walk through a change from ticket to release.

The first task should be small enough for a reviewer to explain its full context. A contained bug fix or test improvement can work well. Avoid a ticket that depends on an unresolved design debate across several teams.

For example, choose a bug where a form accepts an invalid value. Ask the developer to reproduce it, add a failing test, and propose a fix. The reviewer can then discuss validation rules and user-facing errors using real code. Keep deployment supervised until the developer understands the release and rollback steps.

Ask the developer to record setup problems as they occur. Have the buddy check those notes and update the setup guide. That gives the team a usable record of where the next hire may get stuck.

Make asking for help part of the working agreement. A useful blocker message includes the task, expected result, actual result, and what the developer already tried. Tell them where to post it and who will respond. The manager should arrange backup coverage when the usual reviewer is unavailable.

At the day-30 review, inspect actual work together. Can the developer run the tests, explain the change, and respond to review comments? Can they find the owner of a dependency? Record what still needs support.

Use days 31–60 for a bounded feature

Choose a feature with a clear boundary and an available product contact. Ask the developer to write a short approach before building it. The note should explain expected behavior, dependencies, and how the team will test the change.

Let the developer drive the task while keeping review help available. Agree on when they should ask for help rather than spend more time alone. The manager should check whether decisions are waiting on another team.

Define the acceptance criteria before work starts. For a settings page, specify who can change each setting and what happens when saving fails. Identify any migration or support work that belongs in the ticket. This gives the developer a concrete basis for raising scope changes before the review.

Review how the work reached completion. Look at scope changes, test coverage, and communication around delays. A finished ticket gives useful evidence only when you understand its difficulty and the support it required.

Use days 61–90 to agree on ownership

Give the developer an area they can maintain within defined limits. Name the decisions they can make and the changes that still need approval. Ownership might cover a service, a workflow, or a set of customer-facing screens.

Ask them to update the relevant runbook and walk a teammate through it. Include routine maintenance and failure recovery. If the role includes on-call work, use supervised practice before assigning independent coverage.

Use a safe failure scenario to check readiness. Ask where they would look if a scheduled job stopped running, how they would assess customer impact, and whom they would contact. Practice in an approved test environment. Keep production changes subject to the team's normal access and review rules.

At the day-90 review, agree on the next quarter's work. Write down any remaining support needs and assign an owner to each. Avoid treating the review as a pass-or-fail judgment based only on how confident the developer sounds.

Give the developer the written review and space to correct factual errors. Include examples of work they can now handle alone and tasks that still need supervision. Use those distinctions to set the next assignment and decide which recurring onboarding meetings can end.

What does the data say about hiring and nearshore start dates?

SHRM's 2025 recruiting benchmark puts median time-to-fill at roughly a month and a half for executive and nonexecutive roles. It measures the period from opening a job requisition to offer acceptance. That endpoint comes before the developer's first working day. SHRM's 2025 recruiting findings.

Keep hiring dates and onboarding dates in separate fields. Track offer acceptance, the confirmed start date, and the point when required access works. Begin the 30/60/90-day plan from the agreed start date, then record any blocked days alongside it.

A recruiting benchmark cannot tell you when a developer will understand your codebase. Use evidence from your own team to set those expectations. Compare hires doing similar work, and account for differences in system complexity and reviewer availability.

Check overlap using the developer's city

Bogotá stays at UTC-5 without daylight saving time. Buenos Aires and São Paulo stay at UTC-3. Their time difference from US teams can change when US clocks change. IANA's South American time-zone records.

Mexico City stays at UTC-6 without daylight saving time, while Tijuana follows US daylight saving changes. Confirm the city before setting recurring meetings with a developer in Mexico. IANA's North American time-zone records.

Put the agreed hours in the onboarding document using named time zones. Reserve part of that overlap for code review and pairing. Keep routine status updates in writing so meetings have a clear purpose.

Confirm the working calendar with the developer and the party responsible for employment administration. Check who will review code during planned absences. A milestone scheduled for a week without an available reviewer needs a different review date.

Measure progress with work the team can inspect

Use a small record that distinguishes completed work from waiting time.

Avoid ranking new hires by lines of code or raw ticket counts. Review the behavior you need: understanding requirements, testing changes, explaining risks, and asking for help with enough context.

Keep the record brief enough to update during an ordinary manager check-in. Link to the work instead of copying every review comment. When a problem repeats, add the example and the next step. Close the item when the developer demonstrates the skill, rather than carrying an old concern into every review.

How should onboarding differ across hiring models?

Choose the hiring model with a clear view of who will manage the work. Then put each onboarding responsibility against a named person. A contract for recruiting or payroll does not tell your engineering team who will explain the architecture.

Use these questions to divide responsibilities before signing:

For an embedded developer, use the same definition of done as the rest of the team. Include them in design discussions relevant to their work. Give them access to the decisions behind a ticket so they can assess tradeoffs.

For an outsourced project, focus onboarding on the agreed scope and interfaces. Define the environments the delivery team can use and the evidence needed for acceptance. Include a handover plan for the people who will maintain the result.

If you hire Latin American developers through more than one model, keep a common technical checklist. Add separate administrative tasks where the agreements require them. This gives managers a consistent way to prepare without assuming every worker has the same arrangement.

Match the plan to seniority

A senior developer still needs product context, access, and a clear account of past design decisions. Ask them to assess a bounded problem before proposing wider changes. Review whether their approach fits the system's constraints.

A junior developer may need smaller tasks and more frequent pairing. Make review time explicit in the manager's schedule. Do not assign a buddy whose workload leaves no room to help.

For either level, judge the person's work directly. A degree from one of the best Latin American universities does not explain how your deployment process works. Include the same setup checks and product walkthrough for every hire.

What should you ask a provider before the developer starts?

Ask for a written handoff plan that separates administrative duties from technical onboarding. Use names and dates. A general promise of support leaves too much open when a laptop is late or an account cannot be approved.

Confirm who will resolve each blocker

Bring these questions to the call:

• Who confirms the first working day with the developer?
• Who orders the device and checks that it is ready?
• Who handles employment and payroll questions?
• Who tracks unresolved setup tasks before the start?
• Who receives a performance concern, and who decides the next step?
• What happens if the developer, manager, or assigned buddy is unavailable?

Ask the provider to identify any duties it expects your team to handle. Give those tasks internal owners before committing to the start date.

If the provider describes onboarding support, ask what that includes in practice. Request the steps, meeting cadence, and contact responsible. Keep those commitments with the agreement so the manager can refer to them later.

Define what the first task requires

Share a sample ticket that reflects the role. Explain the stack and the test environment. Include the communication the task requires, such as discussing an unclear requirement with a product manager.

Ask what evidence from selection is relevant to that work. A coding exercise may show one skill while leaving system knowledge for onboarding. Use the handoff to identify where the manager should spend time first.

Confirm your rules for AI tools before sharing repository access. Specify approved accounts, allowed data, and review requirements for generated code. Ask the developer to demonstrate the workflow using a permitted example.

Agree on a response when progress slips

Document the expected work and the support you promised. If a milestone slips, review both. Check access delays, changed requirements, and reviewer availability before deciding that the hire lacks the required skill.

For a skill gap, choose a specific corrective task and review date. Explain what acceptable work looks like. Keep feedback close to the example so the developer can act on it.

For a team blocker, assign an internal owner and reset the affected milestone. Preserve the original dates in the record. That helps the next review distinguish slow delivery from time spent waiting.

If a replacement becomes necessary, plan the handoff with your engineering and security owners. Identify unfinished work, transfer documentation, and arrange access changes through the normal process. Ask the provider how it will coordinate timing. Keep a named internal owner responsible for customer work while the role is being filled.

This site is an Opus-owned reference; recommendations are editorial.

Talk to Opus about a role.

How does Opus fit into the onboarding plan?

Opus states: "The client chooses the finalist and manages day-to-day work." Assign an internal engineering manager who can turn the role requirements into tickets and review the results. Keep that manager involved before the developer starts.

For the commercial arrangement, Opus states: "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."

Ask for a written quote and a handoff plan for your role. Confirm equipment responsibilities, the start date, and the escalation contact. Add those details to the same readiness checklist your manager uses for access and first-week work.

Opus states: "Every placement carries a lifetime replacement guarantee with no cap and no time limit." Ask how a replacement request would proceed for your account. Include the knowledge-transfer steps your team would need if a hire changed.

Keep the onboarding decision concrete. Before confirming the start, the manager should be able to point to the first ticket and its reviewer. The developer should know the agreed hours and where to ask for help.

Bring the role description, intended start date, and proposed first assignment to the conversation. Use them to agree on who will complete each task before day one.

Talk to Opus about a role.

<!-- File saving and site build checks were skipped because this session has read-only filesystem access. The page has not been saved to the requested path or validated in the site build. -->