Where to Hire for a Distributed Team

A founder I know hired on talent alone for the first two years. Best candidate won, every time, location be damned. It was a point of pride, and honestly a good instinct. He ended up with a designer in São Paulo, two engineers in Berlin, a PM in Bangalore, and himself in San Francisco.

Then he tried to schedule a product review.

There was no hour that worked. Bangalore and San Francisco share almost nothing in a normal day. The Berlin engineers could catch one end or the other, never both. He'd built an eleven-hour spread without ever deciding to, one excellent hire at a time, and now the company had a shape nobody had chosen and nobody could change without firing people he liked.

That's the part teams miss. Where you hire is an architecture decision, and you usually make it before you understand it's a decision at all. Every offer letter nudges your overlap window one way or the other. Send enough of them without thinking about it and you wake up running a company whose operating model was set by accident.

The number that actually matters is overlap

Forget the map for a second. The thing that governs how your team works isn't how many countries you're in. It's how many hours a day enough of you are awake at the same time.

Call it the overlap window. A team clustered in New York and São Paulo has six or seven hours of it, plenty of room to keep most work synchronous if they want to. A team split between San Francisco and Berlin has maybe two. A team that includes both California and India has almost none, a sliver in someone's early morning and someone else's late night.

Those are different companies, even if they all describe themselves as "remote." The first can lean on live conversation and get away with loose habits. The third cannot. It has to write things down, settle decisions in threads, and let people work on their own clock, because there is no other option. Most teams discover this constraint after they've hired into it, then spend a year retrofitting async-first communication onto a group that assumed it would always be able to hop on a call. The async habits are good either way. The painful part is being forced into them by a map you drew without looking.

Three footprints, and what each one costs

There are roughly three shapes a distributed team can take, and they're not equally easy to run.

The tight cluster keeps everyone inside two or three adjacent zones. Think a team spread across the US and Latin America, or one that runs from London to Nairobi. You give up the truly global talent pool, but you keep a real overlap window, and synchronous work stays cheap when you want it. For most early teams, this is the right default and nobody tells you so.

The two-hub setup anchors people in two clusters with partial overlap, say the US East Coast and Western Europe. You get a wider hiring reach and a few hours of daily overlap to hand work between hubs. It's the footprint that makes following the sun actually plausible, because there's a window where the baton can change hands cleanly instead of getting dropped on the floor while one side sleeps.

The full smear puts people everywhere, with no hour the whole team shares. This is the dream people picture when they say "we hire anywhere," and it's the hardest one to run well. It can work. Some genuinely global companies are excellent at it. But running it well is a capability you build deliberately over years, not a starting condition you stumble into because three great candidates happened to live far apart. If you're going to be fully smeared, decide it on purpose and staff up the writing culture to support it, the way the best remote-first teams build those muscles from day one. Don't back into it.

Match the spread to the work, not the other way around

Some work needs people awake together. Early product and design, where you're still figuring out what you're even building, goes faster with two people riffing in real time than with a forty-comment thread. A founding engineer and a founding designer eleven hours apart will feel it every single day. Pair those roles inside a decent overlap window or you'll watch a two-day decision stretch into a two-week one.

Other work is genuinely self-contained, and for that, distance is close to free. A support queue where tickets are independent. A long-running migration. An infra engineer who mostly needs uninterrupted hours and a clear spec. These are the roles where hiring someone twelve zones away is a feature, because that person gets the long quiet stretch for deep work that your clustered team has to fight for, and the company gets coverage while everyone else sleeps.

So before you post the role, ask which kind of work it is. Tightly coupled, judgment-heavy collaboration wants overlap. Independent, well-defined output can live anywhere. Putting a tightly coupled pair on opposite sides of the planet is the most common self-inflicted wound I see, and it's entirely avoidable at the hiring stage.

The best candidate versus the best-placed one

None of this means you should pass on a brilliant person because they're three hours off. That would be its own kind of foolish. The rule is a default, not a wall, and the whole point of a default is that you override it on purpose when the case is strong enough.

A genuinely exceptional hire is worth bending your footprint for. What you want to avoid is bending it by reflex, hire after hire, until the bends are the shape. The question to sit with isn't "is this person good," it's "is this person so good that they're worth the operating cost of where they sit, and am I willing to pay that cost on the next three hires too." Usually the answer for a standout is yes. Usually the answer for an ordinary-but-fine candidate in an awkward zone is no, and you'd find someone just as good closer in.

The trap is treating each hire as a one-off when the effect is cumulative. One person three hours out is nothing. Five of them, each three hours out in a different direction, is an eleven-hour spread, and you decided it five times while thinking you never decided it once.

Don't strand a single outlier

The worst version of this is the lone person nine hours from everyone else.

They join every meeting at a brutal hour, or skip it and read the notes. Questions they post into a sleeping channel sit half a day before anyone answers. And they're last to hear about anything decided live, which still happens more than it should on a team that hasn't fully committed to writing things down. It's isolating and a quiet path to burnout, and it has little to do with how good the person is at the job. The math just doesn't love them.

If you're going to hire into a far-off zone, hire at least two people there, or pick a zone with real overlap with an existing hub. A pair keeps each other company and covers each other's hours. A solo outlier slowly drifts to the edge of the team no matter how much everyone likes them, and the drift is structural, not personal. You can't fix with kindness what the schedule keeps breaking.

Write the rule down before you need it

The fix is almost embarrassingly simple: decide your footprint before the candidates show up, while you can still think clearly about it instead of rationalizing around a person you've already fallen for.

Put it in the handbook next to everything else. The hours of overlap you require for collaborative roles. The zones you're anchoring hubs in. The bar a candidate has to clear to justify an exception, and who signs off on it. It doesn't need to be elaborate. It needs to exist before the moment you're tempted to ignore it, because in that moment, with a great candidate in front of you, you will lose the argument with yourself every time unless you had it in advance.

Your hiring map is going to decide how your company communicates whether or not you pay attention to it. The only real choice is whether you draw it on purpose or read it off the org chart two years too late, the way my founder friend did, staring at a calendar with no good meeting time and a team he couldn't rearrange.

Make Every Hire's Time Zone Unambiguous

However your map ends up looking, the daily friction is the same: someone posts "let's sync at 3pm" and half the team does the math wrong. Timely converts every time mention in Slack to each reader's own timezone automatically, so a team spread across six zones reads one clear local time instead of guessing.

Add Timely to Slack — Free · See how it works