Role
Remote engineer on East Africa Time, and why that overlap works
Timezone is usually the first thing a distributed team checks and the last thing a candidate explains properly. So here is the arithmetic, and what I actually do with the hours.
How I fit
I am in Nairobi on UTC plus three, permanently, with no seasonal clock change to track. That is a full overlap with European teams and a real morning overlap with the United States east coast. For a distributed team the practical question is not where somebody is, it is how many hours of genuine overlap there are and whether they are the hours that matter.
A challenge from this role
A distributed team has one person several hours out of step. Reviews wait a day. A question asked at four in the afternoon gets answered tomorrow. Nobody is doing anything wrong, and delivery is quietly running at half speed because every exchange costs a calendar day.
How I approach it
Structure the work so that a blocked person is a rare event rather than a daily one. That means writing enough context that a reviewer does not have to ask a clarifying question, taking the ambiguous decisions to a synchronous window deliberately rather than letting them surface in an asynchronous thread, and leaving each day in a state somebody else could pick up. The overlap hours get spent on the things that genuinely need two people at once, and everything else is designed to survive a night.
What proves it
A written plan while work is in flight and a handoff when it ships, both built so somebody could resume from cold.
Sole engineer on a platform used daily by 112 schools, across design, delivery and operations.
Thirty three published posts, plus every decision on this site argued to a conclusion in public.
On call for a production system with real customers, for years, alone.
A primary answer served in one request, because the audience is on the connections that struggle.
The arithmetic, since it is usually left implicit
Nairobi is UTC plus three, permanently. No daylight saving, so the offset never moves and nobody has to recalculate it twice a year.
Against London that is a near total overlap of a normal working day. Against continental Europe it is almost as complete. Against the east coast of the United States it is a genuine morning window, enough for a daily synchronous conversation without either side working unsocial hours.
That combination is unusually good for one hire, and it is the kind of thing worth checking rather than assuming.
Overlap is not the real variable
Teams that struggle with distributed work usually have a process problem rather than a geography problem.
If a task cannot proceed without a synchronous answer, then every question costs a calendar day, and it does not matter whether the gap is three hours or eight. If the work is structured so that context travels with it, the gap stops being the constraint.
That is why the habits matter more than the hours. A written plan, a handoff, and enough context in a pull request that the reviewer does not need to ask anything. Those are the same habits that make somebody safe to leave alone, which is the other thing a distributed team is buying.
What I use the overlap for
Deliberately, for the things that are genuinely better synchronous: ambiguous decisions, disagreement, anything where tone matters, and the start of something new where the shared understanding is being formed.
Everything else is designed to survive a night without anybody waiting.
Questions people actually ask
- What are the actual overlap hours?
- Nairobi is UTC plus three all year, with no daylight saving. A nine to five in London overlaps almost entirely. Central Europe overlaps nearly as much. New York gets a solid morning overlap, roughly from the start of their day into their early afternoon.
- Are you available outside those hours?
- For incidents, yes, and I have been on call for a production system for years. As a routine expectation, no, because an engineer who is always available is an engineer who will not be there in two years.
- Does distance affect delivery?
- It affects how work should be structured rather than how much gets done. The teams that struggle with distributed work are the ones that never adapted their process to it, not the ones with people in the wrong places.