Distributed delivery is sold as "follow the sun" and experienced as "nobody answered until the afternoon". The difference is arithmetic, and it is worth doing before a project starts rather than during it. Here is what the overlap actually looks like between a client in Europe or the United States and development teams in Amman and Tbilisi.
The numbers
Amman is UTC+3 all year: Jordan does not change its clocks. Tbilisi is UTC+4, also all year. So the two development centres are one hour apart, permanently, and neither shifts under the other.
What a client's 9-to-5 looks like for them:
| Client | In Amman | In Tbilisi |
|---|---|---|
| Berlin, summer | 10:00 – 18:00 | 11:00 – 19:00 |
| Berlin, winter | 11:00 – 19:00 | 12:00 – 20:00 |
| London, summer | 11:00 – 19:00 | 12:00 – 20:00 |
| London, winter | 12:00 – 20:00 | 13:00 – 21:00 |
| New York, summer | 16:00 – 00:00 | 17:00 – 01:00 |
| New York, winter | 17:00 – 01:00 | 18:00 – 02:00 |
Computed from the IANA time zone database on 18 September 2026. European and US clocks change on different dates, so for a few weeks each spring and autumn these differ by an hour.
What the table means in practice
For Central European clients, there is no problem to solve. A Berlin working day is an ordinary working day in both Amman and Tbilisi. The overlap is the whole day, which means ordinary working habits — a call in the morning, a question answered in an hour — work without anybody making an effort.
For UK clients, the overlap is still most of the day, and the difference shows up at the end: a 4pm London question lands at 8pm in Tbilisi. Worth knowing when you set expectations, and easy to plan around by agreeing when the day ends.
For US clients, the overlap is the client's morning. A New York 9am is 4pm in Amman and 5pm in Tbilisi. That is a real window — roughly the first half of the US business day — but it is the end of the day for the team, so it has to be used deliberately rather than assumed.
How to run a day across it
Put the overlap to work, not to waiting. The hours when both sides are awake should be used for the things that need two people: decisions, reviews, demos, anything with a question in it. Solo work belongs outside them.
Write the handover down. A team finishing its day should leave a short written state: what moved, what is blocked, what needs an answer. This is the single habit that separates distributed teams that work from ones that generate meetings.
Answer questions asynchronously by default. If every question needs a call, the time zones set your speed. If most questions are answered in writing with enough context, the difference stops mattering for most of the work.
Agree what "urgent" means, and what happens then. Not a promise of instant response at any hour — an agreement about which things justify reaching someone outside their day, and how.
Why two centres, one hour apart, is useful
Two development centres in adjacent time bands is not "follow the sun": the sun barely moves between Amman and Tbilisi. What it gives is a deeper bench in the same working window — more people who can pick something up during the hours a European client is awake, and continuity when one office has a public holiday the other doesn't.
Different countries also means different national holidays, which is an advantage if you plan for it and an irritation if you discover it.
Our development teams work from Amman and Tbilisi: what we build and how we support it.
Sources
- Time differences computed from the IANA time zone database, 18 September 2026, for both halves of the year.