Managing nearshore developers: a guide for engineering teams

Managing nearshore developers, as we use the term, means running engineers who work from a nearby country and time zone and are engaged through a contractor agreement, a staffing partner or a vendor team, so they join your sprint without joining your payroll. How to manage nearshore developers well comes down to three things that differ from managing an employee: what you may direct, who handles pay and absence, and how the engagement ends.

This page maps the lifecycle in nine sections, from the day before repo access to the last day of the engagement, and links the deep guide for each one. Of six nearshore and remote-management guides we read in October 2026, none covered public holidays or offboarding, and none set out limits on directing a contractor. This one is written for engineering leaders in Europe, and for UK and US companies that have engineers there. Where a claim rests on a statute, a regulator or a government calendar, we name it. Where it's our judgment, we say so.

What's on this page

• What you can direct, and what stays with the vendor or contractor
• Before day one: contract, access and who the engineer reports to
• The first 30 days: from first PR to the week-three check
• Time zone overlap and working agreements for EU and US teams
• Communication, ceremonies and measuring output without watching hours
• Code review across time zones
• Holidays, leave and on-call: planning capacity across calendars
• When it isn't working: performance, replacement and continuity
• Ending the engagement: offboarding, access and IP
• What this means for your next nearshore hire
• All guides on managing nearshore and remote engineers
• FAQ

What you can direct, and what stays with the vendor or contractor

You set the work: tasks, priorities, quality standards and what counts as done. You review the output. Pay, tax, leave, equipment and the engineer's own working hours outside agreed overlap sit with the contractor or the vendor, and the contract says who does what. That split is the whole difference between managing a nearshore engineer and managing an employee, and it only holds if your day-to-day behaviour matches your paperwork.

Dutch and UK authorities look at how the work happens in practice, not only at the contract. In our judgment, a developer who invoices as a freelancer but joins your standups, takes tickets from your engineering manager and works fixed hours on one product for a year looks like a team member, whatever the contract calls them. In the Netherlands, KVK's Wet DBA guidance says client and contractor are jointly responsible, and a client who treats an employee as a freelancer owes payroll taxes. The Belastingdienst says the enforcement moratorium ended on 1 January 2025 (Dutch tax authority's enforcement page), and the cabinet's letter to parliament of 19 December 2025 says the remaining soft-landing elements lapse on 1 January 2027. Our guide to Wet DBA risk for companies with Dutch freelance developers sets out the dates and the four ways to engage. For a UK client, HMRC's off-payroll rules apply only where a UK tax or National Insurance liability arises, which turns on the engineer's residence and where the work is done, as HMRC's off-payroll manual sets out. For an EU-resident engineer working outside the UK that's usually not the case, and whether IR35 applies to EU contractors walks through the check.

The table is our judgment about how the three models usually split, not a legal classification. In a direct contractor model, most of the classification risk stays with you. Which model fits your team is a separate question, and staff augmentation vs agency vs in-house compares them. The seven-step nearshore vendor evaluation is worth doing before you sign anything.

Where does directing a B2B nearshore engineer turn into employment? We can't tell you. We found no regulator guidance on that exact question. What exists is tax and labour authority material on bogus self-employment, which is what the sources above are. Our working rule, labelled as judgment: if you'd give an employee the same instruction, schedule or monitoring, check before giving it to a contractor. The EU Platform Work Directive adds a further layer for platforms that organise and monitor work through software, with a transposition deadline of 2 December 2026. Our reading is that it targets digital labour platforms, not generic staff augmentation, and the Platform Work Directive guide for buyers explains the test. Take real cases to counsel in the country involved.

Before day one: contract, access and who the engineer reports to

Four things need to exist before the engineer sees a repository: a signed IP assignment and NDA, a written access list, a named manager and buddy, and the rules for AI tools. Skipping any of them is cheap on day one and expensive in month three.

Start with IP, because the default points the wrong way. Directive 2009/24/EC on the legal protection of computer programs gives the economic rights in a program to the employer in Article 2(3) where an employee wrote it in the course of their duties, unless the contract provides otherwise. Our reading is that a contractor isn't covered by that default, so a written assignment has to do the job, and it should be signed before access, not after the first pull request. National formalities add detail, which what an IP assignment agreement needs for EU contractors walks through. The wider contract set, including the data protection terms and termination, is in the seven clauses of a software development agreement. Serbia isn't an EU member state, so the directive doesn't bind it and a Serbian engagement needs its own local advice.

The access list does double duty. Write one document with every system the engineer touches: repos, CI, cloud console, ticket board, chat channels, password vault, VPN. It's your grant list on day one and your revocation list on the last day. Give outside engineers repo-level access, never organisation-wide, and no shared accounts.

Then decide who directs the work. Name one manager, who owns priorities and the extend, convert or replace decision, and one buddy, a mid or senior engineer who has agreed to answer questions within hours. If your team lead is the natural buddy, check what a tech lead should hand off, and to whom. Last, put the AI tool rules in writing, because a contractor with an assistant and your private repo is a data-handling decision someone should have made on purpose. An AI acceptable use policy template that covers contractors lists what to decide.

The first 30 days: from first PR to the week-three check

The first two weeks can be planned if you accept some judgment calls. Our 14-day plan runs in this order: paperwork before access, access scoped to the first ticket, a pull request open by day 3-5, a merge by day 10, and a go or no-go review on day 14 with three outcomes (extend, convert to a longer engagement, or replace). The full plan is in the first 14 days of onboarding a contract developer. Those dates are defaults we chose, not industry benchmarks. No sourced benchmark exists for a typical contractor ramp, so adjust them to your sprint length.

The gap is what happens between day 14 and day 30. By week three, the engineer should have merged work, review rounds per pull request should be falling, and blockers should be raised early, not discovered at standup. Those are the same three signals the day-14 review uses, and the point of the week-three check is to see whether they're improving or flat. Treat this as our judgment, not a tested protocol.

Before you read any weak signal as a verdict on the person, check your side. Blocked access, vague tickets and slow reviews cause most early "performance" problems, and section eight below covers what to do if the pattern survives that audit. A reasonable default is to make the decision inside about 30 days, which is also our judgment and not a standard.

Expectations should be written against something. If your team uses levels, say which level you hired the engineer at (see career ladder levels and where contractors fit) and what that means for scope and autonomy. A senior contractor who doesn't know they're expected to review other people's work will not do it.

Time zone overlap and working agreements for EU and US teams

Overlap is the hard constraint on nearshore work, and it's arithmetic you can do before you hire. Using a 09:00-18:00 working day on the nearshore side and 09:00-17:00 on the UK or US side, the six countries on Central European Time (Poland, Hungary, Slovakia, Serbia, Slovenia and mainland Spain) overlap with UK business hours for eight hours and with US Eastern for three. Romania is an hour ahead, so the figures drop to seven hours with the UK and two with US Eastern. Those figures come from the overlap table and ceremony-by-ceremony schedule in our agile nearshore development guide, which also shows what each ceremony needs.

Clock changes bend the numbers. US daylight saving begins on the second Sunday of March and ends on the first Sunday of November under the US daylight saving statute, while the EU changes on the last Sundays of March and October under the EU summer-time directive. For roughly three to four weeks a year (28 days in 2026, 21 in 2027), the US and Europe are on different clock rules, and the gap between the two sides moves by an hour. Put those weeks in the calendar in January, not when the standup suddenly lands at the wrong time.

A working agreement turns overlap into behaviour. In our judgment, it should state core hours when both sides are reachable, expected response times for messages and review requests, an escalation path for blockers, and how meeting times rotate so one side doesn't always take the awkward slot. Keep core hours to the overlap you need, agreed in the contract, and don't set hours beyond it. Check that point with counsel. Write it as a short document the engineer signs off on during week one, not as a policy nobody reads.

Choose the overlap you need before you choose the country. With the US East, three hours is enough for one daily sync and a review pass, and not much else, so decide what you'll spend it on. Distributed team management for engineering leaders covers the daily overlap window and the escalation path in more depth.

Communication, ceremonies and measuring output without watching hours

A gap of a few hours turns unwritten decisions into lost days. The fixes are dull and they work: one channel per purpose, decisions written down where the next person will find them, and an escalation path that names a person. The distributed management guide linked above covers channel-per-purpose and escalation paths, and argues for judging output over presence.

Shared definitions matter more when part of the team is external, because nobody can lean over and ask. If "done" means merged in one person's head and deployed in another's, the gap shows up as rework. Writing a definition of done for a blended team shows how to close that gap.

Keep a line open that doesn't run through the person who decides on extensions. Contractors may not volunteer problems to the lead who controls their renewal, so an occasional conversation with someone one level up catches what standup misses. Skip-level meetings, including for contractors and nearshore engineers shows the format.

Measure outcomes, not hours. For team-level delivery, DORA's delivery metrics give you definitions that don't care where someone sits. For one engineer, the day-14 signals work: what merged, how many review rounds, whether blockers surfaced early. We'd also avoid tracking a B2B contractor's hours or online presence. That's our judgment, partly because it doesn't tell you much about output, and partly because monitoring presence is what an employer does, which is the pattern section one warned about.

Code review across time zones

Review is where a three-hour overlap hurts first. A pull request that waits overnight for a first comment, then overnight again for the reply, turns a two-hour review into two days. The fix is to write three decisions down once instead of arguing them pull request by pull request: a size ceiling, a turnaround target and who holds approval authority.

Our guide to code review standards for distributed teams recommends a hard ceiling of about 400 lines per pull request with an explicit exception path, such as a migration or a generated file, that needs a second reviewer's sign-off. For turnaround, it sets the service level against the real overlap, not a blanket 24-hour clock: same-day inside the shared window, next business morning outside it. In our judgment, a UK pairing with eight hours of overlap can hold same-day. A US East pairing with about three hours needs the next-morning rule written in.

Authority is the question that's easy to dodge. The same guide takes the position that a senior augmented engineer should have the same voting weight in review and architecture discussion as an in-house senior, with one carve-out: decisions that outlive the engagement, such as a core data model, also need an in-house senior's sign-off, because the contractor won't be there to answer for it in eighteen months. Decide this before the first disputed approval, not during it.

Two newer concerns sit on top. If the engineer's code touches sensitive paths, review needs a security pass, and the secure code review checklist listed at the end of this page covers what to check. And if the team uses AI-assisted review, you have to know where the code goes and what it costs per reviewer. AI code review tools compared on cost and data handling covers cost for a 20-developer team and where code is sent.

Holidays, leave and on-call: planning capacity across calendars

A blended team doesn't share a holiday calendar, and a shared calendar gives you the wrong capacity number whichever side's dates it defaults to. Count working days per location, subtract each location's public holidays, and only then combine them. Capacity planning in Scrum for blended and nearshore teams works the arithmetic through step by step.

Its worked example shows the problem. Take a two-week sprint from Monday 29 June to Friday 10 July 2026, with a US side and a Polish side. 4 July 2026 falls on a Saturday, so the US Office of Personnel Management's federal holiday schedule shows the federal government observing it on Friday 3 July. Most US employers follow that, but a private employer sets its own, so check your US side's calendar. Poland's official 2026 public holiday list shows no public holiday for the Polish side in that window. The US side loses a day the Polish side doesn't have, and a plan that assumes one calendar is wrong by that gap. The guide also covers Saturday holidays. In Poland, an employee whose public holiday falls on a Saturday is owed a day off in exchange, on a day set with the employer (Zielona Linia on Saturday holidays). Sunday holidays give no substitute day. This rule applies to employees; a B2B contractor's days off follow the contract.

That's the extent of what we've verified. For Hungary, Slovakia, Slovenia, Romania, Spain and Serbia, we haven't checked the public holiday calendars against a primary source. Check the national government's published calendar for each country you hire from, and don't borrow another country's dates.

Leave and sickness need one honest paragraph. In our reading, a genuine B2B contractor's time off is a contract term, not a statutory entitlement, so agree how absence is notified and whether it's billed before the engagement starts. We haven't verified country-by-country rules, so we make no claims about what any one country requires. If your contractor is treated as an employee in practice, the answer changes, which is why section one comes first.

On-call needs more care. Stand-by is not automatically working time or automatically free time. The Court of Justice held in case C-580/19 (RJ v Stadt Offenbach am Main, 9 March 2021) that stand-by is not entirely working time unless the constraints very significantly affect the person's free time, per the Court's press release on that ruling. The case concerned an employed firefighter; whether it reaches a B2B contractor is for counsel. Serbia is outside the EU, so EU directives don't apply to it directly. How to set up an on-call rotation for a nearshore team covers follow-the-sun rotations and who can page a contractor.

When it isn't working: performance, replacement and continuity

Diagnose your side first. The same symptom (nothing merged in a week) can mean blocked access, slow review, vague tickets or a skills gap, and each has a different first move. Once the setup is clean, write three to five dated examples of the gap, agree a short improvement window with targets taken from your own team's numbers, and escalate to the vendor with the same document the engineer received. Then decide. Extending "one more sprint" three times is the expensive option. Handling an underperforming staff augmentation developer walks the steps and the replacement terms.

The contract decides how painless replacement is. Ask for a definition of "not working" tied to measures, a replacement window counted from your written notice and not from the vendor's acknowledgement, a statement of who pays for the replacement's ramp-up, and agreed overlap days for handover. These are our recommendations, not an industry standard. If you want a reference point, HighCircl replaces an engineer at no additional recruitment cost if the engagement isn't working, and has no minimum hour commitment. Whatever vendor you use, get equivalent terms in writing before you start.

Sometimes the person isn't the problem. A second or third engineer from the same vendor showing the same pattern points at vetting, staffing or account handling, and swapping people won't fix it. Replacing an offshore development team with a nearshore one covers diagnosing that failure, securing access, running a parallel pilot and exiting cleanly.

Then there's the other kind of continuity risk, where a key engineer resigns and the knowledge walks out. If the departing person is in-house and the nearshore team now holds the context, or the reverse, you need a plan inside the notice period. A 30-day knowledge transfer and backfill plan gives one. The practical lesson from nearshore engagements is to keep the handover document standing from week one, so the transfer is an update, not an excavation.

Ending the engagement: offboarding, access and IP

Plan the exit on day one. The access list you wrote before day one is the revocation list, so offboarding becomes a checklist instead of an archaeology project. Remove the engineer from every repository and system on the list, rotate any shared secret they could read even if they never used it, review the handover document with the next owner while the engineer is still reachable, and ask for written confirmation that local clones are deleted. Removing someone from a private repository deletes their forks of it, but their local copies remain, which is why the written confirmation matters. The table and the exact steps are in the offboarding checklist inside the 14-day onboarding plan for contract developers.

IP closes out the same way it opened. Confirm the signed assignment from section two is filed, and restate the confidentiality obligations in the exit note. If the assignment was never signed, you can't fix that cleanly on the last day. This is one more reason the sequence in section two puts the paperwork before the first commit.

Notice terms and data deserve a line each. The notice period and any handover duty belong in the vendor or contractor agreement, as does what happens to personal data the engineer handled, including return or deletion. If you rely on a vendor's environment, ask how and when your data comes out. These are contract terms to check before signing.

Some engagements end because you've decided to bring the work in-house, and that has its own sequence of hires, knowledge transfer and cut-over. Transitioning from outsourced development to an in-house team lays that out. Treat a conversion of a contractor into an employee as a new engagement with its own paperwork, and take advice in the country involved, because it changes the classification answer from section one.

What this means for your next nearshore hire

The decision is team shape: what you'll direct yourself, what you'll push to the vendor or contract, and when you'll extend, convert or replace. Here's what we'd do.

All of this is our judgment, not law. Before the engineer starts, name one manager and one buddy, write the access list, and get the IP assignment signed before access. Set a core overlap window and a review turnaround from the real overlap, not from the vendor's pitch, and put the day-14 and day-30 decisions in the calendar before the first day. If you direct the engineer like a team member, check the classification sources in section one before extending the engagement. And in the contract, ask for a replacement window measured from your written notice.

If you're already past the first month and the signals are bad, the next step is the written-examples and improvement-window steps for an underperforming contractor.

All guides on managing nearshore and remote engineers

Guides not linked in the sections above, grouped by topic.

Start here

• Engineering management guides for CTOs and VPs of Engineering

Delivery and incidents

• Release management for a blended engineering team
• How to run an incident postmortem on a blended in-house and nearshore team

Code review and quality

• Secure code review: a checklist for engineering leaders

FAQ

How do you manage a nearshore developer day to day?

Give them the same things you'd give a good colleague: a named manager, a buddy, clear tickets with acceptance criteria, fast review and a daily overlap window. Then manage the output, not the hours. Keep decisions written down so the time zone gap costs you minutes, not days, and keep a separate check on classification if the engineer is a contractor.

How much time zone overlap do you need with a nearshore team?

It depends on where your team sits, and the numbers are specific. On a 09:00-18:00 nearshore day against 09:00-17:00 on your side, Central European Time countries overlap with the UK for eight hours and US Eastern for three, and Romania for seven and two. How many you need is our judgment call: enough for a daily sync and a review pass at minimum. The agile nearshore development guide linked above shows what fits in each window.

What is the difference between managing nearshore and offshore developers?

Nearshore means a nearby country with a compatible time zone, so you get live overlap hours. Offshore means working with a team in a distant country and time zone; for European companies, our comparison of nearshore, offshore and onshore gives India and Vietnam as typical examples, several hours ahead. That's our working definition, not a standard one. The management difference follows from it: nearshore lets you keep ceremonies and review inside shared hours. We don't state cost differences here because we haven't sourced them.

What is the 30-60-90 rule, and does it fit a nearshore contractor?

It's a common framework for an employee's first three months, with a distinct goal for each 30-day block. A short contractor engagement has no room for that pace, so we compress it into the 14-day plan and decide on day 14 whether a longer engagement earns a 30-60-90 of its own. Vendor-published nearshore onboarding guides quote cycles of roughly one to two weeks, but those are their own claims, not independent benchmarks.

How long should onboarding take?

There's no sourced industry number. As a working default, our judgment is a first pull request open by day 3-5, a first merge by day 10 and a decision on day 14. Full productivity takes longer than that. What matters is that the early signals arrive on time, and that access problems on your side don't count against the engineer.

Can you manage a contractor like an employee?

Not safely. Dutch and UK authorities look at how the work happens in practice, not only at the contract, so directing a contractor's hours, tools and daily tasks the way you would an employee's raises classification risk. In the Netherlands, a client that treats an employee as a freelancer owes payroll taxes, and HMRC's off-payroll rules can apply to a UK client where the engineer has a UK tax liability, for example through UK residence or work done in the UK. We found no regulator guidance on where directing a contractor turns into employment, so take your own case to counsel.