The short version: decision latency, not effort, is usually the throughput bottleneck in distributed organizations. Not all meetings are waste, but the default “let’s hop on a call” reflex is one of the biggest productivity drains I’ve seen.
At the fintech startup, we figured this out the hard way. We had engineers spread across time zones, a product moving fast, and a calendar that looked like a game of Tetris nobody was winning. Something had to give.
The real cost of “let’s just sync up”
Here’s what nobody admits: a meeting at 10am and another at 2pm doesn’t give you a four-hour block in the middle. It gives you two useless slices where you can’t get into anything deep. You sit down, start loading the problem into your head, glance at the clock, realize you’ve got 40 minutes before the next call, and end up on Slack or email instead. The hard problems don’t get touched.
I watched this happen at the fintech startup. Smart engineers shipping shallow work because they never had the uninterrupted time to do the real thing.
The other cost is memory. Verbal decisions vanish. Someone says “we agreed on X” and three people remember it differently. New hires ask why something was built a certain way and the answer is “I think we discussed it in a meeting last March.” That’s not engineering. That’s oral tradition.
Writing changes everything
We shifted to async by default. Questions, proposals, decisions – write them down first. If the thread stalls or things get heated, jump on a call. But always come back and capture what was decided in writing.
The results were immediate. Engineers got their mornings back. People in different time zones stopped being second-class citizens. And decisions actually stuck because you could point to the thread where the trade-offs were discussed.
I also noticed something I didn’t expect: the quality of decisions went up. When you force someone to write a proposal instead of pitching it verbally in a meeting, they think harder. They check the code. They pull up the docs. Writing is thinking, and thinking is what we’re paying engineers to do.
How we actually did it
We kept it simple. For any meaningful decision, someone writes up a short doc:
# Decision: [Title]
## Context
## Decision
## Consequences
## Owner and date
Nothing fancy. Took five minutes to fill out. Saved hours of re-litigation later.
We set response time expectations so nobody felt anxious. Urgent stuff: respond within a couple hours. Normal threads: by end of day. Low priority: a couple days is fine. Once people knew the rules, the pressure to be “always on” disappeared.
Status updates went into public channels. Short, async, scannable. We killed the weekly status meeting entirely. Nobody missed it.
Sync still matters (sometimes)
I’m not anti-meeting. I’m anti-default-meeting. There are times when you absolutely should get on a call:
Building trust. Onboarding a new engineer, one-on-ones, team bonding – these need face time. Text doesn’t build relationships the same way.
Gnarly debugging sessions. When you’re staring at a production issue with six moving parts, a live whiteboard session beats a 47-message Slack thread.
Conflict. If two people disagree and the thread is getting tense, get on a call. Tone matters and text is terrible at conveying it.
Incidents. When the site is down, you don’t write a proposal. You get on a call and fix it.
The key is making sync the exception, not the rule.
The discipline of good async
Bad async is worse than meetings. I’ll admit that. If people write vague messages, bury the ask in paragraph four, or never specify deadlines, async becomes a graveyard of unanswered threads.
So we had rules. State what you need in the first sentence. Give just enough context to answer. Be specific about when you need a response. Batch your reading – don’t live in Slack all day. And for the love of god, don’t put long-term decisions in ephemeral chat. Use a doc, a wiki, a PR description – something searchable.
What I learned
Switching to async-first wasn’t just a process change. It was a cultural statement: we trust our engineers to manage their own time, and we value output over presence. The engineers who thrived were the ones who could write clearly, think independently, and reach out when they were actually stuck.
The calendar got quieter. The code got better. And when we did have meetings, they were short, focused, and worth everyone’s time. That’s the trade-off I’ll take every single time.