Build a staff augmentation business plan for the first 90 days

What should you put in place before day one?

Approve an onboarding plan with the hiring decision. Give the hire a named manager, a first assignment, and a clear path to getting help. Reserve time on the team's calendar for reviews before promising a delivery date.

The schedule below is a planning template. Adjust the work to the role and your release process. A senior engineer joining a familiar stack and an engineer entering a restricted production environment need different first assignments.

Count onboarding from the first working day. Keep recruiting dates separate so an accepted offer does not quietly become a promise of immediate delivery.

Write the business case in a paragraph

State what work needs another person and who will accept the result. For example: "The engineer will own the account export backlog. The engineering manager will approve scope, and the product owner will accept completed changes."

Add the constraint that prompted the hire. Perhaps a backlog has no owner, or a staff engineer spends too much time on support fixes. Use your team's own evidence. Avoid assigning the new person an entire department's missed goals.

Your staff augmentation plan should also show what the manager will stop assigning elsewhere once the hire is ready. Otherwise, ownership stays vague and two people may assume the other is responsible.

Define what stays outside the role, too. If the hire will build reporting tools, say whether customer support and after-hours incidents belong to that assignment. Record who can approve a change in scope. Review new requests against that boundary when planning the next sprint.

Set the budget and approval rules

Record the agreed provider charge, billing start date, and any equipment or software costs. Budget internal time for pairing and review. Confirm how partial months, planned leave, and changes in scope affect the invoice.

Keep these costs separate in the approval sheet. The provider's charge and your team's onboarding time answer different budget questions.

Choose who can approve extra spending. If a license blocks the first assignment, the hire should know where the request goes. The manager should know whether that expense is already approved.

Prepare access before arrival

Use your existing access process. Assign an owner to each request and test what can be tested before the start date.

Include the work account, repository permissions, development environment, and the task board. Add the documents needed to understand the first assignment. Confirm equipment delivery and any device setup requirements.

Grant access for the assigned work. Keep production permissions behind the usual approval process. Do not solve a delayed account request by sharing another employee's credentials.

The access owner should record blocked requests with a next action. "Waiting for IT" is too vague to resolve. "Device enrollment needs approval from the security lead" gives the manager something to act on.

Prepare a fallback task that uses approved access, such as reviewing a test plan with the technical buddy. Give it a useful outcome. Do not fill the first week with unrelated reading while the actual blocker goes unassigned.

Use this 30/60/90-day review template

Treat each row as a decision point. Passing a date on the calendar does not prove readiness for more access or broader responsibility.

Days 1–30: complete a small piece of real work

Start with a task that uses the team's normal workflow. A contained bug fix can expose how the team writes requirements, reviews code, tests changes, and releases work.

Give the hire enough context to explain why the task exists. Point to the affected user, the expected behavior, and the person who can resolve an unclear requirement.

Assign a technical buddy who can answer practical questions. Schedule short check-ins during the opening week, then adjust the cadence to the work. Keep a written place for questions that do not need a meeting.

By the first review, look for evidence that the hire can:

• Run the project and its relevant tests.
• Explain the part of the system they changed.
• Respond to review comments and document unresolved issues.
• Find the right person when a dependency blocks progress.

For the account export example, the first task might fix a date filter that leaves out valid records. Give the engineer a sample input and the expected output. Ask them to add a test that catches the fault and explain the change during review. Keep release approval with the usual owner.

Review the work with the hire. Ask which instructions were unclear and correct them for the next assignment. If access consumed much of the month, record that delay before judging delivery.

Days 31–60: expand the scope of ownership

Choose a task with a clear boundary and more room for judgment. Ask the engineer to propose an approach, identify dependencies, and explain how they will test it.

Keep normal peer review. Independence means the person can move work forward and ask useful questions. It does not mean removing checks or expecting them to know undocumented history.

The export assignment could now cover a requested file format. Ask the engineer to confirm which fields users need and how large files should behave. Have the product owner accept those requirements before work begins. Review whether the engineer flags a dependency while there is still time to change the plan.

At this review, compare the agreed scope with what happened. Discuss changes in requirements, review delays, and defects. Ask whether the hire raised risks early enough for the team to act.

If the work missed expectations, write down the specific gap and the next chance to demonstrate improvement. "Needs more ownership" gives little guidance. "Confirm the API dependency before committing to the next release" names an action.

Days 61–90: decide the ongoing role

Give the hire responsibility for an agreed area, with clear limits. That might be a feature backlog, a service component, or a recurring support workflow.

Ask for a handover note another engineer could use. It should explain the current state, open risks, and where to find operating instructions. Review whether the person can support their work after release.

For the export backlog, ask the engineer to propose the next changes and explain their order. Have them identify work that needs another team's decision. The manager can then assess whether the proposed scope fits the business need and available review time.

Use the final review to choose the next scope. Continue the arrangement if the role and performance meet the need. Expand it only when the evidence supports that decision.

Where the fit remains poor, discuss the next step with the provider. Keep the performance record specific. A replacement will inherit the same access delays and unclear requirements unless your team fixes them.

What does hiring data tell you about the onboarding clock?

SHRM reports that median time-to-fill in 2025 was roughly a month and a half for executive and nonexecutive positions. It defines that interval as job requisition to offer acceptance. That measure ends before the first working day. SHRM's 2025 recruiting findings.

Use that distinction when someone asks when the hire will contribute. A recruiting benchmark does not measure access setup, system learning, or readiness to own a release. It also does not establish a schedule for your specific engineering role.

Keep separate dates for the approved requisition, accepted offer, and confirmed start. Add the first accepted deliverable once work begins. This lets you see whether a delay sits in hiring, pre-start preparation, or onboarding.

For the first review, use a small record of actual work:

Avoid using ticket totals as the sole performance measure. Compare the work with its agreed scope and review the reasons for changes. A small fix and a risky migration should not carry the same expectation.

Keep the review record short enough to update during normal work. Link to the task, note the blocker, and record who owns the next step. Ask the hire to check that account before the review. A disputed requirement should lead to a clear decision, rather than quietly becoming a performance concern.

Do not set a universal day-30 output quota from a hiring benchmark. Pick the first assignment with the technical lead, then judge its result in context.

How do hiring models change your nearshore onboarding plan?

Start with who directs the work and who accepts the result. Confirm those responsibilities in the agreement instead of inferring them from a service label.

For Latin American hires, also establish who handles employment administration and who resolves day-to-day problems. The same internal manager should not have to guess whether a payroll issue belongs with finance or the provider.

Use this table to frame contract questions. Ask each provider to confirm its actual scope.

An IT outsourcing business plan should define deliverables and acceptance responsibilities when you are buying a project. For an embedded hire, define the person's role and the manager's time instead. Keep those budgets distinct when both models exist in the same team.

If your manager cannot review work or make scope decisions, resolve that before adding an embedded hire. Assign a delegate with authority to answer questions. If you need a supplier to own delivery, ask for that scope explicitly and define how you will accept the result.

Agree on shared hours by city

Mexico City is UTC-6 and does not observe daylight saving time. Tijuana follows US daylight-saving changes. A country name alone therefore does not define the working schedule. IANA's North America time zone data.

Bogotá is UTC-5 year-round. New York changes between UTC-5 and UTC-4, so the time difference changes during the year. IANA's South America data and North America data.

Put the actual shared hours in the onboarding plan. Name the time zones in recurring invitations and check meetings after clock changes. Agree on response expectations outside overlap rather than assuming someone will keep checking messages.

Use shared hours for work that needs another person, such as pairing or resolving a design question. Leave written context for tasks that can continue without a meeting.

What should you ask a provider before confirming the start?

Send the provider your role goals and onboarding schedule. Ask for written answers tied to the proposed hire and agreement. General service descriptions do not settle who sends the laptop or handles a delayed start.

Who owns each part of the first week?

Ask the provider to name its contact for placement and payroll issues. Name your own manager and access owner in the same document.

Confirm who handles equipment, identity checks, account requests, and start-date changes. Ask how the hire should raise an urgent problem when their usual contact is away.

Agree on the handoff from candidate selection to onboarding. The manager needs the confirmed start date and working schedule before sending invitations. Keep personal employment documents in the proper restricted system.

What does the quote include?

Ask for the rate for this role, seniority, and location. Confirm the currency, payment terms, and billing start date.

Request a clear list of inclusions and any separate costs. Ask how equipment, software licenses, and approved changes to working hours are handled. Have the budget owner review the quote before the hire starts.

If the plan crosses a holiday period, confirm the working calendar and coverage with the provider. Do not schedule a release around an assumed US holiday calendar.

What happens when performance falls short?

Ask who joins a performance discussion and how quickly an issue can reach the right decision-maker. Request the process for documenting concerns and discussing replacement.

Clarify the practical terms: billing during a transition, access removal, and handover duties. Ask how the provider handles a search while the current arrangement is still being reviewed.

Keep an internal continuity plan. Store work in company-controlled systems and require ordinary documentation from the start. A guarantee does not tell the next engineer how an unfinished change works.

What evidence should the hiring manager bring?

Bring a sample assignment with clear acceptance criteria. Explain the review process and the level of support your team can give.

For remote-first companies hiring several people, confirm reviewer capacity before agreeing to simultaneous starts. If one technical lead must review every change, schedule those reviews and adjust start dates where needed.

Ask candidates to discuss the proposed work and schedule. A conversation about a real dependency or handover can expose a mismatch before it becomes an onboarding problem.

Opus is one option to discuss against this checklist. This site is an Opus-owned reference; recommendations are editorial.

Talk to Opus about a role.

How should you assess Opus against this plan?

Opus states: "The client chooses the finalist and manages day-to-day work." Plan to keep an internal manager responsible for assignments, review, and feedback.

Opus describes its pricing this way: "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 the role you intend to fill, then add your internal onboarding costs.

Opus also states: "Every placement carries a lifetime replacement guarantee with no cap and no time limit." Ask how that guarantee would work during a transition. Confirm the handover process and billing terms before relying on it in the budget.

For scheduling, Opus states: "Every Opus placement works with US timezone overlap." Turn that into an agreed working schedule with the finalist. Check whether the shared hours cover your planned reviews and any support duties.

Bring the proposed first assignment to the conversation. Include the manager's name, the access lead time, and the evidence you expect at each review. Ask how the proposed arrangement supports those requirements.

Before confirming the start, make sure the technical lead can explain what successful work will look like at the first review. Then reserve the time needed to assess it.

Talk to Opus about a role.

<!-- File not saved: the workspace is read-only. Automated page validation was not run. -->