Working across time zones with a nearshore team
How to work across time zones with a nearshore team: overlap windows, a weekly rhythm, written decisions and what to do when the US clocks change.
Working across time zones with a nearshore team comes down to four habits: agree a fixed overlap window, write decisions down, demo working software on a set cadence, and plan for the two days a year when the US clocks change. A team on UTC-5 shares the whole day with US Eastern in winter and with US Central in summer, so most of the friction people expect from distributed work simply does not appear. This guide covers the rhythm we use and the failures to avoid.
We are based in Armenia, Colombia, on UTC-5 year-round, and we work with US companies across several time zones. What follows is the operating practice we have settled on, not theory. It applies to any nearshore team, though the specific hours below reflect our own.
The clock, first
Colombia does not observe daylight saving time. It is on UTC-5 all year. The US observes it, so the offset between a US team and a Colombian team changes by an hour twice a year. The table shows the offset to Colombia for each US zone.
| Your time zone | Winter offset | Summer offset | Practical overlap |
|---|---|---|---|
| Eastern | Same clock | You are 1 hour ahead | Full working day, slightly shifted in summer |
| Central | You are 1 hour behind | Same clock | Full working day, slightly shifted in winter |
| Mountain | You are 2 hours behind | You are 1 hour behind | Most of the day |
| Pacific | You are 3 hours behind | You are 2 hours behind | A solid morning on your side |
The numbers are straightforward arithmetic, and you should check them against your own calendar before committing. For Eastern and Central companies the working day is shared almost completely. Pacific companies share the morning, which is when most meetings happen anyway.
Agree an overlap window explicitly
Even when two teams share most of the day, they do not need to be online together all day. The most useful thing you can do is agree a core overlap window, a block of hours when both sides are reachable and decisions get made, and protect it.
- Pick the window from the client side. Put your standing meetings on the calendar first and fit the team around them, not the reverse.
- Keep it short and regular. A few hours of reliable availability beats a vague promise of "always online".
- Put it in writing. A line in the project charter noting the hours in both time zones removes most disputes later.
- Name the exceptions. Decide in advance how urgent issues outside the window are reached, and who is the contact.
Outside the window, people work independently. That is fine, provided the work is clear enough to continue without constant questions, which is the subject of the next sections.
A weekly rhythm that works
The routines matter more than the tools. This is the shape we use with most clients:
| Cadence | What happens | Why it exists |
|---|---|---|
| Daily | Short check-in inside the overlap window; written update in the shared channel | Catch blockers early |
| Weekly | Planning of priorities and a short written summary of what changed | Keep scope visible to everyone |
| Each milestone | Live demo of working software against agreed acceptance criteria | Prove progress with software, not slides |
| Monthly or quarterly | Review of what is working, what is not and what to change | Stop small frictions becoming habits |
Notice that most of this is written. A daily live meeting that no one records leaves anyone who missed it uninformed. A written update that takes five minutes to read is worth more than a standing hour that three people attend.
Write decisions down
Teams that work across time zones succeed or fail on documentation habits. The goal is that anyone, including an engineer who joins next month, can understand what was decided and why.
- Decision log. A running document of decisions: the decision, the reason, the date and who made it.
- Tickets with acceptance criteria. Each piece of work states what done looks like, in terms a person can test.
- Pull request descriptions. What changed, why, how to test it and what is not covered.
- Architecture notes. Short documents for each significant design choice, stored in your repositories.
This is not bureaucracy for its own sake. It is the cheapest way to avoid repeating a conversation, and it protects you if people change. All of it lives in your repositories from day one, which is also what keeps the code yours. The ownership terms are summarized on our trust page.
Run fewer, better meetings
When you share hours, it is tempting to meet constantly. Resist it. A few rules help:
- Every meeting has an agenda sent in advance and a written outcome afterward.
- Use calls for decisions and demos, and use writing for status.
- Keep standing meetings in a fixed slot so no one has to hunt for a time.
- Record demos so stakeholders who cannot attend can watch later.
Plan for the clock change
The two dates a year when the US changes its clocks catch distributed teams out every time. Colombia stays put, so your meeting at 10:00 Eastern is at 10:00 Colombian time in winter and at 09:00 in summer. The fix is boring:
- Put recurring meetings in a calendar that handles time zones, and check them the week the US changes.
- Send a short note a week before each change confirming the new local times for each side.
- Hold milestone dates and deadlines in a single stated zone, such as Eastern, to avoid ambiguity.
Why this matters more for AI projects
AI work benefits from short feedback loops. An agent that handles customer questions improves by reviewing real conversations with someone who knows what a good answer looks like. When that review happens inside the same working day, the next version can be tested the following morning. When it happens across a twelve-hour gap, each cycle takes a day or more. Over a project, the shared day compounds into a faster calibration process. Our approach to this is described in AI agent development, where evaluations against real examples serve as acceptance criteria.
If you are comparing this model with a team on the other side of the world, nearshore versus offshore versus onshore sets out where the trade-offs lie.
What goes wrong, and how to fix it
| Symptom | Likely cause | Fix |
|---|---|---|
| People wait a day for answers | No agreed overlap window or contact | Define the window and an escalation path |
| Rework after demos | Acceptance criteria not written | Add testable criteria to each ticket |
| One side feels out of the loop | Decisions made on calls but not recorded | Keep a decision log, share it weekly |
| Meetings multiply | Using calls for status | Move status to written updates |
| Missed meetings twice a year | Clock change not planned for | Pre-announce the new local times |
When a time-zone match is not enough
A shared clock helps, but it does not replace clear ownership. If no one on your side can make decisions during the overlap window, the team will wait, whether it sits in Bogotá or Boston. A nearshore team also cannot replace on-site presence for hardware, retail or facility work. We cover those limits in nearshore software development in Colombia.
Frequently asked questions
How many hours of overlap should we expect?
For Eastern and Central companies, most of the working day. For Pacific companies, the morning. We do not promise a specific number of hours for every client, because it depends on your schedule. We agree a core window with you at the start.
Does the daylight saving change affect us?
Yes, by one hour on the US side, because Colombia does not change its clocks. Pre-announce the change and keep milestone dates in one stated time zone.
Do we need daily meetings?
A short daily check-in is useful for most active builds, but written updates carry most of the information. Keep live time for decisions and demos.
What if something breaks outside the overlap window?
Agree an escalation path in advance: who is contacted, by what channel and what counts as urgent. For AI systems in production, our AgentOps service from $1,500 per month covers monitoring and response.
How do we try this before committing?
Start with a short paid piece of work and run the rhythm above for two weeks. If the communication works, the build will too. Book a scoping call and we will set one up.