Why the Best Distributed Teams Aren't Actually Distributed

The best distributed teams aren't actually distributed.

That sounds like a contradiction, and it's the single most useful thing I can tell a founder who is about to hire in another country. The companies that make global engineering work are not the ones with people scattered everywhere. They're the ones who understood the difference between a global organisation and a stretched team.

What going distributed actually costs

Founders spread one team across five timezones and call it distributed. Then they wonder why it's slow.

The costs are real and they compound quietly.

Overlap hours shrink. When the working days barely touch, the window in which two people can talk shrinks to an hour, sometimes less. Everything that would have taken a two-minute conversation becomes a message, a wait, a reply, another wait. A question that would have been answered before lunch now takes two days.

People lean on workarounds to stay in sync. Written handovers, recorded standups, elaborate documentation of decisions that used to happen in a corridor. None of this is bad practice, and some of it makes teams better. But it's overhead someone is paying for, and it's paid every day.

The sense of a shared working day never forms. This is the one founders underestimate most, because it doesn't show up in any metric. Teams that share a working day develop a rhythm. They know who's around, they overhear things, they build the informal trust that makes people ask the awkward question rather than quietly guessing. Strip that out and you can still get work done, but you have to manufacture deliberately what used to happen for free.

You get the reach, and you pay for it in friction.

The distinction that fixes it

None of this means hiring globally is a mistake. There are good reasons to have people in other regions: cost, being closer to customers in a specific market, or genuine round-the-clock cover for incidents.

The mistake is in the shape, not the intent.

There's a better structure, and it's the one strong global companies actually use. Don't spread one team across the map. Build small teams, each concentrated in one place, each independent enough to own its work end to end.

Each team lives inside a shared working day. Each one has the people it needs to make its own decisions and deliver its own piece of the product without waiting on someone who's asleep.

The organisation is global. The team isn't.

Why this works

The reason this shape beats the stretched-team version comes down to where the coordination happens.

In a stretched team, coordination is constant and it crosses timezones. Every design discussion, every code review, every "should we do it this way" is a cross-timezone event. The friction is embedded in the daily work.

In a set of small co-located teams, most coordination happens inside a single working day. Cross-timezone communication still exists, but it moves up a level. It's team to team rather than person to person, it happens at defined points rather than constantly, and it concerns interfaces rather than implementation details. That's a far smaller surface area, and it's the kind of communication that survives being asynchronous.

The practical test is simple. Can this team make a decision and ship it without waiting for someone in another timezone? If yes, you've built a unit. If no, you've built a dependency, and you'll feel it every week.

The cost trap

The most common reason founders stretch a team is cost, and it's worth addressing directly because there's a better answer.

If your goal is saving money, you don't need to scatter a single team across continents. Every region has its own lower-cost geographies. Within a few hours of most major markets, there are places where engineering talent costs meaningfully less than in the capital. You can get most of the savings and still keep a team inside overlapping hours.

The mistake is treating the cost decision and the timezone decision as the same decision. They aren't. Cheaper does not have to mean further away, and the difference in how the team functions is substantial.

What this means practically

If you need people in another region, don't stretch an existing team to reach them. Set up a small team there that owns its own piece of the product.

That team needs enough people to be self-sufficient, clear ownership of something specific, and the authority to make decisions inside its own area. A team of three who own a defined slice will outperform six people spread across three timezones working on a shared backlog, and it isn't close.

It also means being honest about when you're not ready. If you can't yet describe a piece of work that a small remote team could own end to end, you're not ready to hire there. Hiring first and figuring out ownership later is how you end up with a stretched team by accident.

The point

Distributed working isn't the problem. Stretching a single team until it stops functioning as a team is the problem, and the two get confused constantly.

Keep the people together. Let the org be the thing that's global.