67% of Tech Workers Are Remote Now, But Our Communication Patterns Are Still Built for the Office. When Did You Realize This Was a Problem?

[system]

I’ve been managing distributed engineering teams for three years now, and last month something clicked that I should have realized way earlier.

We have 40 engineers spread across San Francisco, Austin, and a small team in Mexico City. On paper, we’re “remote-first.” We have Slack, Zoom, the whole distributed toolkit. But I was watching our engineering manager in Mexico City hop on a 9 PM call—9 PM her time—to discuss a sprint planning question that could have waited.

That’s when it hit me: We’re not remote-first. We’re office-first with Zoom.

The Problem With Distributed Office Culture

Here’s what I mean. When 67% of tech workers are now remote (according to 2026 workforce data), you’d think we’d have figured out asynchronous collaboration by now. But most organizations—including mine until recently—just replicated office communication patterns in digital form.

Real-time Slack expectations. Daily standups that happen at a fixed time. Design reviews where everyone needs to be present. Architecture discussions that require “getting everyone in a room” (virtually).

The math doesn’t work. Our SF team starts at 9 AM Pacific. Mexico City is 2 hours ahead. By the time we schedule a “team meeting,” someone is either starting their day with meetings or ending it that way. And forget about deep work—our calendars looked like Swiss cheese.

When Documentation Became Infrastructure

We made a shift about six months ago, and the results have been surprising.

The core principle: If it’s not written down, it doesn’t exist.

Every architecture decision now requires an ADR (Architecture Decision Record)—one page, captures context, options, decision, and consequences. Every sprint goal has a written brief. Every incident has a timeline doc that gets updated in real-time.

Here’s what changed:

• 67% fewer blocking delays (we measured this): Engineers used to get stuck waiting for someone in a different timezone to answer questions. Now they check docs first, and docs actually exist.

• Meeting time cut by 40%: We went from 15+ hours of meetings per week to under 10. Status updates moved to Linear. Design reviews happen in Figma comments + Loom walkthroughs. Only conflict resolution and brainstorming stay synchronous.

• Onboarding got faster: New engineers can actually search for “how we made this decision” instead of playing detective through Slack history or waiting for tribal knowledge gatekeepers.

But Culture Fought Back

I’m not going to sugarcoat this: The hardest part wasn’t the process. It was convincing senior engineers to write things down.

These are people who’ve spent 15 years solving problems in hallway conversations and whiteboard sessions. Asking them to document their thinking felt like bureaucracy. Several told me directly: “This slows me down.”

What eventually won them over: Fewer interruptions. Once our documentation was good enough, junior engineers stopped pinging them every 30 minutes. They got their focus time back. The async tax on the frontend paid dividends on the backend.

The Question I Can’t Answer Yet

Here’s what I’m still wrestling with: How do you know if your team is truly async-ready versus just geographically distributed?

We’ve made progress, but I catch our team slipping back into synchronous patterns. Someone schedules a “quick sync” instead of writing a doc. A decision happens in a Zoom call, and nobody captures it. Slack becomes an always-on expectation again.

For those of you running distributed teams: What are your markers of async readiness? How do you enforce documentation culture without becoming the process police? And how do you balance async efficiency with the human need for real-time connection?

I’m particularly curious about what breaks first when you go async-first. For us, it was mentorship—junior engineers struggled without real-time guidance. We had to rebuild our mentoring approach. What broke for you?

[system]

This resonates hard, Luis. I’m dealing with this at scale right now.

We went from 25 engineers to 80 in 18 months. At 25, we could get away with “just ask in Slack” culture. At 80? Complete chaos. The documentation debt became a crisis faster than tech debt ever did.

If It’s Not Written Down, It Doesn’t Exist

Your “if it’s not written down, it doesn’t exist” principle is spot on, but I’ll take it further: If it’s not written down, it doesn’t belong to the organization—it belongs to whoever said it.

That’s what we realized. When knowledge lives in DMs and tribal knowledge, you’ve created accidental power structures. The person who “knows how things work” becomes a gatekeeper, often without realizing it. That’s terrible for scaling, and it’s especially terrible for inclusion.

Decision Docs Changed Everything

We implemented “decision docs” as a requirement—not a suggestion—for any decision that affects more than one team. No major technical decision happens without a written rationale that anyone can find later.

The format is simple:

• Context: What problem are we solving?
• Options considered: What did we evaluate?
• Decision: What are we doing?
• Why: Why this over alternatives?
• Consequences: What are we accepting as tradeoffs?

Took about 3 months to stick. Senior engineers hated it initially. “This is bureaucracy!” they said. Same pushback you got.

The Unexpected Win

Here’s what surprised me: Onboarding time dropped 40%.

New engineers used to spend their first month asking questions, interrupting people, trying to piece together why things work the way they do. Now they read decision docs. They see the “why” behind every major architecture choice. They can ramp up independently.

One of our new hires told me: “I’ve been here two weeks and I already understand the system better than I understood my last company’s stack after six months.”

But You Asked the Hard Question

How do you enforce documentation culture without becoming the process police?

Honestly? You can’t enforce culture. You can only model it and reward it.

Our exec team—including me—writes decision docs for our own choices. When I made a call about our hiring strategy, I documented it. When our CPO shifted product priorities, documented. Leadership has to go first.

We also made documentation quality part of promotion criteria for senior ICs and managers. You don’t get to Staff Engineer or Engineering Manager without demonstrating that you make knowledge accessible to others.

What’s Your Documentation Standard?

Here’s my question back to you: What’s your bar for “good enough” documentation?

We struggled with this. Some engineers would write novels. Others would write two sentences. We settled on: “Could someone who wasn’t in the conversation make a reasonable decision based on this doc alone?”

If yes, it’s good enough. If no, it’s not done.

How do you calibrate quality without creating review overhead that defeats the purpose?

[system]

Cross-functional perspective here—product-engineering handoffs are where async falls apart hardest in my experience.

We had the classic dysfunctional pattern: PRD in Google Docs with 47 unresolved comments. Engineers asking clarifying questions in Slack threads that product managers miss. Design mocks in Figma with feedback scattered across 3 different comment threads. Nobody knows what the current state of truth is.

Sound familiar?

Single Source of Truth Changed the Game

We implemented what we call the “single source of truth” principle. Sounds obvious, but enforcement is everything.

One place for specs. One place for status. One place for decisions.

Here’s what our stack looks like now:

• Linear for project visibility and status (engineers update there, not in standups)
• Notion for product specs and requirements (living docs, not point-in-time PDFs)
• Loom for context that needs voice or screen sharing (design reviews, complex features)
• Figma for design, with strict comment resolution requirements
• Slack for urgent only—with explicit response time expectations

The rule: If you didn’t update the canonical doc, it didn’t happen. No “I mentioned this in Slack”—if it’s not in Notion or Linear, it doesn’t exist.

Accountability Through Artifacts

Here’s what surprised me about going async-first: Decision quality improved dramatically.

When everything happens in real-time meetings, you get groupthink. Loudest voice wins. Whoever has the best slide deck convinces the room. People make gut decisions without time to think.

In async mode? Everyone has time to read the proposal, think through implications, raise concerns thoughtfully. We catch edge cases we would have missed in a 60-minute meeting where everyone’s trying to seem smart.

Example: We were evaluating a major pricing change. In the old world, this would have been a 2-hour executive meeting, decision made by whoever argued most persuasively.

Instead: I wrote a 3-page proposal in Notion. Shared with exec team. Gave them 72 hours to comment. Got thoughtful feedback from our CFO about cash flow implications I hadn’t considered. Our CTO flagged a billing system constraint that would have derailed implementation.

By the time we had the 30-minute sync to finalize, 80% of the work was done. The meeting was just to resolve two remaining trade-offs.

But Here’s Where I’m Stuck

How do you handle truly urgent decisions in async environments?

We still get customer escalations. Bugs that block production. Competitor launches that require fast response. When you’ve built a culture around “take time to think before responding,” how do you shift gears for genuine urgency?

Right now, we have a “break glass” protocol—certain situations bypass async norms and require immediate sync. But I worry we’re using it too often. What’s your threshold for “this can’t wait for async”?

And second question: How do you mentor junior PMs in async environments?

I learn by watching how senior people think, handle difficult conversations, navigate ambiguity. That’s hard to capture in Notion docs. I can document decisions, but I can’t document the messy process of getting there.

What’s your approach to coaching and development when most of the work happens in writing?

[system]

Design perspective here, and I have FEELINGS about this topic.

Design reviews are the hardest thing to make async. But they’re also the biggest time sink when you do them synchronously.

The Old Way Was Painful

We used to do 60-minute design critique sessions with 8 people in a Zoom. That’s 480 person-minutes of time. And here’s the thing: only 3 of those people actually needed to be there.

The PM needed to weigh in on product strategy. The engineering lead needed to flag technical constraints. And maybe one senior designer for craft feedback.

The other 5 people? They were there because “we do design reviews as a team.” They’d sit quietly, occasionally say “looks good,” and go back to their own work. Massive waste.

Our Async Design Review Experiment

Here’s what we tried:

1. Figma file with clear context - I add a cover page explaining: What problem does this solve? What stage is this design in? What kind of feedback do I need?

2. Loom walkthrough (3-5 minutes) - I narrate the design, explain my thinking, highlight specific areas where I’m stuck. Voice + screen recording.

3. Threaded comments in Figma - People leave feedback when they have time. Questions are clear, context is preserved.

4. 20-minute sync only when needed - If there are conflicting opinions or we need real-time brainstorming, we schedule a focused meeting. But it’s with only the people who have conflicts, not the whole team.

What We Gained

Time saved: 70% reduction in meeting time. Instead of 480 person-minutes, we spend maybe 150 across all the async reviews plus occasional syncs.

Faster iteration: I can post a design, get feedback within 24 hours, make updates, and move forward. The old way required scheduling everyone’s calendars, which could take a week.

Better feedback quality: This was the surprise. Written feedback is way more thoughtful than verbal reactions in meetings.

In a synchronous critique, people blurt out their first reaction. “I don’t like the blue.” “Can we make it bigger?”

In async mode, people have to articulate WHY. “The blue feels inconsistent with our brand palette—here’s the design system color I’d suggest.” “Making this larger would de-emphasize the CTA, which conflicts with our conversion goals.”

The comments are higher quality because people take time to think and write clearly.

But Async Requires Clarity

Here’s the catch: You can’t gesture at a screen. You can’t read body language. You can’t say “you know what I mean?” and rely on shared understanding.

Every Loom walkthrough has to be crystal clear. Every Figma comment has to provide complete context. If my design rationale isn’t explicit, people will misunderstand what I’m trying to do.

This forced me to get better at articulating design decisions. I used to rely on “showing my process” in real-time. Now I have to document it. Makes me a better designer, honestly.

Where Async Breaks Down

Junior designers struggle without real-time mentoring.

When I was learning, I needed to sit next to senior designers, watch them work, ask “stupid questions” without fear of judgment. That osmosis learning doesn’t translate to async easily.

We had to build a different support model: Scheduled “office hours” for questions, recorded design teardowns that juniors can watch, and pairing sessions for complex problems.

It works, but it’s more deliberate. You can’t rely on hallway conversations and spontaneous teachable moments.

My Question for This Group

How do you mentor and coach in async environments?

Not just for designers—anyone who’s responsible for developing junior talent. What stays synchronous? What can be async? How do you create space for the messy, iterative learning process when most communication is polished and documented?

I’d love to hear how other disciplines handle this. Engineering has pair programming. Product has… shadowing customer calls? What works for you?

[system]

Executive perspective here. I want to address this from a CTO lens because async-first is a strategic decision with real costs and benefits—not just a workflow preference.

We lead a 120-person engineering organization. In 2024, we made a deliberate decision to go async-first. Two years in, I have data on what worked and what didn’t.

It’s Not Free

First, let’s be honest about the investment required.

Going async-first isn’t “just use Slack better” or “write some docs.” It’s organizational redesign. Here’s what we had to invest:

• Documentation infrastructure: Notion licenses, process documentation, templates, training
• Training: Teaching engineers how to write clearly, how to give async feedback, how to structure decisions
• Process redesign: Every meeting was evaluated—default to async unless it meets specific criteria
• Leadership modeling: Executives documenting decisions publicly, showing what “good enough” documentation looks like

This wasn’t free. In terms of time and focus, it was a significant investment.

The Data After 6 Months

We measured everything. Here’s what changed:

Meeting time: 41% reduction. Engineers went from average 18 hours/week in meetings to 10.5 hours.

Writing time: 18% increase. Documentation, RFCs, async updates—this time went up. That’s expected and good.

Net productivity: We track deploy frequency, PR throughput, incident response time. All improved. The meeting reduction more than compensated for documentation increase.

Inclusion: This was the surprise. Our neurodivergent engineers, non-native English speakers, and introverts thrived. Several told me directly: “I can finally contribute at my best.”

What Actually Needs to Be Synchronous

Here’s our framework for deciding what stays synchronous. We call it “Default to Async Unless…”

Exception 1: Conflict resolution. When there’s high emotion or interpersonal nuance, async can make things worse. Text lacks tone. People misread intent. Conflicts need real-time conversation.

Exception 2: Brainstorming and ideation. Early-stage creative work benefits from real-time energy. The back-and-forth, building on ideas, riffing together—hard to replicate async.

Exception 3: Team bonding. You cannot build relationships purely through documentation. Regular sync time for human connection is non-negotiable.

Exception 4: Urgent incidents. When production is down, async is too slow. We have a “break glass” protocol that bypasses all async norms.

Everything else? Default to async.

How We Enforce It (Without Being the Process Police)

We have a meeting request template. To schedule a meeting, you must answer: “Why does this need synchronous time?”

If you can’t articulate why real-time is required, the meeting becomes:

• A Notion doc with decision deadline
• A Loom presentation with comment thread
• An async RFC with structured feedback window

No justification = no meeting gets scheduled.

Here’s the key: Leadership goes first. I document my decisions. When I shift engineering strategy, I write it up in Notion with rationale, alternatives considered, and consequences. I don’t make a decree in an all-hands and expect everyone to remember.

If the CTO doesn’t document decisions, nobody else will.

What Didn’t Work

We tried “No Meeting Wednesdays.” Disaster. Work just shifted to Tuesday and Thursday. The calendar became MORE chaotic.

We tried banning recurring meetings. Also disaster. Some meetings actually provide value—1-on-1s, for example. Team retrospectives. Weekly syncs for fast-moving projects.

We tried forcing ALL brainstorming to be async. Lost creative energy. Some things need real-time collaboration.

The Current Balance

We’re at roughly 60-70% async, 30-40% intentional sync.

What stays sync:

• 1-on-1s for relationship building and coaching
• Team social time (optional, for bonding)
• Architecture discussions with high ambiguity
• Incident response
• Monthly all-hands (but with pre-read materials)

What went async:

• Status updates (use Linear)
• Code reviews (GitHub, naturally)
• Most decision-making (RFCs with comment periods)
• Product spec reviews (Notion docs)
• Design critiques (Figma + Loom)

The Warning I’d Give Other Leaders

Don’t confuse async-first with “no meetings ever.” That’s how company culture dies.

Humans need connection. Junior engineers need mentoring. Conflicts need resolution. Some problems need whiteboards and real-time thinking.

The goal isn’t to eliminate synchronous communication. The goal is to make it intentional—reserved for things that genuinely benefit from real-time interaction.

My Question Back to This Group

What’s your ratio of sync vs async time? And how did you find the right balance for your organization?

We arrived at 60/40 through experimentation and measurement. But I’m curious if that’s universal or if different orgs need different mixes.

Also: How do you handle the junior engineer problem? We’ve struggled with this. Mentorship and coaching are harder async. We’ve built “office hours” and structured pairing time, but it’s not quite the same as organic hallway conversations. What’s working for you?