Working with an engineering partner across time zones

The offset is not the problem

Picture a building-products distributor that hires a development team six time zones away, and a twelve-week build that lands in twenty-one. Everyone involved will describe the cause as the time difference. It usually is not. It is that the only person who can say how a backorder should behave when a supplier ships partial is the operations manager; she is on the warehouse floor until four, she answers email in a burst around nine at night, and by then the engineers have been asleep for three hours. Each question costs a calendar day. Forty questions across a build is eight working weeks, and no rate negotiation touches it. That pattern is common enough to treat as the default failure mode rather than bad luck.

That is the shape of most distributed engineering trouble, and its structure is simple. The offset sets the price of a round trip. Your organization sets how many round trips are required. Multiply the two and you have the schedule. Most companies negotiate hard on the hourly rate and never look at either number.

The good news is that both are controllable and one of them is almost entirely under your control. A team that owes four blocking questions a week to a decision-maker who answers within the overlap window will run fine at eleven hours of offset. A team that owes twenty-five to a decision-maker who answers on Fridays will run badly at two.

What each offset actually gives you

Overlap is arithmetic, and it is worth doing before the kickoff rather than after. If your people work eight to five and the other side works nine to six local, here is roughly what you get without anyone changing their life.

Two practical notes on that table. First, the numbers move twice a year and not by the same amount on both sides, because the United States and Europe change clocks on different dates and much of Asia does not change at all. For two to three weeks in March and again in late October, an established six-hour offset is seven, and a standing 8:00 call lands at a different local hour for one party. Put the meeting in a calendar with a real time zone attached rather than a fixed UTC hour, and expect one confused morning per year regardless.

Second, three hours of daily overlap is the floor we plan around for anything where the requirement is still moving. Below three hours the work has to be specified well enough to run unattended, and specifying it that well takes senior time on your side, which is exactly the resource distributed teams are usually hired to conserve.

The number that predicts the outcome

Count blocking questions per week. A blocking question is one where an engineer cannot correctly proceed without an answer from your organization: how does a partial shipment behave, which of these two customer records is authoritative, does a canceled appointment release the room immediately or at end of day, what does this field mean when it is empty.

Then measure how long they wait. In a healthy engagement at a six-hour offset, the median answer arrives in under four working hours and the ninety-fifth percentile is under one business day. When the median passes one business day, the engineers start guessing, and a guess that is wrong is not discovered for two to six weeks, which is when it becomes expensive.

Notice where raw overlap sits. It matters, but it is downstream of whether anyone on your side is actually available to decide. A two-hour-offset project can stall for a month because the one person who understands the pricing rules is traveling. An eleven-hour project can run clean because a plant manager blocks forty-five minutes at 6:45 every morning and answers whatever is in the queue. The offset decided neither one.

Write the question so it can be answered without you in the room

The single highest-return habit in distributed work costs an engineer four extra minutes per question. Instead of "how should partial shipments work?", the question arrives as: here is the case, here are the two or three options, here is what each one implies, here is the one we will build if we do not hear back by Thursday, and here is what it will cost to change later.

That format does three things. It converts a conversation into a decision an operations manager can make in ninety seconds on a phone. It makes silence safe, because there is a stated default. And it creates a record, so when someone six months later asks why partial shipments behave this way, the answer exists in writing with a name on it.

Insist on it. If the team you hire sends you open-ended questions, the fix is not more calls; it is telling them to send options and defaults instead. Any competent team will adopt it immediately, because it is better for them too.

Spend the overlap on decisions, not status

The most common waste we see is a daily thirty-minute status call held during the only two hours the two sides are both awake. Status is the thing that transmits perfectly in writing. Decisions, disagreements, and anything where somebody needs to see a face are what the overlap is for.

A cadence that holds up at a six-hour offset: a written end-of-day note from the engineering side that lands in your morning, twenty-five minutes of live time twice a week for decisions only, one recorded walkthrough of working software each week, and an open channel where anything urgent is flagged with a clear expectation of when it will be seen. That is roughly one hour of live meetings a week, and it is enough for most builds.

The recorded walkthrough is the item people skip and should not. Five to eight minutes of somebody clicking through the actual screens, narrated, watched by your operations lead at whatever hour suits her. It is the cheapest way we know to catch a misunderstanding in week three instead of week eleven, and it works precisely because it does not require both parties awake.

Incidents are where the offset actually bites

Building software across an offset is manageable. Running software across one is a different problem, and it is the part most contracts handle badly.

Take the distributor again. The nightly supplier feed lands at 2:00am Eastern and has to be reconciled before the 6:00am pick list prints. If it fails, someone has ninety minutes to fix it or the warehouse starts the day blind. At a six-hour offset that is a fair arrangement, because 2:00am Eastern is 8:00am in Warsaw and somebody is at a desk. At a thirteen-hour offset it is 3:00pm in Manila, which is also fine. At a two-hour offset it is 4:00am for everyone and nobody is awake at all. Offset is not better or worse for on-call; it is a schedule to be designed on purpose.

Three things to settle in writing before go-live, not after the first outage. Who is paged, by what mechanism, and what happens if they do not acknowledge in fifteen minutes. What the response commitment is in hours, separated from any resolution commitment, because those are different promises and conflating them is how support agreements become arguments. And which of your people can authorize a fix that touches production at 3:00am without waiting for a morning approval, because an engineer who has diagnosed the problem and cannot act on it is worse than no engineer at all.

Where distributed work is the wrong shape

There is work we tell people not to do this way, and it is worth being direct about it.

Discovery where nobody can yet describe the requirement. If the honest state is "we know the scheduling process is a mess but we cannot tell you the rules", that is two or three weeks of somebody sitting next to the people doing the work, watching, and writing it down. Doing that across eleven hours costs three times as much and produces a worse document. Do the discovery close, then distribute the build.

Anything with a physical component. A label printer that jams on a specific stock, a scanner that misreads under warehouse lighting, a kiosk in a clinic lobby. Somebody has to be standing in front of it.

Work that is genuinely two weeks long. Setting up a distributed engagement has a real fixed cost: access, environments, context, the first misunderstanding. Under about six weeks of work, that overhead eats the savings. A short, well-defined job is often better given to whoever can start Monday, even at a higher rate.

And the case worth saying out loud: sometimes you do not need software at all. A twelve-location restaurant group asks for a labor scheduling tool. Dig into it and the real situation is often two managers overriding the forecast every week because it does not know about a stadium three blocks away. The fix is a shared calendar of event dates and a rule about when to add a third closer. A scheduling build would reach the same answer more slowly, at somewhere between thirty and sixty thousand dollars.

The mistakes that do the most damage

• The daily status call scheduled during the only overlap, so decisions wait and status gets discussed live
• No named decision-maker, so every question routes to whoever answers first and answers conflict
• Questions sent open-ended, with no options, no default and no deadline
• Sanitized sample data that has none of the messiness the real system contains, so the build is correct against fiction
• Response time and resolution time promised as one number, which nobody can meet and everybody argues about
• Meetings pinned to a UTC hour, drifting into someone's evening for three weeks after a clock change
• Demos as slides instead of working screens, hiding a misunderstanding until acceptance
• No one on your side authorized to approve a production fix overnight

Before the first sprint

• One named person who decides, with a stated window when they answer
• A written count of blocking questions expected per week, and a target answer time
• Overlap hours calculated for both clock-change periods, not just today
• Access to a working environment with realistic data, granted before day one
• The question format agreed: case, options, implications, default, deadline
• A weekly recorded walkthrough of running software, not slides
• Paging path, response commitment and resolution commitment written separately
• Someone on your side who can authorize an overnight production change

Bottom line

Distributed engineering works, and it works at offsets people assume are impossible, but only when the work is described well enough to proceed without a conversation and somebody on your side is genuinely available to decide. Before you compare hourly rates, count the decisions your organization owes per week and name the person who will make them. If that person does not exist or cannot be freed up, the offset is irrelevant, because the project will run badly at any distance, including down the hall.

Frequently asked questions