PipelineRoad has team members in Austin, Sao Paulo, Jakarta, and Melbourne. That’s UTC-6, UTC-3, UTC+7, and UTC+11. The maximum spread is seventeen hours. When it’s 9 AM for me in Texas, it’s midnight for our designer in Melbourne.
This is, by any reasonable standard, a terrible setup. Every article about remote work will tell you to hire within overlapping time zones. Keep the spread to four or five hours. Make it easy to schedule meetings.
We ignored all of that, not out of principle but because the people we wanted to work with happened to live where they live. And after two years of making it work, I’ve learned that the conventional wisdom about time zones is mostly wrong. The hard parts of distributed teams have almost nothing to do with clocks.
The Overlap Myth
The first thing everyone obsesses about is overlapping hours. How many hours per day can the whole team be online simultaneously? For us, the honest answer is about two. Maybe three if someone’s willing to take a late call.
Two hours of overlap sounds catastrophic. It’s not.
Here’s what I’ve learned: if you need the whole team online at the same time for more than two hours a day, you have a process problem, not a time zone problem. The need for synchronous communication is almost always a symptom of unclear ownership, missing documentation, or poorly defined projects.
When we first went distributed, I tried to force overlap. I’d schedule all-hands meetings at times that were merely inconvenient for everyone rather than impossible for anyone. The result was a team that was perpetually jet-lagged in spirit. People were waking up at 5 AM or staying up until midnight, and the meetings themselves were sluggish because half the team was operating at low capacity.
So we stopped. We reduced synchronous meetings to two per week — a Monday kickoff and a Thursday check-in — and made everything else async. The team got better almost immediately.
Async as a Default, Not a Compromise
Most companies treat asynchronous communication as a downgrade from real-time interaction. It’s what you do when you can’t get everyone in a room. This framing is backwards.
Async communication, done well, is superior to synchronous communication for almost everything except relationship building and complex problem-solving. And I mean genuinely superior — not “adequate” or “acceptable.”
Here’s why. When someone writes a Loom video explaining a project update, they’re forced to organize their thoughts. They edit. They structure. The information is clear and complete. Compare that to a meeting where the same person would ramble for twelve minutes, go on three tangents, and leave everyone with a different understanding of what was said.
Written communication in Slack follows the same logic. A well-written message — with context, specifics, and a clear ask — transfers information more efficiently than a twenty-minute call. And it creates a record. You can search it. You can reference it. You can read it at 2 PM in your time zone instead of attending a meeting at 6 AM.
The key word is “well-written.” Most async communication fails because people treat it like texting — fragmented, context-free, ambiguous. We invested heavily in teaching the team how to write good async updates. Complete thoughts. Enough context that someone reading the message in eight hours can act on it without follow-up questions. Clear distinction between FYI, feedback request, and action required.
This took about three months to become natural. Now it’s our greatest operational advantage.
Meeting Hygiene
We still have meetings. But we’re ruthless about them.
Every meeting has a written agenda shared at least twelve hours in advance. If there’s no agenda, the meeting is cancelled. This isn’t a suggestion — it’s policy. I’ve cancelled my own meetings for violating this rule.
Every meeting has a designated note-taker who posts a summary within one hour. The summary includes decisions made, action items with owners and deadlines, and any open questions that need async follow-up. If you didn’t attend the meeting, the summary should give you ninety percent of what you need.
We never have status update meetings. If you want to know what someone is working on, check the project board or read their async update. Meetings are reserved for two things: making decisions that require real-time discussion, and building relationships.
That second category is important. I’ll come back to it.
What I Got Wrong
I want to be transparent about the mistakes, because I made a lot of them.
In the first year, I dramatically underestimated how much context remote team members lose compared to in-office teams. In a physical office, information flows through osmosis. You overhear a conversation. You catch someone at the coffee machine. You absorb context passively just by being in the space.
Remote teams get none of that. Every piece of context has to be deliberately shared. This means you have to over-communicate by at least 2x compared to what feels natural. When I thought I was communicating enough, I was communicating about half of what the team needed.
The symptom was subtle. People weren’t confused or blocked — they just made slightly different decisions than I would have, because they were missing background information I’d assumed they had. It wasn’t a crisis. It was a slow drift. And slow drift is dangerous because you don’t notice it until you’re way off course.
The fix was what I now call “context dumps.” Every Monday, I record a fifteen-minute Loom that covers: what’s happening at the company level, what I’m thinking about strategically, any client updates that affect multiple people, and anything I learned that week that might be useful. It’s informal. It’s messy. But it closes the context gap dramatically.
My second big mistake was treating all communication channels the same. We had Slack for everything — quick questions, deep discussions, project updates, social chat, file sharing. It was chaos. Important messages got buried under memes and lunch polls.
We now have a clear channel architecture. Project-specific channels for project work. A channel for async standups. A channel for decisions that need to be searchable. And a channel for everything social and non-work. The separation seems obvious, but it took us eight months to figure out.
Trust Is the Infrastructure
The thing that actually makes distributed teams work — the thing that matters more than tools or processes or time zone overlap — is trust.
Not trust in the abstract, feel-good sense. Trust as infrastructure. The operational foundation that allows everything else to function.
When I trust that Alfredo in Sao Paulo is handling the client deliverables, I don’t need to check in. When he trusts that I’ve given him enough context, he doesn’t need to wait for approval. The system runs smoothly because each node trusts the others.
Building that trust remotely is harder than building it in person. You can’t rely on the passive trust-building that happens when you share a physical space — the body language, the casual interactions, the shared lunches.
You have to be intentional about it.
For us, that means a few things. First, we do one-on-ones that are explicitly not about work. I talk to each team member for thirty minutes every other week about whatever they want to talk about. Their weekend. A movie they saw. Something they’re stressed about. These calls feel unproductive. They are the most important calls on my calendar.
Second, we meet in person twice a year. The whole team, in one place, for a week. We work, but we also eat together, explore together, argue about restaurants together. The in-person time creates a relational reservoir that sustains us through months of pixels and timestamps.
Third — and this is the one most managers resist — we default to trust rather than verification. I don’t track hours. I don’t monitor screens. I don’t care when people work, only that the work gets done. This feels risky. It’s actually risk-reducing, because people who feel trusted perform better than people who feel surveilled.
Cultural Differences Are Real
I want to address something that remote work discourse often glosses over: cultural differences are real, they matter, and pretending they don’t exist is a form of negligence.
On our team, direct feedback is interpreted differently depending on who’s receiving it. What feels like helpful candor to me — an American-Singaporean who grew up in a direct communication culture — can feel like public criticism to someone from a culture that values face-saving and indirect communication.
I learned this the hard way when I gave blunt feedback in a group Slack channel and didn’t realize I’d embarrassed a team member. He didn’t say anything about it directly. His work got quieter. More cautious. It took me two weeks to understand what had happened, and when I finally asked, the conversation was uncomfortable and necessary.
Now, critical feedback is always private, always framed with explicit care, and always followed by a question: “How did that land for you?” It’s a small adjustment. It changed our team culture entirely.
We also navigate different relationships to deadlines, different comfort levels with ambiguity, and different definitions of “done.” None of these are right or wrong — they’re just different. The manager’s job is to build a shared operating system that accommodates those differences without flattening them.
The Tools That Actually Matter
People always ask about our tech stack. What project management tool? What communication platform? What video software?
The honest answer is that the specific tools barely matter. We use Slack, Notion, Linear, Loom, and Google Meet. We could swap any of these out and be fine within a week. The tools are interchangeable.
What’s not interchangeable are the rituals.
Monday kickoff. Thursday check-in. Async standups every morning. Context dumps every Monday. One-on-ones every other week. Project post-mortems after every major delivery. These rituals create rhythm, and rhythm creates predictability, and predictability creates trust.
The worst remote teams I’ve seen have great tools and no rituals. The best ones have mediocre tools and ironclad habits.
Is It Worth It?
Running a team across four time zones is not easy. I won’t pretend otherwise. There are moments — usually at 6 AM on a Tuesday when I’m on a call that could have been an async message — when I fantasize about everyone being in the same office.
But the tradeoffs are worth it. We have access to talent we’d never find in one city. Our team members have autonomy over their schedules and their lives. The quality of our written communication is exceptional because it has to be. And the diversity of perspectives — cultural, geographic, experiential — makes our work better in ways that are hard to quantify but impossible to miss.
The future of work isn’t remote or in-office. It’s intentional. Whatever setup you choose, the question is whether you’ve been deliberate about how people communicate, build trust, and do their best work.
For us, four time zones turned out to be less of a constraint and more of a design parameter. Once we stopped fighting it and started building around it, everything got better.
Seventeen hours of spread. Two hours of overlap. And a team that works.