Here's a hard truth most engineering leaders don't say out loud: your team's speed depends way too much on people being in the same room at the same time.
You don't notice this until someone joins who isn't. A senior engineer in Prague, six or nine hours ahead of your US team, will expose every place where your process was actually just "ask Dave, he remembers."
The instinct is to treat this as a problem to manage. Standups get awkward. Someone has to stay late or log in early. Slack threads pile up overnight. It feels like friction.
But watch what actually happens over the following few months.
Decisions get written down. When you can't grab someone in the hallway to settle a design question, you write it in a doc or a ticket instead. That doc doesn't disappear when the meeting ends. It becomes the record. Six months later, nobody has to reconstruct "why did we do it this way" from memory.
PR descriptions get better. A reviewer working nine hours later than the author can't ask a quick clarifying question and get an instant answer. So the author starts explaining context up front: what changed, why, what was considered and rejected. That habit doesn't stay confined to the async engineer's PRs. It spreads.
Meetings get smaller and sharper. You can't schedule five people across a 9-hour spread for a 30-minute sync without real cost. So teams start asking: does this need a meeting, or does it need a doc? Most of the time it's a doc.
Bottlenecks around specific people become visible. If your architecture decisions only happen when one particular engineer is awake and in a good mood, that's not resilience, that's a single point of failure with a keyboard. A distributed team forces you to notice this and fix it, because otherwise nothing ships on the days that person is asleep.
None of this is really about timezones. It's about whether your team's knowledge lives in people's heads or in artifacts other people can read. Timezone spread just makes the gap impossible to ignore, because the workaround (walk over and ask) isn't available anymore.
Companies that have scaled distributed engineering hard already know this. GitLab operates across more than 60 countries. That's not possible if institutional knowledge only exists in synchronous conversations. It's only possible if the default mode of working is written, asynchronous, and reviewable by someone who wasn't in the room.
The uncomfortable part for a lot of US teams is that this same discipline would make them faster even without a single overseas hire. Distributed timezones don't create the need for better documentation and clearer decision records. They just make it impossible to keep pretending you don't need them.
So if you're evaluating whether a senior engineer nine timezones away is worth the coordination cost, that's a fair question to ask. But the more useful question might be: what is your team's process currently relying on that only works because everyone happens to be awake at the same time? Because that dependency was always a risk. The timezone gap just makes you deal with it now instead of later, during an outage, when the one person who understands that system is on vacation.
The engineers who thrive in this setup aren't the ones who happen to tolerate odd hours. They're the ones who were already good at writing clearly, documenting decisions, and working without needing constant real-time confirmation. That skill set is valuable on any team, in any timezone. Distributed work just makes it non-optional.
Top comments (0)