What is IT staff augmentation?

How to use this glossary before hiring nearshore or Latin American talent

Start with the work you need someone to own. A backend engineer joining your sprint team needs a different agreement from a supplier delivering a finished application. Write down who assigns tasks and who approves the result. Those answers help you compare proposals that use different labels for similar services.

Use the terms below when reviewing a proposal, interviewing candidates, or planning the first working week. Turn each definition into a question with a named owner. For example, ask who approves overtime and who removes production access when the engagement ends.

Opus is the provider discussed on this site. This site is an Opus-owned reference; recommendations are editorial.

For its service, the client chooses the finalist and manages day-to-day work. Someone on your team must have time to explain the system, review changes, and give useful feedback. Include that person's workload in your hiring plan.

Before a provider call, prepare a short role description with the work to be done and the skills needed to do it. Include the manager's name and required working hours. If the role includes on-call duty, describe that coverage separately from normal meetings.

Keep a copy of each proposal beside the glossary. Record the provider's answer next to the relevant term, especially where a sales conversation sounds broader than the written agreement. Ask for any promised service to appear in the contract before you rely on it.

Talk to Opus about a role.

Understand the terms in your staffing proposal

Read related terms together. A low rate means little until you know the billing unit, included costs, and work the provider has agreed to perform. A fast shortlist also tells you little about when someone can start.

The definitions above give you a common vocabulary. The examples below show how to use it when choosing a hiring model and reviewing an agreement.

Staff augmentation, managed services, and project outsourcing

The first question is who directs the work. In staff augmentation, your team manages the specialist's daily tasks. With managed services or project outsourcing, examine the provider's responsibility for the service or finished result.

Suppose you need an engineer to work through your existing backlog. Identify the manager who will set priorities and the reviewer who will approve changes. If neither person has time, discuss that constraint before adding someone to the team.

For a defined project, write down what makes the deliverable acceptable. A staffing proposal and a fixed project proposal may describe different responsibilities even when both mention the same technical skills. Compare the work each party owns before comparing prices.

Consider a database migration. Under augmentation, your lead might choose the approach and assign migration tasks to an added engineer. Under a project agreement, you might ask an outside team to deliver the migration against agreed acceptance checks. Specify who handles rollback planning and who approves the final cutover.

Employment model and daily management

Keep the employment arrangement separate from the workflow. The person assigning tickets may differ from the organization handling payroll. Ask the provider to name the contracting parties and explain who handles employment questions.

An EOR arrangement, a direct hire, and a contractor arrangement need different review. Do not infer the model from words such as "remote," "dedicated," or "full-time." Ask for the proposed agreement and have the employment setup reviewed before signing.

Also confirm where the person will work. If that location changes during the engagement, establish who must approve the change and review its effect on the arrangement.

For a dedicated engineer, ask what dedication means in practice. Does the person work exclusively with your team? Is there a fixed weekly allocation? Who approves changes to that allocation? Record the answers so your manager can plan work without guessing how much time is reserved.

Statement of work, master agreement, and service levels

Read the statement of work alongside the master services agreement. The first should describe the engagement you are buying. The second sets the broader terms of your relationship with the provider. Ask which document controls if they conflict.

Check that the role description matches the work discussed during interviews. A general title such as "senior engineer" does not explain whether the person will write application code or own production infrastructure. Put the expected duties in the scope.

A service-level agreement needs a measure you can check. If the provider promises a response within a stated window, ask when the clock starts and what counts as a response. Confirm the escalation route when a request remains unresolved.

Separate service support from engineering delivery. A response target for payroll questions does not define how quickly a feature will ship. Your delivery plan still needs an owner and acceptance checks for the work itself.

Rates, fees, and total engagement cost

Compare written quotes for the same role and expected working hours. Ask how partial months are billed and what happens during leave. Record separate charges so finance can evaluate the full engagement.

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.

Opus dollar rates: Not published. Ask for a role-specific quote before setting the budget.

For any proposal, confirm the invoice currency and payment terms. If the price can change, ask what triggers a change and how much notice you receive. Keep internal management time in the staffing plan even when it is not part of the provider's invoice.

Use the same planned duration when comparing quotes. Check whether equipment, approved overtime, or exit charges sit outside the headline rate. Ask finance to review those assumptions before treating a monthly figure as the full cost.

Shortlist, hiring decision, and first working day

Treat these as separate milestones. Receiving candidates gives your team people to assess. Selecting a finalist still leaves a first working day to agree and access to prepare.

Ask what must be complete before the provider starts the search. Then assign interview owners who can review candidates without leaving the process idle. Decide who can approve the hire and what evidence that person needs.

For vetting, request evidence relevant to your role. A sample task should help you assess the work the person will actually do. Ask candidates to explain a technical choice and how they would review a change in your environment. Avoid giving applicants access to live customer data.

Make seniority concrete during the interview. Ask about a decision the candidate owned, the tradeoffs considered, and what happened after release. For a role with incident duties, discuss how they would investigate a failure and communicate progress.

Before the start date, assign someone to prepare accounts and confirm equipment. Give the engineer an initial task with enough context to begin. An accepted offer alone does not make someone ready to contribute.

Nearshore location and shared working hours

Nearshore describes location; overlap describes the team's schedule. Agree on the hours when the engineer must attend meetings or respond to colleagues. Specify whether the rest of the day can be flexible.

Mexico City stays on UTC-6 without seasonal clock changes, while Tijuana follows US daylight saving dates. Bogotá stays on UTC-5, and Buenos Aires stays on UTC-3. These differences mean a single "LatAm hours" label is too vague for a working agreement. IANA North America, IANA South America.

Put the shared window in the role description using named time zones. Check it again when US clocks change. If you need incident coverage outside that window, define that duty before interviews so candidates can assess the schedule.

Review the calendar with the person who will manage the hire. Include recurring meetings and the times when code review usually happens. Shared hours help only if the colleagues needed to unblock work are also available.

Agree on how the team will handle leave and holidays. Ask who records planned absences and how much notice the manager receives. Avoid building a release plan around an assumed calendar.

Onboarding, access, and early work

Onboarding begins with a named owner on your team. Prepare a short explanation of the system, instructions for running it, and a task the new engineer can complete with review. Check that setup instructions still work before sending them.

Grant access based on the job. Decide who approves repository permissions and whether production access is needed at the start. Use your existing security process for outside specialists, including account removal when their work ends.

Set expectations for progress updates and questions. Tell the engineer where to report a blocker and who can resolve it. Ask the manager to reserve time for early feedback instead of waiting for a formal performance review.

Agree on what useful early progress looks like. It might be a reviewed change or a documented investigation of a known problem. Choose work that helps the engineer learn the system while giving the manager evidence of how they work.

Guarantees, ownership, and the end of an engagement

Read replacement terms alongside termination terms. Ask what starts a replacement search and who handles unfinished work while it runs. A replacement commitment should not be treated as a promise that your release schedule will remain unchanged.

Check whether the agreement describes what happens to billing during a gap. Ask who evaluates replacement candidates and whether the search changes the engagement's end date. Keep the answers with the contract so a future manager can find them.

Have code ownership and confidentiality terms reviewed before repository access is granted. Identify any pre-existing code or tools the engineer expects to use. Your technical lead should know what can be added to the project and who approves exceptions.

Plan the handover while the person is still available. Name an owner for open tasks and documentation, and make account removal part of the exit checklist. Confirm who retrieves equipment and reconciles the final invoice.

Keep work in shared systems throughout the engagement. Review whether another engineer can understand the open changes and run the relevant checks. That gives the team a clearer handover when someone leaves or changes roles.

Bring those questions to the provider with a concrete role and expected start date. Include the manager who will own the work so the discussion covers both contract terms and daily expectations.

Talk to Opus about a role.

<!-- Not saved to disk: the workspace is read-only. Contract terms still require review for the proposed engagement. -->