The unit economics of a 100% remote engineering team

The spreadsheet every founder runs first

Every founder building a remote engineering team runs the same spreadsheet before the first offer letter goes out. Put a senior backend engineer in San Francisco against the same role in Bengaluru, Lisbon, or Manila, and the salary line alone moves by 30 to 60 percent. Add the cost of an employer-of-record service, a laptop shipped overseas, and a slower ramp to full productivity, and the gap narrows a little. It almost never closes.

That single number, somewhere between saving forty thousand dollars a year per engineer and saving ninety thousand, is usually the deciding input for the hiring plan. It is not a bad number. It is just an incomplete one, and the part it leaves out does not show up on an invoice, so nobody puts it in the spreadsheet.

What the remote engineering team spreadsheet leaves out

The missing variable is overlap hours: the number of hours each day when two engineers on two different clocks are both awake, online, and able to answer a question in real time. A team split between New York and London has roughly five hours of overlap on a normal working day. A team split between San Francisco and Bengaluru has close to zero, since a 9-to-6 day in California ends around the time a 9-to-6 day in India is just getting started, twelve and a half hours apart.

Overlap hours don't appear in a compensation benchmarking tool, because they are not a cost in the accounting sense. They show up later: as a pull request that sits unreviewed for a full day because the only two people who understand the change are never awake at the same time, or as a design decision that takes a week of comment threads instead of a twenty-minute call. None of that is invisible to the engineers living through it. It is invisible to the spreadsheet.

The coordination tax, and what actually proves it is real

There is real research behind this now, not just engineering-team folklore. A 2024 study in Organization Science, by researchers at Rice University, Harvard Business School, and Georgetown University, analysed internal communications data from more than 12,000 employees at a Fortune 100 multinational. Their finding: every additional hour of temporal distance between two employees reduced the synchronous communication between them by roughly 11 percent. Stack four or five hours of separation onto a working relationship and real-time collaboration drops sharply, not because anyone decided to talk less, but because the windows to do it shrink.

The same researchers found that employees respond by time-shifting: quietly moving their own working hours earlier or later to manufacture more overlap with colleagues abroad. That is a coping mechanism, not a fix. It moves the coordination tax from "slower reviews" to "an engineer taking calls at nine at night three times a week," which is a real cost too, just one that shows up in attrition and burnout instead of a sprint report.

Put plainly, the coordination tax is the extra cycle time, decision latency, and rework a team accumulates as a direct function of how little overlap it has, independent of how skilled or motivated anyone on it is. It does not show up as a line item. It shows up as a slower release cadence that everyone quietly blames on process instead of geography.

A rough model for where your team sits

You don't need the original dataset to use the finding. You need a rough map of where your team's timezone pairs land, because the effect is not linear: a team with six hours of overlap behaves close to a co-located team, and a team with zero hours of overlap behaves like two separate teams that occasionally hand off work, with most of the difference concentrated in between.

This is a rule of thumb, not a formula with decimal places. But it is enough to do the thing the salary spreadsheet can't: tell you, before you hire, whether the role you're filling is the kind of work that tolerates its timezone pairing or the kind that will quietly fight it for the next two years.

Here is a hypothetical, but realistic, way to size it. Take a five-engineer team where three sit in a low-overlap region. If a typical pull request takes one day to merge inside a high-overlap pairing, and closer to two and a half days inside a near-zero-overlap pairing, and each of those three engineers opens three pull requests a week, that is roughly four and a half extra engineer-days of work sitting idle in review every single week, all year. None of that shows up as a cost on payroll. It shows up as features that take a third longer to ship than the roadmap assumed, for reasons nobody can point to on any single day.

Where the savings still win

None of this is an argument against hiring remotely or across distance. For a large share of engineering work, especially anything with a clear owner and a well-defined interface (a service behind a stable API, a feature behind a flag, an internal tool nobody else touches) low overlap costs almost nothing, because the work was never going to need five round trips of real-time discussion. The salary savings land cleanly, and the coordination tax bill never really arrives.

This is also where hiring two engineers in the same low-overlap region, instead of one engineer each in two different low-overlap regions, pays for itself. Two engineers in Bengaluru can pair with each other during their own overlap-rich hours and only need to sync with the US side at the edges, which spreads the timezone cost across a pair instead of charging it on every single interaction. A support rotation or an SRE on-call setup goes further still: zero overlap is the entire point of a follow-the-sun handoff, since the work is structured around clean shift boundaries rather than shared real-time context.

Where it doesn’t, and what to do instead

The tax bites hardest on work that's inherently collaborative and ambiguous: early architecture decisions, incident response, anything where the spec is still being worked out in conversation rather than written down. Putting a zero-overlap pair on that kind of work does not just slow it down. It tends to produce worse decisions, because a discussion that should happen in one sitting gets split across three days of partial context.

Incident response is the clearest version of this. A production outage doesn't wait for the next overlap window, and a team that built its on-call rotation around salary savings rather than overlap will find that out at 2am local time for whoever is awake, with the engineer who actually understands the failing service asleep on the other side of the planet. Teams that get this right keep ambiguous, high-stakes ownership, like the service that pages the most, inside a single timezone cluster, even if that cluster costs more per head.

The fix is not avoiding distance. It is being explicit about it before the org chart gets drawn. Put the ambiguous, fast-moving work inside whichever timezone cluster has the most overlap, and route the well-scoped, stable work across the boundary. Write design docs built for a single round of asynchronous feedback rather than a conversation, with the open questions stated upfront instead of buried in a wall of context. And treat the one daily overlap window, where there is one, as something to protect rather than something to fill with status updates that could have been written instead.

The teams that get the most out of remote hiring are not the ones with the best overlap. They are the ones that decided, before the first offer went out, exactly which kind of work was going to cross the timezone boundary, and which kind was not going anywhere near it.