Learn how remote-first startups build effective distributed teams with async communication, the right tools, and intentional culture practices.
So I was looking at yet another “how to build a remote team” article the other day and I just… I couldn’t finish it. The advice was all surface-level fluff. “Use Slack! Do virtual happy hours! Trust your employees!” As if that’s the hard part. As if the actual grind of keeping eleven people across seven time zones pulling in the same direction comes down to picking the right chat app and believing in people. It doesn’t. Not by a long shot.
I’ve been running distributed teams since 2019 — before the pandemic turned remote work into everybody’s favorite topic — and I’m still figuring it out. We’ve got people from UTC-5 to UTC+9 right now. Some days we’re shipping code around the clock and it feels like magic. Other days, a production bug goes live at 3am Tokyo time, the designer in Berlin won’t be online for four hours, and my co-founder in Austin is buried in customer calls until 4pm her time. Nobody’s around to fix it. I’m sitting there refreshing error logs and wondering why I didn’t just rent an office in one city like a normal person.
That frustration is what actually taught me the most. So instead of writing another cheerful guide about remote work, I want to walk through the problems we hit, the stuff we tried that failed, and what eventually worked. Maybe some of it helps you. Maybe you’ll avoid repeating our mistakes. Or maybe you’ll just feel better knowing someone else is also annoyed by this.
Remote-First Isn’t Remote-Friendly
Before anything else, this distinction drives me up the wall because people keep mixing them up. A remote-friendly company has an office. It lets some folks work from home sometimes. Good for them. A remote-first company is a completely different animal — every single process, every communication channel, every decision gets designed around the assumption that nobody shares a room. Ever.
GitLab is probably the best example out there. Over 2,000 employees in 65+ countries, and their entire company handbook is public. Thousands of pages long. Obsessive in detail. And that’s exactly what remote-first demands — you can’t leave things implied or assumed because there’s no hallway to catch someone in.
What irritates me is companies that slap “remote-first” on their job listings and then do none of the work. Decisions still happen in hallway chats at HQ. All-hands meetings get scheduled for San Francisco afternoons, which means everyone east of Berlin is either waking up at midnight or watching a recording three days later (and let’s be real, nobody watches the recording). That’s not remote-first. That’s a regular office that occasionally lets people dial in. Huge difference.
We fell into this trap early on. I thought buying the right tools and saying “work from wherever” was enough. It wasn’t even close to enough.
The Time Zone Overlap Problem
Right. So here’s where it starts getting genuinely hard.
You need some overlap between people who work together regularly. Not for standups — those can go async pretty easily. You need it for the messy stuff. Pair programming. Design reviews. Those unstructured back-and-forth conversations where two people stare at a problem together and hack their way through it in real time. I’ve tried making all of that async and it just… doesn’t work the same. Something gets lost.
My rule of thumb (and I could be wrong about the exact number, but it’s served us well) is a minimum of three hours of daily overlap between any two people who collaborate closely. Take a frontend developer in Warsaw at UTC+1 and a backend engineer in Portland at UTC-8. Nine-hour gap. Your overlap window is roughly 6-9am Portland time, 3-6pm Warsaw time. Tight. Workable. Now try adding someone in Sydney at UTC+11. Good luck finding a single hour that works for all three of them — there’s basically zero natural overlap between Sydney and Portland.
We tried to power through this for months. Just brute-forced it. People shifted their schedules around, took calls at weird hours, got cranky. It was a mess.
What actually solved it — or at least made it manageable — was clustering hires into time zone bands. We ended up with an Americas group (UTC-8 to UTC-3) and an EMEA/Asia group (UTC+0 to UTC+9). Each band has plenty of internal overlap. The bands connect through shared documents, recorded Loom videos, and a structured handoff process where you leave a clear written summary of where things stand at the end of your workday. It’s more deliberate than just everyone being in one room, but once you get the rhythm down, it flows.
Async Communication Is a Skill, Not a Tool
This one. This one right here. I wasted so much time and money learning this lesson.
We bought everything. Slack. Notion. Linear. Loom. Miro. Every shiny collaboration tool on the market. And people still scheduled thirty-minute Zoom calls to discuss things that could’ve been a three-paragraph write-up. I remember sitting in my fourth unnecessary meeting of the day thinking, “We have all the tools. Why is this still happening?”
Because tools don’t teach people how to write a clear async message. That’s a skill. And most people have never been trained on it.
Bad async message: “Hey, can we chat about the pricing page?” Good async message: “I’m proposing we change the pricing page from three columns to two. Here’s a mockup. Reasons: analytics show 80% of signups pick the middle tier so the third column is wasted space, and an A/B test last month showed 12% higher conversion with the simplified layout. Unless someone objects by Thursday, I’ll go ahead and implement this.” See the difference? The second one doesn’t need a follow-up. It doesn’t need a meeting. It stands on its own.
After a while, we started running what I can only describe as async communication bootcamp for new hires. One full week of practicing — writing proposals, giving feedback inside documents, making decisions without hopping on a call. Felt ridiculous at first. Like, we’re training adults how to write messages? But the quality of our team’s written communication improved so much that I’d never skip it now. Loom videos became a big part of this too. A two-minute screen recording with narration can replace a thirty-minute meeting, and the person on the other end watches it whenever they’re actually online. No scheduling gymnastics required.
The Async Decision-Making Framework
OK so your team can write decent async messages now. Great. The next problem is harder: how do you actually make decisions without everyone jumping on a call the second something gets slightly ambiguous?
Most teams default to “let’s schedule a quick sync.” I find that so frustrating because “quick sync” is never quick, and the habit kills momentum for people in far-off time zones who now have to wait twelve hours for a meeting they’ll attend at some ungodly hour. You’ve got to actively break that reflex.
We landed on a lightweight RFC process — Request for Comments. Might seem like overkill for eleven people, and honestly, it probably is a little. But it’s saved us from so many bad decisions that I don’t care if it’s technically more process than a team our size needs.
Here’s how it works. Anyone writes an RFC as a Notion doc using a standard template: problem statement, proposed solution, alternatives considered, risks, and — this part matters a lot — a decision deadline. Without a deadline, RFCs just float around forever and nothing gets decided. People comment when they feel like it, which means they don’t.
Once an RFC goes up, relevant people get 48 hours to comment. Real comments. Not emoji reactions. Not “looks good.” Write your actual thoughts. And here’s the rule that makes the whole thing work: if you don’t comment within the window, you’ve implicitly agreed. Seems harsh, right? It is. But it kills the problem where someone pops up three weeks later saying “wait, I never signed off on that.” You had 48 hours. You didn’t use them. We moved on.
Disagreement is the tricky part. In a meeting, you can read body language — you can tell when someone’s uncomfortable even if they’re not talking. Async doesn’t give you that. Silence might mean agreement, confusion, or quiet resentment. So we added what I call a “silent disagreement protocol.” After the comment window closes, the RFC author posts a poll with three options: (a) fully on board, (b) disagree but will commit, or (c) can’t live with this. Option B is healthy. Most disagreement should land there. Option C triggers an actual synchronous call — that’s the one situation where a meeting is justified, in my opinion. It probably happens once a month. Maybe less.
For smaller decisions — stuff that doesn’t need a formal RFC — we use “propose and proceed.” Post your plan in the relevant Slack channel, tag whoever it affects, say “I’m doing this tomorrow unless someone flags a problem.” Nine times out of ten, nobody objects and things just keep moving. Fast. Possibly too fast sometimes — we’ve had a couple of cases where someone missed the message and got blindsided. But I’ll take occasional surprise over death-by-meeting any day of the week.
The Tools That Actually Stuck
After cycling through seemingly every collaboration app that exists, here’s what survived. Slack for quick throwaway conversations — we treat it like a hallway, not a filing cabinet. Notion for specs, decisions, and anything that needs to last longer than a day. Linear for task tracking because it’s snappy and doesn’t make you fight the UI. Loom for async video. GitHub for code. And Tuple for pair programming, because screen sharing over Zoom is painfully laggy and the audio quality makes you want to throw your laptop out a window.
The tool that surprised me most was embarrassingly simple: a shared Google Calendar showing everyone’s working hours. That’s it. When you can glance at the calendar and see your designer goes offline in three hours, you prioritize differently. We color-code by time zone — green for overlap hours, yellow for edge hours, red for “don’t even think about scheduling something here.” It’s primitive. It works better than every fancy scheduling product we tried. Sometimes the dumb solution is the right one.
Hiring for Remote: What’s Actually Different
Not everyone does well working remotely. That’s fine — it’s a preference, not a personality flaw. But if you’re running a remote-first startup, you need to screen for it, and the traits that matter aren’t the ones most people think about.
Technical skill? Assess it normally. Whatever your usual process is, keep doing it. What you need to add is testing for written communication (have them write a mock project proposal during the interview process), self-direction (ask about side projects and how they organize their own days), and comfort with ambiguity. Remote work means figuring things out without tapping someone on the shoulder, and some people really struggle with that.
From what I’ve seen, previous remote experience is the single best predictor of success. Someone who’s worked remotely for two years at another company ramps up roughly three times faster than someone making the jump from an office for the first time. The adjustment period is real, and it goes wrong more often than you’d expect — some people discover they genuinely hate working from home after two months, and when they’re in a different country, that’s an expensive mistake for everyone involved.
Our interview process has changed a lot over the past couple of years. First round is entirely written. We send candidates a short product scenario and ask them to write up their approach. No video call. No live coding. Just a document. I think this tells us more about how someone will actually perform day-to-day than any whiteboard interview ever could. Candidates who turn in sloppy or vague responses at this stage don’t magically get better once you hire them. How someone structures a written argument is a pretty solid signal of how they’ll communicate on the job.
Second round is a standard live technical interview over Tuple or Zoom, depending on the role. Nothing unusual there. Third round is where it gets interesting — a paid trial week. The candidate works on a real but self-contained project with the team for five days. We pay a fair day rate. They get to feel what async remote work is actually like, and we get to see how they handle it.
Expensive? Yes. Slow? Definitely. Worth it? Absolutely. We’ve had candidates who aced every interview round and then completely fell apart during the trial week because they couldn’t handle the ambiguity of async. One person — and I’m not exaggerating — Slacked me every thirty minutes asking if they were “doing it right.” That’s not someone who’ll thrive without a manager hovering over their shoulder, and we never would’ve caught that from interviews alone.
Red flags I’ve learned to spot: candidates who can’t give a concrete answer to “tell me about a time you resolved a work conflict over text.” People who say they want remote work mainly for the “flexibility” but never mention deep work or autonomy. Anyone who asks zero questions about how we communicate — it probably means they haven’t thought about what makes remote different from office life. And the biggest red flag, maybe: candidates who’ve only worked in offices and describe their ideal workday as “lots of collaboration and brainstorming sessions.” They’re not wrong for wanting that. They’re just wrong for us.
Then there’s compensation, which is its own can of worms. Do you pay San Francisco rates to someone in Bucharest? GitLab and Basecamp both pay by role, not location. Other companies adjust for cost of living. We landed somewhere in the middle: we pay above-market rates for each person’s local area. Our engineer in Poland makes less in absolute dollars than our engineer in New York, but both are well above what they’d earn locally. It’s not perfectly fair. I know that. But it’s practical, and so far nobody’s quit over it.
Building Culture When There’s No Office
Skeptics always bring this one up. And they’ve got a point — culture in a remote company takes deliberate effort you can skip when everyone shares a building. You can’t just rely on people bumping into each other at the coffee machine.
A few things that have actually worked for us. Weekly “coffee chats” — the system randomly pairs two people who don’t normally work together for a fifteen-minute video call. Just talk. About anything. Work, hobbies, whatever. We’ve got a Slack channel called #watercooler where people post about weekends, pets, cooking disasters, that kind of thing. And then the big one: annual in-person retreats. We budget $3,000 per person for a week somewhere interesting, and the entire point is bonding. Not work. Not planning sessions. Just humans spending time together.
The retreat is, I think, the single most effective thing we do for culture. Spending a week together in person turns text-based relationships into real ones. After our retreat in Lisbon last year, cross-team collaboration got noticeably better. People are way more generous in their Slack messages when they’ve shared meals and had drinks with the person on the other end. We protect that budget like it’s sacred — it’s the best money we spend all year, and I’d cut almost anything else before touching it.
The Loneliness Problem
I’d be lying if I skipped over this. Remote work can be isolating. Several of our team members have struggled with it — not everyone, but enough that we had to take it seriously.
We now offer a coworking space stipend of $300 a month for anyone who wants it, and we actively encourage people to use it. Working from a coworking space three days a week gives you human contact without the commute or the office politics. A couple of team members have told me this benefit matters more to them than a raise would. That surprised me at first, but it makes sense when you think about it. Humans need other humans around. A Slack channel doesn’t replace that, no matter how many GIFs you post in it.
When Remote-First Breaks Down
And here’s the part where I refuse to sugarcoat things, because the internet has enough people pretending distributed teams can do anything an in-person team can. They can’t. There are specific situations where remote-first falls apart, and ignoring that doesn’t help anybody.
Crunch periods. That’s the big one. When you’re two weeks out from a major launch and stuff is breaking faster than you can patch it, async becomes a bottleneck. You need rapid back-and-forth. You need someone to respond in seconds, not hours. Waiting four hours for your teammate in another time zone to wake up and see your question is agonizing when production is on fire.
We handle this by declaring “sync sprints” — short bursts, usually three to five days, where the whole team shifts their working hours toward maximum overlap. Nobody loves it. It’s disruptive. People lose sleep. But it works for genuine emergencies, and the key word there is genuine. If you’re running sync sprints every month, your planning is the problem, not your team’s geography.
Conflict resolution is another weak spot. When two people on your team have a real disagreement — not a technical debate, a personal tension — text makes it worse almost every time. Tone gets misread. People type things they’d never say face-to-face. Small resentments fester for weeks because there’s no casual lunch where you’d naturally clear the air.
We learned this lesson the hard way. Two of our engineers got into a disagreement that spiraled into a month-long cold war played out through increasingly passive-aggressive GitHub PR reviews. It was awful. Our rule now: any interpersonal conflict gets escalated to a video call within 24 hours. No Slack arguments. No snide comments buried in documents. Get on camera, talk like adults, move forward. Seems obvious in hindsight. Wasn’t obvious when we needed it.
And then there’s the hardest situation of all: letting someone go. Firing someone remotely is brutal. There’s no gentle version. You can’t hand them a box, shake their hand, walk them to the door. It’s a video call, their Slack goes dark, and the rest of the team just watches a name disappear from channels.
We’ve had to do it twice. Both times, I flew to their city and had the conversation in person. Cost a couple thousand dollars in flights and hotels each time. Worth every penny. I think you owe a person that basic respect. If you truly can’t fly out, at the very least do it on a video call — never over email, never over Slack. I’ve heard stories of founders who fired people via chat message and it makes my blood boil. That’s not a management style. That’s cowardice.
What I’d Do Differently Starting Over
Looking back, three things jump out.
First, I’d cluster time zones from day one. Our first five hires landed in five different zones because we chased talent without thinking about collaboration patterns. Brilliant individuals, terrible overlap. It took months to untangle the scheduling nightmare that created.
Second, I’d invest in async communication training immediately. We wasted our first six months drowning in meetings because nobody — including me — knew how to work any other way. That bootcamp I mentioned? Should’ve been week one, not month eight.
Third, I’d set expectations way more clearly during hiring. Remote-first means your written messages carry more weight than your face time. It means feedback on your work might arrive twelve hours after you submit it. It means you need the discipline to log off at a reasonable hour because nobody’s watching you leave a building. Some people love that. Some people need a physical workplace to feel grounded. Neither is wrong. But hiring someone who needs office structure into a remote-first company is a mistake I’ve made twice, and I’m not interested in making it a third time.
Back to That Article
Remember that blog post I was reading — the one that annoyed me enough to write all of this? I went back and finished it after I’d cooled down. Its advice wasn’t technically wrong. Use Slack. Do virtual happy hours. Trust your employees. Fine. All true on the surface.
But it was missing everything underneath. The months of failed experiments. The 3am production bugs with nobody awake to help. The engineer who Slacked me every thirty minutes. The cold war in the PR reviews. The flights to fire people in person because it was the right thing to do. That’s what building a distributed team actually looks like — not a clean checklist, but a long series of problems you solve one frustrating lesson at a time.
The future of work isn’t “remote good” or “office good.” It’s companies being honest about which model fits their situation and then doing the unglamorous work to make it function. Half-measures — slapping “hybrid” on a job posting without any real structure behind it — are worse than committing to either direction fully. Pick your lane. Build everything around it. And when someone writes a fluffy article telling you it’s easy, maybe close the tab and get back to actually doing the work. That’s what I should’ve done in the first place.
(0) Comments