Your Remote Team Isn't Broken. Your Operating System Is.

I got a DM last Tuesday from a founder I know. 25-person team, Series A, engineers in Lisbon and product in Chicago. His exact words: “We’re spending 40% of our week in meetings and nothing is getting shipped. What are we doing wrong?”

I told him the thing nobody wants to hear: “You’re not running a remote company. You’re running an office over Zoom.”

He’s not alone. I’ve had some version of this conversation maybe 30 times in the last year. And the pattern is always the same. Smart founders who went remote, kept every meeting on the calendar, bolted Slack onto the wreckage, and then wondered why everyone’s exhausted and velocity tanked.

The problem isn’t the people. It’s the operating system they’re running on.

The Office-Over-Zoom Trap

Here’s what it looks like in practice. You’ve got a daily standup at 9am ET. Your engineer in Singapore joins at 10pm. Your designer in Berlin is eating lunch during it. Nobody’s actually present. They’re performing presence. The standup takes 25 minutes, could’ve been a three-paragraph Slack post, and the only person who got anything from it is the PM who wanted a status update they could’ve read async.

I made this exact mistake when my team went distributed. We had about 40 people going remote for the first time, and the instinct was to recreate the office digitally. Same cadence, same rituals, just on screens. Six weeks in, I finally said what I think everyone was already thinking: these meetings are making the work harder, not easier.

So I killed three of them in one afternoon. Replaced the daily standup with a written update. Turned the Monday all-hands into a Loom. Cut the Friday “team sync” entirely because nobody could explain what it was actually for.

We didn’t need better meetings. We needed fewer meetings and a completely different default for how work gets done.

That was two years ago. I haven’t looked back.

Async-First Is a Default, Not a Policy

The word “async” gets thrown around a lot, usually by people who mean “flexible hours.” That’s not what I’m talking about.

Async-first means the default way work happens is written, documented, and asynchronous. You write it down, you share it, people engage with it on their own time. Synchronous meetings still happen, but they’re the exception. Reserved for things that genuinely need real-time interaction. Creative brainstorms. Hard conversations. Negotiations. Not status updates. Never status updates.

GitLab is the most visible example of this working at scale. Fifteen hundred people, fully distributed, and they log over 200 async decisions a week in their public handbook. Their VP of Engineering, Christopher Lefelhocz, has talked openly about how their async culture is one of the biggest reasons they can hire globally without timezone constraints.

The principles scale because they’re about how information moves, not headcount. Full disclosure: I think most “async transformation” advice overcomplicates this. You don’t need a consultant or a 40-page playbook. You need to stop having meetings that should be emails. That’s genuinely 80% of it.

What This Actually Looks Like Day-to-Day

“Go async” is useless advice without specifics. So let me make it concrete.

Your 9am standup becomes a 5-minute written update posted to a shared channel. What shipped yesterday, what’s in progress today, anything blocking. People in other timezones read it when they start their day.

Your weekly all-hands becomes a Loom video from the founder. 8 minutes, maybe 10. Company metrics, what’s changing, what you’re thinking about. Comments and questions go in a thread.

Your brainstorm meeting still happens. But only when you genuinely need real-time back-and-forth. Product strategy pivots, major technical decisions, anything where tone and nuance matter. Everything else is a shared doc with a comment thread and a 48-hour window for input.

Decision-making gets documented in decision logs. Every significant decision gets a short entry: what we decided, why, what alternatives we considered, what the trade-offs are. Linked from Slack, searchable in Notion or wherever you keep docs.

When I actually made these changes, the feedback caught me off guard. People said things like “this is the first time I’ve actually absorbed what was said in an all-hands.” Turns out watching an 8-minute Loom on your own time, pausing and rewinding when something matters, beats sitting through a 45-minute live session where you’re half-checking Slack the whole time.

And the decision logs? They eliminate the “why did we decide this?” argument that happens six months later. They kill repeated debates. They give new hires a searchable encyclopedia of institutional context instead of a week of “go ask Sarah, she was here when we made that call.”

The Part Nobody Tells You

It’s not going to be easy, so let’s not sugarcoat the realities that most async advice skips over.

Not everyone thrives async. Some people genuinely need real-time interaction to feel connected and do their best work. That’s not a flaw. I lost a designer this way. She was talented, but the lack of daily face-time made her feel invisible. I just assumed the system worked for everyone because it worked for me. Classic founder brain. (If I could go back, I’d have asked her what she needed instead of assuming.)

The transition period is rough. When you kill meetings, there’s a 2-3 week window where people feel unmoored. They’re used to meetings as a proxy for productivity. “I was in meetings all day, so I must’ve been working.” Removing that crutch is disorienting. Expect some pushback and some people who quietly re-create the meetings you killed, just with different names.

Written communication is a skill, not a given. Going async means your team needs to write clearly. Not everyone does. Some people need coaching on how to structure a written update, how to write a decision doc, how to give feedback in a comment thread instead of a hallway chat. Budget time for this.

A Framework (If You Want One)

I’m wary of frameworks because they tend to make messy reality look clean. But if you want a starting structure, here’s what worked for us:

Layer 1: Documentation as the default. Anything that doesn’t require real-time back-and-forth gets written first, shared async. Not Slack threads. Those disappear into the void. Actual docs that live somewhere searchable.

Layer 2: Decision logs as infrastructure. Major decisions get logged. Context, rationale, alternatives considered, trade-offs, timestamp. This becomes your team’s institutional memory. When someone asks “why do we do it this way?” six months from now, you point them to the log instead of reconstructing the conversation from memory.

Layer 3: Guard your sync time. Two, maybe three hours of synchronous meetings per week, max. Treat sync time like venture capital: scarce, valuable, and wasted on things that don’t need it. If a meeting could be a doc, it should be. If a discussion could happen in a comment thread over 24 hours, let it.

Groundbreaking? Nope. It’s boring, operational, and it works. The hard part isn’t understanding the framework. It’s having the discipline to stick with it when someone says “can we just jump on a quick call?” for the fifteenth time this week.

Try This

Open your calendar right now. I’ll wait.

Count every recurring meeting you have this week. Standups, 1-on-1s, all-hands, brainstorms, syncs, check-ins. All of them. Write down the total hours.

Now go through each one and ask: “Could this be a written update, a Loom, or a comment thread instead?” Be honest. If the answer is “well, it’s really a status update” or “we mostly just go around the room sharing what we’re working on” — that’s not a meeting. That’s a habit.

When I did this exercise, we cut more than half of our recurring meetings in a single week. The one complaint came from a PM who genuinely liked the daily standup because it was the only time he talked to people before lunch. (Fair enough, James. We found you a better solution.)

---

What I’ve Been Using: Twist by Doist

I’m a Slack person by default. But I’ve been playing with Twist, and the philosophy behind it is smart enough that it’s changed how I think about messaging tools.

The pitch is simple: it’s Slack, but designed for async. Conversations are organized by topic in threads, not channels. There’s no green dot showing who’s “online.” Notifications are calm by default. The whole UX is built around the idea that you’ll respond when you’re ready, not when a red badge bullies you into it.

I’ve talked to a few teams who’ve made the switch. The engineers tend to love it — deep work time goes up noticeably when people stop expecting instant replies. The pushback usually comes from sales and customer-facing teams who live in real-time. One founder told me getting his sales team to switch was like convincing his dad to use a password manager. They ended up running both tools, which is its own kind of chaos.

The honest take: Twist is built for async work and Slack isn’t. But Slack’s already won the adoption game, and ripping it out of an existing org is like trying to take a bone from a dog that’s been chewing it for three years. If I were starting from scratch, I’d start on Twist. Converting an existing team? Try it with one department first and see if it sticks.

$8/user/month on the real plan. Cheaper than Slack Pro.

---

Worth Your Time

On decision logs: GitLab’s entire decision-making framework is public in their handbook. I spent about 20 minutes in their “disagree, commit, and disagree” section and it genuinely changed how I think about async conflict. Even if you don’t adopt their whole approach, that section alone is worth the read.

On meeting costs: Shopify canceled 10,000+ meetings across the company last year. Their internal data showed the average employee was spending 15+ hours per week in meetings. They cut that roughly in half and productivity metrics went up, not down. The interesting part isn’t the cut itself — it’s that nobody missed most of those meetings. Check out our breakdown of remote-first tool strategies for more on how companies are rethinking their operational stack.

On the human side: I found an interview with Amir Salihefendic (Doist CEO) where he talks about the loneliness problem in async teams and what they’ve actually built to address it. It’s the most honest take I’ve seen on the cultural trade-offs of going async, and if you’re worried about that cost (you should be, at least a little), start there.

---

The productivity gains from going async are real. I’ll stand behind every word of that. But whether people actually feel connected working this way… that one I don’t have a clean answer for. The designer I lost taught me that much. If you’ve figured out the loneliness piece without sacrificing the async gains, I genuinely want to know how you did it.