30/60/90-day onboarding for remote first companies hiring

What should a busy buyer put in the plan?

Give the new hire a named manager, a first assignment, and a written definition of acceptable work before they start. Build the 30/60/90-day plan around tasks the role will own.

For a developer, that might mean a small reviewed fix, followed by a bounded feature, then responsibility for a defined part of the product. For an operations hire, it might mean shadowing a recurring process before running it with review.

Use the milestones below as a starting template. Adjust them for seniority, system complexity, and the work you can safely assign.

Keep the plan in a shared document that both the manager and hire can edit. Record each milestone's acceptance criteria, reviewer, and due date. Link to the work itself so the review does not depend on memory.

Prepare access and the first assignment

Before the start date, ask the manager and technical lead to walk through the first task. Identify every system it requires and the person who can approve access.

Prepare individual accounts and role-appropriate permissions. Confirm the approved device and sign-in process. Keep passwords and secrets out of the onboarding document.

The welcome message should tell the hire when to join, whom to contact, and what to do if access fails. Include a backup contact in case the manager is absent.

Choose a first task with a clear finish. "Learn the codebase" gives the hire no way to judge progress. "Fix this validation error, add a test, and submit the change for review" gives both sides something to inspect.

For remote first companies hiring now, this preparation belongs alongside the final interviews. Reserve reviewer time before committing to a start date.

Write the first ticket before the start date

A useful first ticket includes the reason for the change, the expected behavior, and the person who will accept it. Add a link to a similar completed task. State which files or systems are in scope and where the hire should stop to ask for help.

For example, ask a developer to correct an error message in a test environment. Explain how to reproduce the error and what the user should see afterward. Require the usual review and tests. Keep release approval with the person who already owns it.

If the hire finds that the issue is larger than expected, let them pause and document the finding. Discovering a hidden dependency is useful work. The manager can then narrow the task or choose another starting point without treating the change as a failure.

Use days 1–30 to establish a working routine

Start with the product, the customer, and the team's current work. Explain what the hire's role owns and which decisions need approval.

Assign a colleague who can answer routine questions. Keep performance feedback with the manager so the hire knows where formal decisions sit.

For onboarding remote developers, have the hire run the application and tests, then follow a small change through review. Explain how releases work and who can approve production access. Use a low-risk task before assigning work that could affect customer data.

For a nontechnical role, use the same pattern. Walk through a real task, explain the quality checks, and let the hire complete a bounded piece with review.

At the day-30 meeting, inspect the finished work together. Ask which instructions were wrong, which access requests stalled, and which decisions were hard to make. Update the plan from those answers.

Avoid treating attendance at training sessions as proof of readiness. Ask the hire to show how they would complete the task or handle a common exception.

Use days 31–60 to expand responsibility

Choose an assignment that requires the hire to make decisions within a defined scope. Write down the boundaries and name the reviewer before work begins.

A developer might own a small feature from clarification through release preparation. An operations hire might run a recurring report and explain an unexpected result.

Ask for a short plan before execution. Review the proposed approach early enough to correct misunderstandings without discarding finished work.

Reduce routine check-ins when the work supports it. Keep a reliable way to raise blockers. A remote first team should spell out which issues need an immediate message and which can wait for the next review.

At day 60, compare the result with the original acceptance criteria. Record where the hire worked independently and where help was still needed. Agree on the next assignment using that evidence.

Leave a written handoff between working hours

Give the hire a simple update format: work completed, the next step, and any decision needed from someone else. Link to the task and name the person whose answer is needed. Agree where these updates belong so they do not disappear into private messages.

When the manager responds, record the decision on the task itself. A colleague should be able to resume the work without replaying a meeting. For remote new hire onboarding, review an actual handoff together and fix any unclear wording before the next assignment.

Use days 61–90 to confirm ownership

Give the hire a defined area of recurring responsibility. Specify the expected output, the people who depend on it, and the decisions that require escalation.

For an engineer, ownership might include planning a change, responding to review, and maintaining the related documentation. Add operational duties only after the required training and access approvals.

Ask the hire to improve one onboarding instruction that caused confusion. This gives the next person a tested explanation and lets the manager see how well the hire understands the process.

Close the day-90 review with written decisions. Record what the hire now owns, what still needs review, and the next work goals. If a milestone remains unmet, name the corrective action and the next review date.

What does hiring data tell you about the schedule?

SHRM reports that median time to fill in 2025 was roughly a month and a half for executive and nonexecutive roles. Its measure runs from job requisition to offer acceptance. SHRM's 2025 recruiting overview describes that recruiting interval.

Keep offer acceptance, the first day worked, and readiness for independent work as separate dates in your plan. A recruiting benchmark does not establish when someone can own your release process or complete your month-end work.

Start the onboarding checkpoints from the first day worked. Keep pre-start preparation on a separate checklist, with its own owners and deadlines.

Track the delays your team can fix

Use a short record of onboarding events:

• When the hire could use the systems required for the first task.
• When the first assignment was submitted and reviewed.
• Which blockers required help from another team.
• When the manager accepted the work against the agreed criteria.

These are proposed internal measures. Set targets from the role and your team's capacity.

Record waiting time separately from task time. If a developer waits for repository access, the manager should see that delay before drawing conclusions about delivery.

Use the same care with review queues. A finished task waiting for approval is a different problem from work that repeatedly misses the written requirements.

Review evidence before changing the deadline

At each checkpoint, ask the hire and reviewer to explain the same piece of work. Look for agreement on what was requested, what changed, and why.

If the task grew during onboarding, revise the milestone openly. Record the added scope instead of quietly keeping the original deadline.

If the scope stayed stable but the work fell short, identify the specific gap. "Needs better communication" is too broad to act on. "Raise a dependency blocker when it threatens the agreed delivery date" describes a behavior the manager can review.

Keep the review small enough to use. A page of decisions and links to actual work is a practical starting point.

How should hiring models change nearshore onboarding?

Use the hiring model to decide which responsibilities need a written handoff. Keep work priorities and acceptance criteria attached to named people.

The table below is a buyer checklist. Confirm the actual division of work in the agreement.

Do not assume the person who handled recruiting will own onboarding support. Ask for the contact who will handle problems after the hire starts.

For a Latin American hire, document the working schedule using the person's actual location and agreed hours. Put the shared meeting window in the calendar and check it across seasonal clock changes.

Agree on how planned leave affects reviews and delivery dates. Ask the provider to confirm employment-related arrangements before making promises to the hire.

Match the plan to the work relationship

For a hire working inside your team, make the internal manager responsible for the backlog, feedback, and day-30 review. Ask the provider to confirm its separate support duties.

For an outsourced project, focus the plan on deliverables and acceptance. Ask who assigns work within the delivery team and who can approve changes in scope.

If you already selected a candidate, ask which onboarding services you still need. If you need help finding the person, include the recruiting-to-onboarding handoff in the buying discussion.

Keep the ownership document short. Each task needs a name, a due date, and a route for escalation. Resolve tasks assigned only to "the client" or "the provider" before the start.

What should you ask a provider before the hire starts?

Ask the provider to walk through the first working week using your actual role. A sample schedule is useful only if someone can explain who will carry it out.

Who owns each handoff?

Request named contacts for start-date coordination, employment questions, and service issues. Identify a backup for each contact.

Ask who confirms that the hire is ready to start and who tells your team if the date changes. Make sure the hiring manager receives that update directly.

Bring your own checklist to the discussion. Include equipment, account approvals, the first assignment, and the first review. Ask the provider to identify which items it owns.

What does the quote cover during onboarding?

Ask for the monthly charge and a written explanation of included services. Confirm responsibility for equipment, software seats, and any work required before the first day.

Ask when billing begins and how a delayed start is handled. Have the provider explain the steps for correcting an invoice or resolving a payroll question.

For internal planning, reserve manager and reviewer time separately. Ask each owner to confirm that capacity before agreeing to the start date.

What evidence will the manager receive?

Ask what candidate assessment information can be shared with the manager. Use it to choose an appropriate first assignment and decide where early review is needed.

For a technical role, ask how the assessed work relates to your stack and expected level of ownership. For a customer-facing role, ask how written and live communication were assessed.

Avoid turning the onboarding plan into another interview process. Use the first month to teach your systems and observe performance on real, bounded work.

What happens when progress stalls?

Agree on the escalation route before a problem occurs. Ask how to report a concern, who joins the discussion, and how the next action is recorded.

If a milestone is missed, inspect the cause with the hire. Check access, task clarity, reviewer availability, and the quality of the work.

For a skill gap, document the expected behavior and the support you will provide. For a blocked dependency, assign the fix to the person who controls it.

Ask how any replacement process handles the transition. Your checklist should cover work handover, access removal, equipment, and the next hire's start arrangements.

How should you evaluate reviews and location claims?

Use online reviews to identify questions worth asking. A complaint about slow support should prompt a walkthrough of the escalation process.

For teams based in New York, Houston, or Charlotte, ask who will be available during the hours when your manager reviews work. The office address alone does not answer that question.

Ask for a concrete example of a handoff document with private information removed. Review whether it names owners and records unresolved issues.

How should you assess Opus for this plan?

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

Use the same ownership checklist when discussing a role with Opus. Prepare the first assignment and proposed checkpoints before the conversation.

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

That gives your manager a clear task: own the work plan, review the output, and provide feedback. Ask Opus to confirm the separate support contacts and handoff steps for your placement.

Talk to Opus about a role.

Check the commercial details against your plan

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 role-specific written quote. Confirm how the agreed start date, equipment arrangements, and support responsibilities fit the quote.

Opus also states: "Every placement carries a lifetime replacement guarantee with no cap and no time limit."

Ask how to initiate that process and who coordinates the handover. Keep your own access checklist and work records ready for any transition.

Bring a usable role plan to the conversation

Prepare the role's first assignment, the manager's name, and the proposed day-30 outcome. Add the working hours and systems the hire will need.

For remote team onboarding, also name the person who will review the first deliverable. Confirm that person's availability before setting the start date.

By the end of the discussion, aim to have an owner for every pre-start task and a date for the first review. Carry those decisions into the shared onboarding document.

Talk to Opus about a role.

<!-- File not saved because the workspace is read-only. Automated checks were not completed; milestones are planning recommendations, not guaranteed outcomes. -->