A 30/60/90-day plan for remote first companies hiring

What should a busy buyer put in the plan?

Give the new hire a manager, a first assignment, and written expectations before their first working day. Build the plan around work your team can review. A completed training checklist should lead to a task the person can perform.

Use the schedule below as a planning template. These are proposed checkpoints, not measured averages or promises of full productivity.

Start the clock on the first working day. Keep offer acceptance, employment setup, and equipment delivery as separate dates in your hiring tracker.

For remote first companies hiring now, the immediate task is to reserve manager time. Put the first meetings and review slots on the calendar before promising a start date. Assign a backup reviewer when the manager will be away.

Prepare the work before arrival

Create a short onboarding document that the hire can use without asking where everything lives. Include:

• The role's purpose and the work the person will own.
• The manager, buddy, and contact for access problems.
• Links to the task tracker, team documents, and approved communication channels.
• Shared work hours and expected response times.
• The first assignment, its reviewer, and its acceptance criteria.
• Dates for the first feedback conversation and milestone reviews.

Have IT check the equipment and account setup. Grant access according to the role, and use individual accounts with the required security controls. Assign an owner to every unresolved request.

Keep the first assignment small enough to review without a long chain of dependencies. For a developer, that might be a contained bug fix. For an operations hire, it might be a recurring report with a known reviewer and sample output.

Write acceptance criteria before assigning the task. For the bug fix, describe the faulty behavior, the expected behavior, and the test that should demonstrate the change. For the report, specify the reporting period, required fields, and person who checks the totals. Attach an example if the team already has one.

Ask the reviewer to read the assignment before the hire starts. If the reviewer cannot explain what would make the work acceptable, revise the task.

Use days 1–30 for supported delivery

On the first day, walk through the product or service from the customer's perspective. Explain how the team's work affects that experience. Then show the hire where decisions and tasks are recorded.

Schedule a brief daily check-in during the first week. Ask what they tried, where they got stuck, and whose help they need. Reduce the meeting frequency when they can find answers and make progress without waiting.

For onboarding remote developers, have the engineer set up the environment and run the existing checks with a teammate. Walk through a recent change from request to review and release. Explain who approves access to production and how the team handles a failed release.

Give the buddy a narrower job than the manager. The buddy can explain team habits, find the right document, and introduce colleagues. The manager sets priorities and gives performance feedback. Tell the hire which person to contact when those needs overlap.

By day 30, review a small piece of completed work. Ask the hire to explain the decisions behind it and the feedback they used. Record any access or documentation problems that slowed delivery.

Use days 31–60 for broader ownership

Give the hire a bounded assignment with a clear outcome. Examples include a small feature, a monthly reporting cycle, or responsibility for a defined support queue.

Agree on the scope before work begins. Write down what the hire can decide alone and which decisions need review. Include a contact for dependencies outside the team.

For example, a developer might choose how to implement a change within an existing service. A change to a shared API might still need approval. An operations hire might correct a report but need approval before changing the underlying business rule. Put those boundaries beside the assignment.

At the day-60 review, examine how the work moved through the team. Did the hire raise blockers while there was time to respond? Did reviewers give useful feedback promptly? Were acceptance criteria stable enough to guide the work?

Change the next assignment based on those answers. If the person spent much of the month waiting for access, resolve that delay before drawing conclusions about their pace.

Use days 61–90 to confirm ongoing responsibility

Ask the hire to own a work cycle from planning through review. Keep the team's normal approval and security controls in place.

For a developer, this could mean scoping a modest change, coordinating dependencies, submitting it for review, and checking the result after release. Independent delivery still includes code review and help from colleagues.

Use the day-90 conversation to agree on the next area of ownership. Record the work the person can handle, the support they still need, and the next deliverable. Share the written assessment with them so they can correct misunderstandings.

Avoid a vague verdict such as "needs more confidence." Describe the behavior you want to see: propose a solution before the planning meeting, identify a dependency earlier, or check the result after release. Attach the expectation to the next assignment so both sides can assess progress.

If you are still defining the role, bring that first assignment and review schedule to the hiring conversation.

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

Talk to Opus about a role.

What does the data tell you about nearshore onboarding timing?

SHRM describes median time-to-fill in 2025 as roughly a month and a half for executive and nonexecutive positions. It measures the period from job requisition to offer acceptance. That endpoint precedes the work measured in this onboarding plan. SHRM recruiting benchmark.

Track recruitment and onboarding separately. Your hiring tracker should show when the role opened, when the candidate accepted, and when they started. Your onboarding record should show when they completed the agreed work.

A faster accepted offer does not establish an earlier date for independent delivery. Notice periods, equipment readiness, and your team's review capacity still need their own plan.

When comparing hiring proposals, ask each provider to define the start and end of its timing claim. An accepted offer, a signed agreement, and a first working day are different events. Use the same event when comparing timelines, then add your own readiness checks.

Measure progress through accepted work

Choose a small set of measures that the manager can maintain during normal work:

Avoid using message counts or meeting attendance as evidence of productivity. Read the work and the feedback attached to it.

For a remote first team, record decisions where absent teammates can find them. Give the hire a clear way to ask questions without guessing who is online. A short task update should explain progress, the next step, and any help needed.

Keep the scorecard in the existing task tracker or onboarding document. Link to the work rather than asking the hire to create a second report. At each review, record the manager's decision and any change to the next milestone.

Compare similar assignments when reviewing progress across hires. A contained fix and a change that needs several teams do not carry the same dependencies. Record scope changes so a revised deadline does not look like an unexplained miss.

Plan shared hours for Latin American hires

Mexico City uses UTC-6 without seasonal clock changes. Bogotá uses UTC-5, while Buenos Aires and São Paulo use UTC-3 without seasonal clock changes. IANA North America time-zone data, IANA South America time-zone data.

Agree on actual working hours with the hire. A city and time-zone label help schedule meetings, but they do not establish someone's availability.

Put pairing sessions, manager check-ins, and reviews inside the agreed shared hours. Check recurring invitations across clock changes. Add local holidays and planned leave to the team calendar before setting milestone dates.

For remote team onboarding, also explain what happens outside shared hours. State where to leave a routine question and how to raise an urgent issue. Confirm who covers each case.

How do the hiring models change onboarding duties?

Use the hiring model to identify who handles each task. Then put named owners against those tasks in the agreement and your internal plan.

The table below is a buying checklist. Confirm each provider's actual scope before relying on it.

Ask who acts when a laptop fails to arrive or the hire cannot access a required system. A service category alone does not answer that question.

For each task, name the person who performs it and the person who resolves delays. The hiring manager can own readiness without personally creating every account.

Keep technical onboarding inside the team that owns the systems

The team responsible for your software should explain its architecture and review rules. Ask a senior engineer to choose the first task and act as its reviewer.

Give the hire a map of the services they will touch. Explain the test setup, release process, and rules for handling customer data. Show an example of a useful pull request description and the checks required before approval.

If the role uses AI tools, explain which tools are approved and what information may be entered into them. Have the hire follow your team's review process for any generated output.

Apply the same approach to other roles. A finance hire needs the approval rules and reconciliation process. A marketing hire needs access boundaries and a named approver for spending or publishing.

Make the post-acceptance handoff explicit

Before the candidate accepts, ask for the handoff steps in writing. Confirm who communicates the start date, arranges equipment, and answers payroll questions.

Send the hiring manager's plan to the provider contact where relevant. Keep work feedback specific: name the assignment, explain the expected result, and describe the gap.

If a replacement becomes necessary, prepare a handover and access-removal plan. Confirm who owns each step before changing accounts or transferring work.

Keep employment records and sensitive personal details in the systems intended for them. The shared onboarding plan needs task status and contact names. Give each participant access to the information required for their role.

What should you ask a provider before the start date?

Use the same questions for each proposal. Ask for written answers that your manager, IT team, and finance team can act on.

Who owns readiness?

Ask who checks the contract status, equipment delivery, and first-day schedule. Request a contact for unresolved items and a backup if that person is away.

Define what must be ready for the hire to begin useful work. If a required system will take longer, agree on a suitable paid assignment for the interim.

Walk through a concrete failure case before signing: the hire arrives, but the laptop does not. Ask who contacts the hire, who resolves delivery, and who approves interim work. Put those names in the readiness checklist.

What does support include after placement?

Ask whether the provider schedules check-ins and who attends them. Confirm how work concerns reach the right person.

Separate the manager's feedback from employment or payroll questions. Give the hire a clear contact for each, so a pay issue does not sit in a technical support queue.

Ask what happens when the regular provider contact is away. Record the backup contact and the channel for an unresolved issue. Include the hire in any discussion that changes their work expectations.

What schedule has the candidate agreed to?

Confirm the working hours in the candidate's location and the manager's location. Discuss recurring meetings, planned leave, and any on-call requirements before finalizing the role.

Ask how changes to the schedule are agreed. Avoid adding late meetings as an informal condition after the person has started.

What will the monthly bill cover?

Request a written quote for the actual role, seniority, and location. Check how equipment, approved expenses, and changes to scope are handled.

Ask when billing begins and what happens if the start date moves. Give finance the agreed terms before the first invoice arrives.

How will you handle a missed milestone?

Describe the concern using actual work. Ask the provider what support it can supply and which decisions remain with your manager.

Set a dated follow-up with a specific deliverable. Keep a record of the support promised and delivered. Give the hire the same written expectations that the manager uses.

For example, if a report contains errors, identify the incorrect fields and show an accepted example. Agree on who will review the next version. If the hire lacked access to the underlying data, resolve that before assigning another deadline.

What does a replacement commitment cover?

Ask how to request a replacement, what costs apply, and how the handover works. Confirm the treatment of ongoing work and access during the transition.

Keep those terms separate from your onboarding scorecard. A replacement commitment does not define whether the first assignment was clear or whether the reviewer was available.

What does Opus contribute to the plan?

Opus states: "The client chooses the finalist and manages day-to-day work." Assign your hiring manager the first task, feedback schedule, and milestone decisions.

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."

Published dollar rates: Not published. Ask for a written quote for your role before setting the hiring budget.

Opus also states: "Every Opus placement works with US timezone overlap." Confirm the actual shared hours with the finalist and place the first review sessions inside them.

Opus states: "Every placement carries a lifetime replacement guarantee with no cap and no time limit." Ask how a replacement request and handover would work for your team.

Use the hiring conversation to settle the division of work. Ask which pre-start tasks Opus will handle for the proposed placement and which tasks your team must complete. Record the answer beside each task owner.

Bring a short role plan to the conversation: the first assignment, the person reviewing it, and the responsibility you want the hire to own by day 90. Include the required systems and working hours. Those details give the selection and onboarding discussions the same definition of success.

Talk to Opus about a role.

<!-- File not saved: filesystem access is read-only. Save this page to the requested output path before building. -->