For the first few months at a top US-based company I work with, I stayed logged in until nearly midnight Nairobi time. Not because anyone asked me to. Because it felt like the professional thing to do: my team was online, they were moving fast, and I wanted to be there when things came up. That logic made complete sense. It also wore me out steadily, made my mornings foggy, and, when I finally traced it back, cost me nothing in actual output because most of what arrived in those late hours could have waited until my morning anyway.
The fix was not a big mindset shift or a courageous conversation. It was a set of small decisions about when to be online, what to write, and how to end each workday. If you are building a remote career with a US-based employer from East Africa, or anywhere else with a long timezone gap, this is what actually worked for me.
The Trap: Treating Their Clock as Your Clock
The first instinct when you join a US team from eight time zones away is to anchor yourself to their schedule. They open Slack at 9 AM Pacific; you translate that and make sure you are present. They have a stand-up at noon their time; you join at 8 PM yours. It feels like commitment. It reads as availability.
The problem is that it is not sustainable past the honeymoon period. You end up doing two full workdays: your real Nairobi morning where you get things done, and then a long, fragmented tail into the evening waiting for their day to start. The second shift rarely produces your best work. You are tired, your focus is gone, and most of what you are waiting for turns out to be asynchronous anyway.
More critically: being online does not equal being trusted. Trust comes from delivering reliably, communicating clearly, and being predictable. None of those require matching a timezone you were never in.
The Overlap Window Is Your Currency
Between Nairobi (EAT, UTC+3) and US Eastern (EST, UTC-5) there is roughly a two-to-three-hour window each afternoon where both clocks are awake at the same time. With US Pacific the overlap is shorter, sometimes barely an hour at the edges of the day. This window is genuinely valuable. The question is what you put inside it.
I protect those hours for things that actually need real-time interaction: a decision that requires context too complex for writing, a conversation with a new teammate where tone matters, anything with emotional weight that benefits from hearing a voice. Those things earn live time. Everything else does not.
The overlap window shrinks badly if you fill it with things that could have been a Loom recording, a written update, or a comment thread. Guard it for the exchanges that genuinely need two people present at the same moment, and leave the rest for async.
Writing for the Reader Who Wakes Up Eight Hours Later
Async communication is a skill, not just a habit. There is a version of it that creates more back-and-forth than a live call would, and a version that moves work forward while both parties sleep. The difference is in how you write.
A bad async message gives half the context and ends with a question. The other person wakes up, reads it, needs more information to answer, asks a follow-up, and you both lose a full day. A good async message gives the full picture upfront: what you did, what you found, what you need, and what you will do if you do not hear back by a certain time. It anticipates the obvious next question and answers it before it is asked.
Concretely, I changed three things about how I write to my US colleagues:
- State the ask in the first two sentences. Do not build up to it. People skim, especially when they wake up to twenty-three unread threads.
- Include a default action. "If I do not hear back by my EOD, I will proceed with option A" removes a whole cycle of waiting. It also signals that you are not blocked, you are moving.
- Separate observations from requests. "FYI" messages and "need a decision on this" messages look identical if you do not label them. One requires nothing, the other requires something. Make that clear immediately.
This sounds obvious. Most people still do not do it consistently. When you write this way, your messages land better and replies come faster, even across an eight-hour gap.
Ending Each Day With Something Finished
The single most useful habit I built was a short end-of-day note: what I completed, what is in progress and where it stands, and what I need (if anything) before the next morning. It takes roughly five minutes and goes into the shared project thread or directly to whoever owns the decision I am waiting on.
They wake up in San Francisco at 9 AM to a status that is already current. They are not starting their day wondering where the Nairobi work landed. I am not starting my next morning recovering the context I lost overnight. The note is also, quietly, a visibility record: over weeks it becomes a clear picture of consistent output, which matters a great deal when your manager has never shared a room with you.
This is how you build trust across a timezone gap without being always-on. You become predictable: they know what to expect from you, when to expect it, and how to reach you when something is urgent. That predictability is worth more than twelve more hours of vague availability.
What Still Requires Real-Time Presence
Not everything can be async, and pretending otherwise creates its own problems. A few things genuinely require being present in the same moment:
- Anything that is going wrong fast. When a system is down or a customer situation is escalating, back-and-forth over text is too slow. This is when you join the call at an unusual hour without complaint, because it is the right call and it is time-bounded.
- Relationship moments. The first meeting with a new colleague, a performance review, a promotion conversation. These shape how someone sees you and they are harder to repair over text if they go poorly.
- Anything where tone is load-bearing. Sensitive feedback, a disagreement about direction, a moment where what you mean and what you write are easily confused. Default to voice for those.
The point is not to refuse synchronous time. The point is to be deliberate about it so you are fully present when it matters, rather than burned out from being half-present all the time.
A Note to the Person About to Sign That First International Remote Contract
If you are negotiating a remote role with a US company right now, say your working hours clearly and early. Not as an apology, as a fact. "I work 8 AM to 5 PM EAT. My overlap with US Eastern is roughly 3 to 5 PM my time. I structure my work to deliver async and am reachable on short notice for urgent matters."
This tells a thoughtful employer that you have done this before (or that you have thought carefully about how to do it well). It tells a less thoughtful employer something important about whether this arrangement will work. Either outcome is useful to know before you sign.
The companies worth working for have seen this film before. They know that a disciplined remote worker in Nairobi who writes well and delivers consistently is worth more than an anxious one who stays online until 1 AM to prove they care. If they do not know that yet, you can show them. But you cannot show it while you are exhausted.
The Concrete Shift
I logged off at a reasonable hour and the work did not fall apart. My morning Nairobi output, delivered before their day started, was waiting for them every morning. The overlap window became genuinely productive because I was not already tired when I arrived at it. My messages got more precise because I had to write for someone who would read them hours later, not answer them immediately.
If you are in this situation right now, the clearest version of the lesson is this: your timezone is not a disadvantage you have to compensate for by being available all the time. It is a constraint to design around, and most of the design is just good communication habits anyway. Those habits will serve you whether you are eight time zones from your team or two floors up from them.
If you want to compare notes on how you have approached this, or are building your case for your first international remote role, drop me a line. I am happy to think through the specifics with you.
Comments