Why time zone matters more than the hourly rate

A low hourly rate in a distant time zone can cost you more than it saves. The invoice counts hours, but the delay is in the questions: every question that sits overnight costs a day. With a team in your own time zone, the same question costs fifteen minutes. So when I compare teams, I look at overlapping working hours first and at the rate second.

How much overlap you keep

Say both sides work from 9 to 5. This is the overlap you keep per day:

With four hours of overlap you can ask a question, get an answer the same day and still ask a follow-up. With two hours that works once, if everyone responds in time. Below that, almost every question waits a night, unless someone shifts their working hours. I would not count on someone working evenings for years to overlap with you.

A question that waits overnight

Developers ask questions, about a ticket that is not quite clear or about an edge case nobody saw coming. If your team is in your time zone, you reply in Slack and the work continues within fifteen minutes.

With a night in between, every question becomes a day. A ticket with three open questions takes three days longer. Code review works the same way. A pull request that comes in at the end of their day gets your comments after they have gone home, and the fix arrives the next day. One more round and two days have passed for a ten-line change.

While they wait, developers pick up something else or start guessing. The first means more work in progress and more context switching, the second sometimes means work has to be redone.

The costs that are not on the invoice

An invoice shows hours times rate. What it does not show:

• the days of lead time lost to waiting
• the extra time you spend writing everything out in detail upfront
• meetings at awkward hours, for you or for them
• a production problem that starts while your team is asleep

That last one weighs heavily. If something breaks at ten in the morning your time, you want someone awake who knows the code.

Writing things down is good in itself: a remote team works better with clear tickets, even in the same time zone. With a large time difference, though, everything has to be complete upfront, because you cannot quickly call to clear something up. Boris describes what to write down and what can go in a call in async work: what to write down.

Daylight saving time makes it messier

In the EU, summer time starts on the last Sunday of March and ends on the last Sunday of October. The United States switches on the second Sunday of March and the first Sunday of November. For a few weeks a year, the gap between Central Europe and the US East Coast is an hour smaller than usual, and recurring meetings shift.

If you work with a country that has no daylight saving time, the difference changes by an hour twice a year. That is manageable, but it is one more calendar to keep track of.

Serbia is in the same time zone as the Netherlands and Germany, also in summer, so none of this applies there. The practical side of working with Serbia is covered in working with developers in Serbia.

When a large time difference does work

A large time difference works when the work is well defined and raises few questions, such as a separate module with a clear specification. It also works when the team on the other side has its own product owner and lead and delivers complete features. For support it can even help that someone is awake while you sleep.

A developer who sits inside your own team and talks to your product people every day needs overlap. That is how we work: our developers join the client's team, during the same hours.

How to compare partners fairly

1. Count the overlapping working hours, and check the weeks around the clock changes.
2. Ask who answers a question at four in the afternoon, your time.
3. During a trial, measure lead time per ticket, from start to merge.
4. Work out the cost per delivered ticket, next to the cost per hour.

Our trial lasts two weeks, and if it does not work out you pay nothing. The rest of the process is described under how we work. Bas lists what a developer costs in total, including hiring in-house, in hiring in-house or nearshore.

Sources

• European Commission: summer time in the EU
• NIST: Daylight Saving Time rules