Build a staff augmentation business plan for days 30/60/90

What should your first 90 days accomplish?

Give the hire a defined area of work, a manager who can make decisions, and a way to prove progress. Build the onboarding plan around the work you need done.

For an engineering hire, that might mean taking ownership of a small service or clearing a defined maintenance backlog. For an operations hire, it might mean running a recurring process with documented checks. Choose a result the manager can inspect.

Treat the milestones below as a planning template. They are proposed review gates, not promises about how fast every hire will become productive.

Define whether those dates mean calendar days or working days. Put actual review dates on the calendar once the start date is confirmed. Account for planned leave and holidays when choosing the work due at each gate.

Write the business case before opening the role

A useful staff augmentation plan begins with a specific gap. "We need more engineering capacity" leaves too much open. "We need someone to own maintenance for the billing integration" gives the manager a starting point.

Record the work that is waiting, its business effect, and the skills needed to handle it. Explain what the existing team will stop doing or hand over. If you cannot name work to transfer, clarify the role before interviewing.

Keep the budget beside the scope. Include the quoted monthly cost, equipment, software seats, and internal onboarding time. Ask which costs begin before the first working day and what happens if the start date moves.

The budget owner should approve the full commitment they are making. Put any assumptions about renewal or exit terms in the same document.

Add a boundary around the role. An engineer hired to maintain an integration should know whether new product development is also expected. List work that needs separate approval, such as taking on another service or joining an on-call rotation. This gives the manager a way to discuss new requests without quietly changing the job.

Prepare the first assignment before day one

Choose a task with a clear finish and limited dependencies. Give it acceptance criteria and a named reviewer. Avoid making the new hire's first result depend on an unresolved product decision.

For example, a proposed first assignment could be fixing a reproducible defect in a service the person will later help maintain. Supply the expected behavior, test steps, and release process. The reviewer should know when to expect the change.

Before the start, confirm:

• The manager and a backup contact are available.
• Equipment and required accounts are ready.
• Access approvals match the person's initial duties.
• The first assignment has acceptance criteria.
• Shared working hours and review meetings are booked.
• The hire knows where to report a blocker.

Grant access through your normal approval process. Use individual accounts and the permissions needed for the assigned work. Avoid handing over broad production access merely to speed up setup.

Prepare a fallback assignment that uses approved test data or a development environment. If an account is delayed, the hire can still learn the relevant workflow. Keep the blocked task visible, with an owner for restoring access. A fallback should not hide a setup problem that will stop later work.

Use days 1–30 to establish a working baseline

Start with the product, the users, and the part of the system the person will touch. Pair that context with real work. A long reading list does not show whether someone can navigate the project.

Ask the hire to run the relevant workflow, trace a typical request, and complete the first small task. Have them note setup errors as they encounter them. Those notes give the manager evidence of friction the team can fix.

At the day-30 review, inspect the work and discuss how it got done. Could the person identify the right reviewer? Did they raise a blocker while someone could still help? Were the acceptance criteria clear?

Use a written example of acceptable work during this period. Show a previous ticket with its review comments, tests, and release notes. Explain which parts are team requirements and which were specific to that task. The new hire should not have to infer your quality bar from scattered feedback.

If access consumed much of the month, revise the next milestone. Record the delay separately from feedback about the person's skill.

Use days 31–60 to test delivery

Give the person a bounded assignment with enough scope to require planning. Ask them to explain dependencies and propose a delivery sequence before work begins.

Keep normal code review, quality checks, and release controls in place. Independence means progressing within those controls and asking for help at the right time.

Review the estimate against the actual work. Discuss scope changes, waiting time, and rework separately. A missed date has different implications when a dependency changed than when the task was misunderstood.

For the billing integration example, the next assignment might be adding a missing error path with tests and support notes. Agree on expected behavior before implementation. Ask the engineer to identify the person who will approve the release and the evidence that approval requires.

Use the day-60 meeting to choose the next area of ownership. Be specific about decisions the person can make and decisions that still need approval.

Use days 61–90 to agree on ongoing ownership

Have the hire manage the agreed work through a full cycle. That might include planning, delivery, and support after release. Select the cycle that fits the role.

Review whether another teammate can follow the notes and take over during an absence. Ask the person to explain unresolved risks and the next work they would prioritize.

For a recurring operations task, inspect a completed run and its exception log. For engineering work, review the released change and any follow-up defects. Use evidence from the actual role instead of giving every hire the same activity checklist.

At day 90, record the decision: continue with the same scope, expand it, or address a defined performance concern. Assign an owner and date to any follow-up.

If you expand the role, update its scope and review the budget. Confirm that the person has the access and support needed for the added work. Keep the original milestones in the record so everyone can see what changed.

What does the hiring data tell you about the schedule?

SHRM's 2025 recruiting benchmark puts median time-to-fill at "roughly a month and a half" for both executive and nonexecutive roles. Its measure runs from job requisition to acceptance of an offer. SHRM's 2025 recruiting analysis.

That measure ends before onboarding begins. Use it as context when planning a search, while keeping your target start date and delivery milestones separate.

Track these dates in your hiring plan:

Ask any provider quoting a hiring timeline to define its start and end points. Confirm whether it measures candidate presentation, acceptance, or the first day worked. Ask which roles and completed searches the figure covers.

Do not subtract one provider's hiring figure from a broad benchmark and treat the difference as guaranteed delivery time saved. Your interview schedule, candidate availability, and internal setup still need their own dates.

Work backward from a business deadline using those separate stages. If a release requires an experienced owner, identify when that person must demonstrate the relevant work. Then check whether the proposed start leaves enough room for your onboarding tasks. Move the scope or deadline when the plan depends on skipping required reviews.

Measure progress with work the manager can inspect

Use a small scorecard throughout onboarding. Record completed assignments, quality feedback, and unresolved blockers. Link each entry to a ticket, review, or work sample where possible.

Avoid a score based only on activity. Attending meetings and finishing training can support delivery, but neither shows whether the person can complete the assigned work.

For an IT staff augmentation service, ask how candidate assessment relates to your stack and role. Then set your own acceptance criteria for the actual work. Keep training completion and work acceptance as separate entries.

Include the team's contribution in each review. Note when a reviewer was absent, a decision was late, or an environment failed. This gives the manager a fair basis for changing the plan.

Make each scorecard entry specific enough to discuss. "Needs better communication" gives the hire little to act on. "The release blocker was raised after the reviewer signed off" identifies an event. Agree on when the next blocker should be raised and where to record it.

How should you divide onboarding across hiring models?

Compare models by assigning duties before comparing quotes. The same day-30 work goal can apply across several arrangements, while the people responsible for getting the hire ready may differ.

Use this table to structure the discussion. Confirm every responsibility in the proposed agreement.

If you need someone inside your existing team, test whether you have the management time to support that arrangement. Assign a person who can answer questions and accept work.

If you need a vendor to own a project outcome, write that requirement into the engagement. Do not assume an individual hire's onboarding plan creates project-level delivery responsibility.

Check the handoff between recruiting and the working team. Give the manager the agreed role scope, interview findings relevant to the work, and any training commitments. Ask the hire to confirm their understanding of the assignment. Resolve differences before those expectations become part of a performance review.

Give each issue a named owner

Keep a short contact map with the onboarding plan. The hire should know who handles access, task decisions, and administrative questions.

Name a backup for approvals that can stop work. A manager's absence should not leave a new hire guessing whether to wait or proceed.

Ask staff augmentation companies to explain how they handle a placement concern. Agree on who receives the concern, what evidence they need, and when you will review next steps. Keep that process distinct from routine technical feedback.

When buying staff augmentation services, ask who maintains the contact map after the start. If the account contact or internal manager changes, update the plan and tell the hire. Record unresolved issues during the handoff so the new owner can act without restarting the discussion.

What should you ask before onboarding a nearshore or Latin American hire?

Ask the provider to walk through your actual role and proposed start date. A useful discussion should leave you with named owners and written answers.

Start with the conditions needed for the first assignment. If the hire will work on restricted systems, involve the internal security owner before committing to the schedule.

Confirm hours and handoffs

Ask for the hire's working city and proposed local schedule. Write the shared work window in both teams' time zones. Specify when reviews and urgent decisions need live contact.

Mexico City stays on UTC-6 without seasonal clock changes. Bogotá stays on UTC-5 without seasonal clock changes. US clock changes can therefore alter the gap between those cities and a US team. IANA's North America time-zone data, IANA's South America time-zone data.

Check recurring meetings across the dates covered by the plan. A meeting booked before a clock change may land at a different local hour afterward.

Agree on an asynchronous handoff format. A short note should state what is complete, what remains blocked, and who needs to act. Define how urgent issues are escalated outside shared hours.

Set expectations for response times within the agreed schedule. Distinguish a routine review request from an incident that needs immediate attention. Confirm any coverage outside normal hours before assigning it, including who approves the work and how the arrangement is documented.

Ask for the terms behind the quote

Use the same questions with each provider:

• What does the monthly quote include?
• Which charges fall outside it?
• When does billing start?
• How are equipment and software handled?
• Who resolves payroll or benefits questions?
• What happens if the hire or client needs to move the start date?
• What are the renewal, notice, and replacement terms?
• Who manages access removal and equipment return when the engagement ends?

Ask for answers in writing before approving the engagement. Keep the quote and onboarding plan together so the manager and budget owner use the same assumptions.

Agree on how a missed goal will be handled

Discuss a concrete case: the hire reaches day 30 without completing the first assignment. Ask what the provider would need to assess the concern.

Your manager should first document the task, support given, and observed result. Check whether the person had the required access and a clear definition of done.

If the issue is skill or role fit, describe it using work examples. If the issue is a missing internal decision, assign that decision to your team. Set the next review date while the details are clear.

Avoid waiting until day 90 to raise a concern that already blocks delivery.

How should you assess Opus against this plan?

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

Opus states: "The client chooses the finalist and manages day-to-day work." Build your plan with an internal manager who can own assignments and feedback.

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.

Use the conversation to test your proposed start date and responsibilities. Ask who will handle administrative issues while your team manages the work.

Talk to Opus about a role.

Bring a role outline that includes the first assignment and the work you expect the person to own by day 90. Include required shared hours and any access constraints.

Keep the day-30 goal small enough to review in detail. Make the day-60 assignment reflect the work you are hiring for. Use the day-90 decision to set the next scope and budget.

Before confirming the start, have your manager check that the first task, reviewer, and access owner are ready. Give the hire the same written milestones your team will use to assess progress.

Talk to Opus about your onboarding plan.

<!-- File not saved: filesystem access is read-only. Automated page checks were not run. -->