Onshore, Offshore, Nearshore: Designing Teams Around Time Zones, Not Rates

Last updated: September 12, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

The spreadsheet had three columns and no fourth row.

Onshore, nearshore, offshore. A blended hourly rate under each one, quoted by three different vendors, and the offshore column shaded green because it came in 38% under the column on the left. Somebody had done real work on that sheet. I still have it. The rates were accurate, the margins were right, and the annual savings figure at the bottom was not fantasy.

What the sheet did not have was a row for overlap hours. Which turned out to be the only number on the page that decided anything.

We went green. I signed it. The pod that came back was strong, genuinely strong, sitting 12.5 hours off us and building a document-indexing service against a loan schema that was, at that point, about 80% settled. They were not the problem. The other 20% is where this story lives.

One field. Nullable or not nullable, on a borrower-employment record that could legitimately arrive empty from three upstream sources and not legitimately arrive empty from a fourth. The question went out on a Thursday afternoon our time. It landed in their morning, which was already our Thursday night. The answer came back with a follow-up question attached, because the answer depended on something nobody had written down. We read it Friday. We replied Friday. Their Monday.

Four exchanges. One field. Thursday to the following Wednesday.

Nobody was slow. I checked the timestamps twice, because I wanted somebody to blame. Every person in that chain answered within a few hours of reading the message, and the thing still took six calendar days, because the chain had a one-day tick built into it and no amount of goodwill compresses a tick. We had not bought cheaper engineering. We bought the same engineering with a clock between us, and I had approved the clock without pricing it. That one is on me.

KORE1 publishes these because the same conversation keeps landing in their engineering staffing pipeline, usually as a client asking what a nearshore bench costs when the actual question is which seats can survive a 10-hour offset. It is the same argument I made about how team boundaries actually get drawn, moved out one layer, because a boundary decides throughput and a clock is just another boundary. I write with them. They place the engineers I am about to describe, so discount my hiring opinions accordingly.

Three Models, Sorted by Clock Instead of Cost

Onshore, nearshore, and offshore describe how far a team sits from your working day, not how good it is. Onshore means the same or an adjacent time zone. Nearshore means a nearby country within a few hours. Offshore means a distant region with little or no natural overlap in a shared business day.

That is the whole taxonomy, and notice what is absent from it. Skill is absent. Seniority is absent. English fluency, which is the thing executives ask about first, is absent, and in 2026 it barely functions as a sorting variable at all. I have worked with brilliant engineers in Kraków and mediocre ones forty minutes from my house. I have hired both. Geography stopped predicting capability a long time ago.

It never stopped predicting the calendar.

Most engineering organizations are already making this decision, whether or not anybody wrote it down. In Stack Overflow’s 2025 Developer Survey of 48,178 developers, 32.4% work fully remote and only 17.9% are fully in person. Everybody else is somewhere in between, which means the clock is already a design variable on most teams whether it got designed or not.

Here is the same three-column comparison with the row that belongs on it, anchored to a U.S. team on Eastern time running a normal nine-to-five.

Read the fourth column as a budget rather than a fact. Overlap is the thing you are purchasing. The rate just prices it.

One clarification on that table, because the honest version is less tidy than the row suggests. Nearshore is the only model on it that gives you a genuine full-day overlap without anybody sacrificing an evening, and in my experience that, far more than cost, is why so much of the work that used to go to Asia now goes to Latin America instead. Not cost. Costa Rica is not cheap. The clock did that.

The Number That Never Makes It Onto the Comparison Slide

There is good research on this. Almost none of it appears in the vendor content ranking for these terms.

Jasmina Chauvin of Georgetown, Prithwiraj Choudhury of Harvard Business School, and Tommy Pan Fang of Rice studied more than 12,000 employees at a Fortune 100 multinational and published the result in Organization Science in 2024. I reread the paper twice. Same firm, same roles, same work. The only variable they changed was temporal distance. Each additional hour of offset cut synchronous communication by 11%, and the Rice Business writeup of the study notes that it did so against a 19% loss of overlapping business hours.

The gap between those two numbers is the interesting part. Overlap fell 19%. Real-time contact only fell 11%. So people clawed back most of the difference. Somebody paid for that.

How? By working outside their own hours. In the same dataset, 43% of synchronous communication happened when at least one of the two people was outside normal business hours. Harvard Business School’s summary of the findings breaks that down further and the breakdown is uncomfortable. Men averaged 14% after-hours communication against 9% for women, a gap the researchers connect to who carries the evening at home. In countries with no statutory weekly hour limit, off-hours work ran 32%. Where a 35-to-39-hour week is enforced, it dropped to 9%.

So the coordination cost does not evaporate when you go offshore. It moves onto individuals, privately, at night, unevenly, and in some jurisdictions the law will not let it move at all. None of that shows up in a blended rate. All of it shows up in your attrition. Check your exit interviews.

I have watched one version of this go well and several go badly. The tell was always whether the burden got named out loud. A team that agrees the Bengaluru lead takes an 8 p.m. call twice a week, in exchange for something real and written down where the rest of the org can see it, is a team making a trade. A team where that call quietly became permanent has a resignation coming in about nine months. One of mine left over exactly that. She gave three weeks.

What a One-Day Tick Costs Over a Quarter

Herbsleb and Mockus put numbers on the delay itself back in 2003, in IEEE Transactions on Software Engineering, and the paper still anchors this area of research. Comparing work items inside one large software organization, they found that distributed work items took roughly two and a half times the calendar time of comparable colocated ones. The journal ran a retrospective on it in 2025, which tells you how well it has held.

The mechanism they identified matters more than the multiplier. Distributed work items pulled in more people, and the number of people involved turned out to be strongly predictive of how long the item took to close. Distance does not slow the typing. It widens the circle of humans who have to agree on something, and every added human is another tick. The typing was never the bottleneck.

That finding is twenty-three years old. It describes my Thursday-to-Wednesday nullable field with more precision than anything written since.

Run the arithmetic on your own team for a sprint and it stops being abstract. Count the questions that crossed the seam and needed an answer before work continued. Not messages. Questions that blocked. Most teams I have measured land somewhere between eight and twenty per two-week sprint. At one calendar day of latency each, with roughly a third of them generating a follow-up, you are spending two to three engineer-weeks of wall-clock time per quarter on waiting. The rate card saved you 38%. The calendar gave a chunk of it back and sent no invoice. Nobody reconciles that line.

Follow the Sun Works for Queues. It Does Not Work for Decisions.

Follow the sun is the model where work moves around the globe with the daylight so something is always in progress. The model is real and I have used it. It also fits a much narrower set of work than the people selling it admit.

Where it genuinely delivers: incident response rotations, monitoring and alert triage, batch job babysitting, long-running test and build pipelines, customer support queues, and data pipeline reruns. Each of those is a queue of self-describing work items. A pager fires, the runbook says what to do, and the next region picks it up with no context transfer required. Queues forgive a handoff.

Design work is not a queue. Design work is a conversation with state in it, and state does not survive a handoff to somebody who was asleep for the previous eight hours of argument. Arguments do not serialize.

The failure I see most often is a leadership team that read a case study about 24-hour development and concluded they could split a feature down the middle. Front end here, back end there, meet in the middle, ship twice as fast. What they get is a contract negotiation conducted entirely by asynchronous message, one round trip per day, for six weeks. Both halves are being built by good engineers. The seam between them is where the project lives, and nobody is awake at the seam.

My own bias here comes from a rebuild I led. Critical systems were wired together point to point, brittle in exactly the way that gets you paged, and we moved them onto a Kafka-based publish-and-subscribe backbone. Downstream processing latency fell 45%. I have recommended the same rebuild twice since.

It taught me something I did not expect about org design, though. Decoupling the systems did not decouple the teams. The services stopped waiting on each other. The people kept waiting on each other, because the thing actually coupling them was a set of decisions nobody had assigned. An event bus will not fix an unowned decision. It makes the waiting harder to see, which if anything is worse. I keep hitting the same pattern in team topologies in practice, where redrawing boxes on an org chart does nothing until the boundary decisions underneath them move too.

Write Down Who Decides Before You Pick a Country

The most common thing I see when I come into an engineering organization that is struggling is not a technology problem. It is a clarity problem. Distribution does not cause that problem. It prices it. Distance sends the bill.

A colocated team with fuzzy decision rights survives on hallway repair. Somebody notices a stall, walks over, and resolves it in under two minutes without anyone logging that a decision happened. Put nine hours between those two people and the same stall costs a day. Every time.

Which is why decision ownership has to be written down before a distribution model gets picked, not after. Before you sign anything, locate these five and name a person, not a team, for each:

1. Who resolves a requirements ambiguity without escalating. Name the human. If the answer is “they ask the product owner,” then your product owner’s time zone is now a hard constraint on your delivery model, and that belongs on the spreadsheet.
2. Who approves a schema or interface change. This was my nullable field. One named owner with authority to answer inside their own working day turns six days into six hours.
3. Who can say a story is not ready and send it back. Distributed teams accumulate half-specified work because rejecting it costs a round trip and everyone quietly decides to figure it out later. Across a big offset, treating estimates as informed commitments stops being a process nicety.
4. Who declares an incident and who runs it, per region, per hour. Write the hours down. “The on-call” is not an answer when on-call is asleep and the person who noticed is not authorized to page.
5. Who owns the seam. If a feature spans two time zones, one person is accountable for the interface between them, and that person’s calendar has to touch both. Teams forget to fill this seat. It decides whether any of the rest works.

Every item on that list is boring. It is also the difference between a distributed team and a set of people in different countries sharing a Jira instance.

The Overlap Audit

You can do this in a week, without a consultant, and it will change the spreadsheet. Start Monday.

Pull your team’s actual calendars for the last two weeks and mark the hours where every person who has to agree on something is awake and working. Not the hours where somebody could technically join from bed. Real working hours. Check the calendars, not the contract.

Then log every blocked question that crossed a time zone seam in that period, with the timestamp it was asked and the timestamp it was answered. Your ticketing system will not have this. Slack does. Export the channel.

Three numbers go on one page.

• Median usable overlap, in hours per day. Under four and you are running an asynchronous contract whether you designed one or not.
• Median hours from blocked question to usable answer. If this is over twelve, every dependency in your plan is really a day.
• Count of blocked questions per sprint, times that median. This is your coordination bill, in engineer-hours, and it is the number to hold next to the rate savings.

These are instrument-level numbers, the same kind I argue for in delivery metrics that actually predict velocity, just pointed at the clock instead of the pipeline. Show me the data on those three and I can usually tell you in twenty minutes whether your model fits your work, without knowing anything about your stack. A team with six hours of overlap and a four-hour answer time can build almost anything. A team with ninety minutes of overlap and a nineteen-hour answer time can build what was fully specified before the sprint started, and will struggle with everything else, which is most of what any roadmap worth funding actually contains. Standup discipline does not change that. I have watched teams try.

Which Seats Have to Live in Your Time Zone

Some roles are overlap-critical and some are not. Getting this wrong is more expensive than getting the country wrong. I have done both.

Overlap-critical, in my experience: the tech lead on anything with unsettled requirements, the person who owns the seam between two distributed groups, the architect during a migration, and whoever runs incident command for your business hours. What those share is that their output is decisions, and decisions carry a latency cost that compounds. Latency compounds quietly.

Far less sensitive: platform and infrastructure work behind a stable interface, test automation, data pipeline construction against a fixed contract, SDK and integration work with published specs, and most maintenance on a mature service. I have run all of those across a 12-hour gap successfully. They ask few questions, and the questions they do ask are answerable from a document. The specs did the talking.

So the sequencing that tends to work is unglamorous. Put your decision-makers inside your own working day, then distribute the execution as widely as the labor market rewards. Decisions first. Hands second. Most organizations do the reverse, because the execution seats are the ones with a headcount number attached and the decision seats are the ones that read as overhead right up until the quarter where nothing ships and the board starts asking why.

When the overlap-critical seat is the one you are missing, the honest options are a direct hire, which is slow, or a contract engineer who has done it before, which is faster. KORE1’s IT staffing practice fills roles in an average of 17 days across 30 or more U.S. metros, which matters here because an onshore lead placed in three weeks can make a 12-hour-offset delivery pod viable. The same pod with no lead in your hours will burn a quarter proving it is not. If you need a group rather than an individual, they keep a bench of contract engineering teams who have shipped together, which removes the variable nobody prices, namely strangers learning each other. Teams that already fit save a month. For the decision seat at the top, that is VP of engineering staffing. For the execution seats around it, contract staffing is usually the right instrument while the model is still being proven.

Before You Sign Anything With a Nine-Hour Offset

So What Counts as Nearshore, Exactly?

Nearshore means a nearby country close enough to share most of a working day, typically within two hours of your own. For U.S. companies that is Mexico, Costa Rica, Colombia, Argentina, and Brazil.

The word gets stretched by whoever is selling. I have seen vendors market a 7-hour offset as nearshore on the strength of being in the same hemisphere. Ignore the label and look at the offset. If you cannot hold a 10 a.m. call that lands inside both teams’ normal hours, it is not nearshore, whatever the deck says. Check the offset yourself.

How Many Overlap Hours Do We Actually Need?

Four hours is the practical floor for work with open requirements, and six is where a distributed team stops feeling distributed. Under two hours, plan for an asynchronous contract with written specs at every seam.

Those thresholds are mine, not a research finding, drawn from teams I have run and teams I was brought in to fix. Four is the floor for a reason that is arithmetic rather than philosophical. You need one window long enough to hold a real design discussion, plus a second window later in the day where a blocked person can get unblocked before their day ends. Squeeze both into ninety minutes and one of them gets skipped. It is always the second one. I have skipped it myself.

Is Offshore Ever the Right Call?

Often, for work that does not generate questions. Settled specs, stable interfaces, bounded scope, and a named owner in your own hours are the four conditions, and offshore delivery is reliable when all four hold.

There is a lazy version of this argument that ends with never hiring outside the country. I am not making it. Two of the strongest engineers I have worked with sat nine and a half hours ahead of me, and the question was never whether they were good. It was whether the work we handed across could be fully described in writing, because writing was the only channel the clock left us. We wrote more. It worked.

We Already Signed a Twelve-Hour Contract. Now What?

Do not restructure. Buy back decision latency instead by naming one owner in your hours for every recurring question type, and moving one senior person’s day to create a real two-hour window.

Three things, in order. Write the decision list from the section above and assign it to named people, which costs nothing and fixes most of it. Then pull your top five recurring question types from the Slack export and pre-answer them in a document the pod can read at 2 a.m. without you. Then, and only then, talk about a shifted schedule, compensated properly and rotated, because an uncompensated permanent night shift is how you lose the person you can least afford to lose. Renegotiating a signed contract is expensive and usually unnecessary. Most of the pain is decision latency, not geography. Fix the latency first.

Does Async-First Fix the Time Zone Problem?

It converts the problem rather than solving it. Async-first replaces waiting with writing, which works well for status and specifications and poorly for anything still being argued about.

Async-first is a real discipline and the teams that do it properly are better than the teams that do not. I recommend it. Watch what it asks of you, though. Every decision has to be written down, with context, by somebody who has the authority to make it, before the other side wakes up. Organizations that were already bad at writing things down do not become good at it because they hired in Manila. They move the same ambiguity into a slower medium. The ambiguity survives the move. Async-first multiplies written clarity, so if clarity is near zero, the product is too.

Onshore Costs Nearly Three Times as Much. How Do I Justify That to Finance?

Bring the coordination bill, in engineer-hours, from your own overlap audit. A rate comparison with no latency column is not a complete model, and finance teams accept that correction more readily than engineering leaders expect.

The framing that lands is not “onshore is better.” It is that both quotes are priced per hour worked, while your delivery date depends on hours elapsed, and the gap between those two is measurable. Take the blocked-question count times median answer time, convert to engineer-weeks per quarter, and put it in the same table as the savings. Sometimes offshore still wins that math. It wins honestly, which means nobody is surprised in month seven. Surprise is the real cost. I have written separately about how to build an engineering budget your CFO will approve, and this is the same move applied to a smaller decision.

Put the Fourth Row on the Spreadsheet

Before the next vendor comparison goes to your leadership team, add one row under the rates. Usable overlap hours. Then add a second row for median time from blocked question to answer, and if you do not have that number yet, the audit above takes a week.

Rates are a price. Overlap is not. It is a design decision, and it constrains what your team can build in a way that the price never does.

If you run the audit and the three numbers surprise you, message me on LinkedIn with them and I will tell you which model I think your work actually fits. And if the answer turns out to be a seat you do not have, a lead inside your own hours or a pod that already knows how to work across a clock, talk to a KORE1 recruiter before you renegotiate a rate card that was never the problem.