IT hiring glossary: what does it mean outsourcing?

How to use this glossary for nearshore and Latin American hiring

Start with the decision you need to make. If you need an engineer inside your team, compare staff augmentation and direct placement. If you need someone to run a service, examine managed services. If you already have a candidate, determine who will employ that person.

These terms answer different questions. Nearshore describes location. Staff augmentation describes how you add people to your team. An employer of record describes an employment arrangement. A proposal can use all these terms without explaining who will review code or approve leave.

Before requesting quotes, write down the work the person or team will own. Include a concrete example: maintaining a billing API, clearing a support queue or migrating a database. Then name the internal manager who will review the work. If nobody on your team can do that, ask how the provider will manage delivery.

Use the definitions to turn a sales conversation into a written division of duties. Ask each provider to identify who finds the candidate and signs the employment agreement. Assign responsibility for performance reviews, security access and ending the engagement as well.

Keep a copy of those answers beside the quote. If a proposal promises a dedicated team but leaves management to you, budget for that work. If it promises a completed project, look for a clear way to accept or reject the result.

For a conversation about a specific role, talk to Opus about a role. This site is an Opus-owned reference; recommendations are editorial.

Which terms should you check before signing?

Use the glossary terms to read a proposal, then connect each term to a duty in the agreement. Focus first on the working model. After that, check the price and the support that continues once someone starts.

Choose the model around the work

Consider a hypothetical backend hire who attends your planning meetings and receives tasks from your engineering manager. Staff augmentation describes that working setup. Your manager still needs time to explain requirements and review pull requests. You also need to establish who employs the person and handles payroll.

Now consider a project to replace a reporting tool. If you expect the provider to plan and deliver the finished tool, ask for project scope and acceptance criteria. A list of available developers does not answer who owns the delivery date.

For an ongoing help desk, define service hours and escalation paths. Ask what happens when the assigned person is absent. Put those duties in the agreement instead of assuming that the phrase "managed service" includes them.

The same test applies to a dedicated team. Ask whether "dedicated" means exclusive working time or simply named people on an account. Confirm who can change the team and how much notice you receive. If a lead leaves, decide who keeps work moving while a replacement learns the system.

Separate recruiting from employment

Recruiting covers finding and assessing people for a role. Direct placement describes a hire made through that search. Neither term, by itself, answers how you will employ someone in another country.

An employer of record addresses the legal employer role. Payroll processing addresses pay administration. When comparing these services, ask for the name of the entity that signs the worker's employment agreement. Then ask who handles leave requests and employment changes.

Keep the daily manager visible in this discussion. An outside business may handle employment duties while your engineering lead sets priorities. Write down who delivers performance feedback and who handles a formal employment concern.

If you already have a candidate, say so before requesting a proposal. Ask for the employment service you need and whether any recruiting charge still applies. If you need a search, specify the skills to assess and who makes the final hiring decision.

Compare quotes with the same boundaries

A salary, a recruiting fee and a monthly staffing rate cover different things. Before comparing totals, ask each bidder to list what the quote includes and what your company pays separately.

Use the same role and expected working schedule in every request. Include the level of ownership you need. A developer maintaining an established feature has a different assignment from a lead making architecture decisions and reviewing other engineers.

For contingency recruiting, define the event that triggers the fee. It might be tied to an agreed hiring milestone, so read the payment clause closely. For retained search, check which payments remain due if you pause or cancel the role.

Ask how paid leave affects the invoice and whether equipment is included. Confirm the billing currency and how rate changes are approved. For project work, ask how a change request affects both price and delivery date.

Keep your own management time in the comparison. Someone must explain the product, review work and answer questions. A lower invoice can still require more work from your team. Assign those duties before treating a quote as the full hiring budget.

Turn vetting into evidence you can review

Vetting means checks, but the word does not tell you what was checked. Ask what the candidate's assessment involved and who reviewed it. Request enough detail to understand which job requirements it tested.

Use an interview problem drawn from the role without asking candidates to do unpaid production work. For a maintenance role, discuss a small code sample and a likely failure. For a lead role, ask how the candidate would weigh a design tradeoff.

Assess communication through the work itself. Ask the candidate to explain a decision and respond to a changed requirement. If the job involves written handoffs, include a short written task. A fluent interview alone does not test whether someone can explain an incident to the next shift.

Agree on the hiring decision process before interviews begin. Name the decision-maker and give each interviewer a clear area to assess. When feedback conflicts, return to the job requirement and the evidence. Avoid adding another interview without a specific question it needs to resolve.

Define hiring milestones before comparing speed

Time to hire needs a start point and an end point. A search can begin when you approve the role or when a recruiter contacts a candidate. It can end at offer acceptance or another agreed milestone. Ask which events a provider measures.

Keep the accepted-offer date separate from the first working day. A candidate may need to finish an existing commitment. Equipment and account access also need owners before the person can begin useful work.

For your own schedule, list the steps that depend on your team. Reserve interview slots and decide who can approve an offer. If the hiring manager is away, name a backup. These are tasks you can control while the search runs.

Treat a shortlist deadline as a separate promise from a start date. Ask what happens if the first candidates miss the requirements. Agree on how feedback changes the search and when you will receive the next update.

Check shared hours by city and season

Bogotá is UTC-5 year-round. Buenos Aires and São Paulo are UTC-3 year-round. These cities do not change their clocks seasonally. IANA South America time zone data.

Mexico City is UTC-6 without seasonal clock changes, while Tijuana follows US daylight saving time. A country name alone is therefore too broad for setting a meeting schedule. IANA North America time zone data.

Ask for the candidate's working hours in their city and your team's time zone. Check the schedule during both US standard time and daylight time. Record the agreed window in the offer or working agreement so recurring meetings remain clear after the clocks change.

Separate shared working hours from on-call duties. Attendance at a daily meeting does not establish availability for an overnight incident. If the role includes support, specify the coverage schedule and the person who takes over when the hire is away.

For Latin American or LatAm hiring, confirm the holiday calendar as part of scheduling. Ask how the team handles a release that falls on a local holiday. Plan the handoff before committing to a launch date.

Make scope and acceptance concrete

A statement of work should let both sides identify what the engagement includes. For a software project, name the deliverables and the environment in which they must work. Record dependencies your team must supply, such as test data or access to an existing service.

Acceptance criteria explain how you decide whether the work is complete. "The report works" leaves room for disagreement. A clearer requirement names the report's inputs and the expected output, then states who checks it.

Decide how you handle defects found during review. Ask how long you have to test a delivery and where you record issues. Distinguish fixing an agreed requirement from adding a new one.

For an ongoing service, use a service-level agreement to define measurable commitments. Response time measures how soon someone responds. Resolution time measures how soon the issue is resolved. Specify service hours and severity levels so both parties measure the same events.

Agree on access and ownership before work begins

List the systems a new worker needs for the first assignment. Give each access request an internal approver. Avoid granting broad production access simply because it is easier during onboarding.

Ask how the provider handles company data and whether anyone beyond the assigned team can access it. If the work involves customer data, bring your security reviewer into the discussion before access is granted.

Put code ownership and account control into the agreement. Decide where the team stores code, documentation and deployment settings. Your company should know how to retrieve the work if the assigned person becomes unavailable.

For tools bought during the engagement, record who owns the account and pays the renewal. Keep credentials out of handover documents. Use your approved access process so the next person can take over without sharing someone else's login.

Define what happens after the hire starts

Put onboarding tasks on the calendar before the first working day. Name the person who approves access and the manager who assigns the first piece of work. Give the hire a clear place to ask questions.

Choose an initial assignment small enough to review. Use it to check whether the person understands the product and can work through your normal review process. If progress stalls, identify whether the cause is missing access, unclear requirements or a skill gap.

Read replacement language alongside the exit terms. Ask what triggers a replacement search and what costs continue during it. A promise to search again does not, by itself, promise a refund or someone who can start immediately.

Plan the handover while the engagement is active. For projects, include code and operating instructions in acceptance. For ongoing services, decide how open tickets transfer. When someone leaves, assign responsibility for removing access and confirming that unfinished work has an owner.

Bring a role description and your required working hours to the next conversation. Talk to Opus about a role.

<!-- Not saved: the workspace is read-only. Page rendering was not checked. -->