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

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

What should a busy buyer put in place first?

Give the hire a named manager, a working setup, and a first assignment before filling the calendar with introductions. Define what the developer should be able to do at each review. Reserve time for the people who will help them get there.

Use the plan below as a starting point. These are proposed milestones, not measured averages or promises that every developer will reach the same stage on schedule.

Start the clock on the first working day. Record planned leave and any period when the developer cannot work because access or equipment is blocked. Keep the original dates visible, but explain delays in the review.

Prepare the work before the start date

Create one onboarding document with links to the repository, setup guide, team calendar, and current project. Add the manager's name and the technical buddy's contact details. Tell the developer where to ask a question and who steps in when the buddy is away.

Choose a first task that touches the real workflow without exposing the hire to an uncontrolled release. A small bug fix or test improvement can work. Write down the expected behavior and how a reviewer will check it.

Avoid an assignment that depends on an unresolved design debate. The developer should be learning the system, with a clear route to completing the task.

Have IT confirm equipment delivery and account setup. Assign an owner to each approval. Use your normal identity checks and security controls, including multifactor authentication. Keep secrets out of welcome emails and shared onboarding notes.

Use days 1–30 to establish a working routine

Walk through the product from the user's perspective before explaining its services and repositories. Show the developer which workflow their team owns and what happens when it fails.

Ask them to run the project and its relevant tests. Have them note any setup step that differs from the documentation. Fix those instructions as part of onboarding, with a reviewer checking the change.

Use pairing time to explain how the team makes decisions. Show a recent pull request with useful review comments and a past incident with a clear follow-up. Explain who approves a release and where rollback instructions live.

At the first milestone review, ask the developer to demonstrate the change and explain its limits. Review the support they received as well as the work they completed.

A missed goal needs a specific explanation. "Still getting up to speed" gives neither the manager nor the developer a useful next step. "Test credentials arrived late, and the change is waiting for review" tells the team what to fix.

Use days 31–60 to test ownership of a bounded task

Assign a feature or service change with clear acceptance criteria. Ask the developer to propose the work before starting it. The plan should identify dependencies, likely risks, and the person who can resolve each open question.

Keep normal code review in place. Let the developer handle follow-up questions and update the work plan when requirements change.

For example, a backend hire might own a small API change through testing and release. A frontend hire might own a form change, including error states and keyboard use. Choose work that matches the role you hired for.

At the review, examine where help was needed. Distinguish useful collaboration from repeated gaps that need coaching. Agree on the next assignment and any training before increasing scope.

Use days 61–90 to agree on ongoing responsibility

Give the developer a defined area to maintain. State the decisions they can make alone and those that need review.

Ask them to leave operating notes another teammate can use. Where relevant, include release steps, known failure modes, and the escalation contact. Test those notes by having someone else follow them.

The final review should produce a written decision about future scope. Record what the developer can own, which skills need work, and what the manager will provide.

Keep on-call duties separate from a calendar milestone. Require the relevant access, training, and incident practice before assigning that responsibility.

If you are choosing a hire now, talk to Opus about a role. This site is an Opus-owned reference; recommendations are editorial.

What does the data say about the hiring and onboarding clocks?

SHRM's 2025 recruiting benchmark puts median time to fill at roughly a month and a half for executive and nonexecutive positions. It defines that period as job requisition to offer acceptance. That clock ends before a developer necessarily starts work. SHRM, State of recruiting 2025.

Use that definition when reviewing a hiring forecast. Ask whether a quoted timeline ends at candidate delivery, offer acceptance, or the first working day. Put each date in the staffing plan.

Then add your own readiness checks. An accepted offer does not confirm that a laptop has arrived, security has approved access, or a reviewer has time available.

Do not use the recruiting benchmark as a forecast for engineering output. Set the first assignment against your codebase and the hire's role. Track what actually happens after the person starts.

Measure delays the team can act on

Keep a short record alongside the onboarding plan:

• When the developer could first run the project.
• When the first reviewable change was submitted.
• How long that change waited for review.
• Which blockers needed action from another team.

These measures help locate a delay. They should not become quotas for commits or pull requests. A small change to a sensitive service may need more discussion than a larger change elsewhere.

Review the record with the developer. Ask whether instructions were clear and whether support arrived when promised. Compare performance against the agreed assignment, including any scope changes.

Check shared hours against actual locations

Bogotá stays at UTC-5 without daylight saving time. São Paulo stays at UTC-3 and does not observe daylight saving time. The difference from a US team's local clock can change when that team changes its clocks. IANA time-zone rules for South America.

Mexico City stays at UTC-6 without daylight saving time. Tijuana follows US daylight-saving dates. Confirm the city instead of setting a schedule based only on the country. IANA time-zone rules for North America.

Put both local schedules in the onboarding document. Reserve a shared window for pairing and review, and define how the team handles questions outside it.

Before recurring meetings cross a clock change, check their local times. Also agree on holiday coverage with the developer and the employment contact before assigning release work.

How do nearshore hiring models change onboarding ownership?

Choose the model based on the work you expect someone else to handle. Ask who owns each task in the table before signing. Treat these as responsibilities to settle in the agreement, since service scope can differ.

If you want an individual developer embedded in your team, name the internal manager before the search ends. A provider contact can handle an employment question, but your team still needs someone who can explain the code and approve work.

If you are buying a delivery outcome, define who onboards the provider's team and how knowledge returns to your staff. Include documentation and handoff requirements in acceptance criteria.

Separate employment setup from engineering readiness

Maintain distinct checklists for employment and technical work. Connect them through a shared start date and named owners.

The employment checklist should identify who confirms the agreement, pay process, benefits questions, and leave procedures. Ask the provider to explain any steps required before work begins.

The engineering checklist should cover device readiness, approved tools, access, setup, and review support. The manager should know which items are complete without requesting sensitive employment records.

If you plan to hire LatAm developers across several teams, use the same checklist structure. Change the repository, first assignment, and reviewers for each role.

Budget for the manager's part of the work

Reserve capacity for pairing, reviews, and feedback. Name a backup reviewer when the primary reviewer has a release or planned leave.

Avoid assigning the new hire a task whose only knowledgeable owner is unavailable. Move the assignment or arrange support before the start date.

For a senior LatAm developer, reduce basic instruction where it is unnecessary. Keep product context and system-specific decisions in the plan. Seniority does not tell someone why your team chose a particular data model or deployment process.

What should you ask a provider before the developer starts?

Ask questions that produce a name, a date, or a written responsibility. "Do you help with onboarding?" leaves too much room for different expectations.

Confirm the start and access process

Ask who confirms the first working day and what must happen beforehand. Check whether equipment delivery, notice commitments, or employment steps could affect that date.

Agree on who owns the device and who handles repair or replacement. Confirm the process for installing required security software.

Ask how access is removed when the engagement ends. Your internal owner should know which accounts, tokens, and devices require action. Keep that process ready from the start.

Confirm the support path

Request the contact for pay, benefits, and leave questions. Separately name the person who receives concerns about attendance or performance.

Agree on how the provider and manager share information. Keep sensitive employment details within the appropriate channels.

Ask what happens when the developer reports a problem with the client team. There should be a route for raising blocked access, conflicting instructions, or concerns about workload.

Confirm how progress and problems will be handled

Share the proposed milestones before the start date. Ask the provider to distinguish any training it provides from training your team must deliver.

Agree on a process for a missed goal:

1. Review the assignment and evidence with the developer.
2. Identify whether the cause is access, scope, support, or a skill gap.
3. Assign the next action to a named owner.
4. Set a review date and document the result.

Avoid waiting until the final milestone to discuss a repeated issue. Give feedback while there is still a specific task the developer can improve.

Confirm the terms of any replacement

Ask what triggers a replacement search, who starts it, and what fees or conditions apply. Ask how the current engagement ends and what handoff the agreement requires.

Keep your own code and documentation accessible to the team. Require work to live in approved repositories throughout the engagement.

A replacement still needs access, product context, and review time. Keep those tasks in the staffing plan when estimating the effect of a change.

Where does Opus fit in this onboarding plan?

Opus reports: "The client chooses the finalist and manages day-to-day work."

That division puts technical onboarding with your engineering team. Name the manager, choose the first assignment, and reserve reviewer time before the developer starts.

Opus reports: "Every Opus placement works with US timezone overlap." Confirm the actual shared hours for the developer and team. Include those hours in the plan alongside the contact for urgent questions.

For preparation before the start, Opus reports: "Every Opus placement completes a 6-module internal AI certification before day one." Your team should still explain its approved tools and rules for handling code or customer data.

For cost planning, Opus reports: "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."

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

Opus also reports: "Every placement carries a lifetime replacement guarantee with no cap and no time limit." Ask how the replacement process would work for your engagement, including the handoff and proposed start date.

Bring a short role outline to the conversation. Include the system the developer will work on, the manager's name, and the first task you expect them to complete. Add the shared hours and the proposed day-90 responsibility.

Those details give the hiring conversation a concrete scope and give your manager a plan to use when the developer arrives.

Talk to Opus about a role.

<!-- Not saved to disk: this session has read-only filesystem access. Automated length and format checks were not run. -->