How to Make Distributed Work Actually Distributed

Most teams that call themselves distributed are actually remote teams clustered in one timezone, with a few outliers. The outliers carry a disproportionate burden: late meetings, after-hours decisions, the feeling of being a permanent guest. Making distributed actually distributed requires structural choices that most teams skip because they're inconvenient for the majority timezone.

The tell: where decisions happen

The fastest diagnostic: where does the team make decisions? If most decisions happen in a 2-4 hour window that aligns with one timezone, the team is centralized, not distributed.

Genuinely distributed teams decide async across full days. The decision-making rhythm is the load-bearing test.

Audit your meeting times

Map your recurring meetings against each engineer's timezone. Count: how many meetings does each engineer attend outside 9am-5pm their time? If the answer is more than 1-2 per week for any engineer, your meeting culture privileges a specific timezone.

Distribute the inconvenience. Move meetings to rotate through timezones. Some weeks the West Coast joins early; some weeks Asia joins late.

Move decisions out of meetings entirely

The cleaner solution: decisions don't happen in meetings. Meetings are for discussion; decisions are made async after, by the named authority, within 48 hours. This decouples decision-making from any specific timezone.

Most teams resist this because it feels slower. It is slower per decision and faster per team — more decisions get made because no decision waits for a meeting.

Distribute authority across timezones

For each category of decision, name a primary and deputies in each major timezone. The deputies can decide if the primary is unavailable. Without this, every important decision routes through one zone.

This is the single structural change that distinguishes truly distributed teams from majority-timezone-with-outliers teams.

Build the artifact infrastructure

Distributed work depends on durable, queryable records: decision archive, surface ownership map, end-of-shift handoffs. Without them, distributed teams revert to in-timezone coordination because that's the only thing that works.

With them, an engineer in Singapore can answer their own questions at 9am local without messaging anyone — the records carry the context.

Defend deep work in every zone

If meetings cluster in one zone, engineers in that zone have shorter focus blocks. If they cluster in another, the inverse. Either way is bad. Rotate meeting times or move work async so no zone bears all the disruption.

Hire across zones, not into them

Hiring patterns reveal the team's actual disposition. If 80% of hires land in one timezone, the team is centralizing regardless of stated values. Set hiring targets that distribute headcount.

This sometimes requires sourcing pipelines outside your core zone — investment that takes a quarter to build. Worth doing.

Measure distributed-ness explicitly

Two metrics worth tracking:

• Decision distribution — what percent of decisions are made by engineers outside the dominant timezone?
• Meeting load distribution — what's the variance in out-of-hours meetings across the team?

Both should trend toward parity. If they don't, the team is centralizing.

Common failure modes

Failure: calling the team distributed while running it from one zone. The outlier engineers eventually leave; the team becomes single-zone and pretends to be distributed.

Failure: forcing all engineers onto the majority zone's schedule. Burns out the outliers; produces silent attrition.

Failure: distributing only in marketing. If the public narrative says "distributed" but the practice says "clustered," engineers see the gap and lose trust.

What to do tomorrow

Look at your last 10 decisions. Where were the deciders? Where were the meetings held? Where do hires concentrate? If three of those answers cluster in one timezone, your team is functionally centralized. The fix is structural, not vibes — start with one specific change this quarter.

Frequently asked questions

Is fully distributed always better?

Not always. Small teams can work fine clustered, with deliberate trade-offs. The cost rises with size — past 20 engineers, the centralization tax becomes substantial.

What about teams with one or two outlier engineers?

The outliers carry a disproportionate cost. Either bring them into a deliberately distributed mode or be honest that the team is centralized and hiring outliers is a hardship choice for them.

How do we handle critical decisions that need fast turnaround?

Named authority with explicit deputies. Critical decisions can happen in any zone if the deputies are real. They're rarely real when authority hasn't been distributed in advance.