Moving from Sync-Heavy to Async-First: Our 6-Month Journey

[vp_eng_keisha]

Six months ago, our engineering team was drowning in meetings. As we scaled from 25 to 80+ engineers across three time zones (Atlanta, Austin, and Bangalore), the synchronous collaboration model that worked when we were small had become our biggest bottleneck.

The average engineer was spending 20+ hours per week in meetings. Standup, sprint planning, backlog grooming, architecture reviews, 1:1s, all-hands, team syncs, cross-team syncs… the calendar was a sea of blue blocks. Engineers were coding at 9pm because their days were consumed by Zoom calls.

The Breaking Point

Our VP of Product showed me data that made me sick: our cycle time had doubled in six months, even as we added headcount. We were getting slower as we grew. The culprit? Meeting overhead and context switching.

I knew we had to make a fundamental shift. After researching companies like GitLab and studying async-first practices, I made the call: we were going async-first, effective immediately.

Our Async-First Principles

1. Default to written communication. Every decision, every update, every discussion starts in writing. We use Notion for RFCs and ADRs, Slack threads for discussions, and Linear for work tracking. If it’s important enough to meet about, it’s important enough to document.

2. Protected focus time. No meetings on Tuesday and Thursday mornings. These are sacred “maker time” blocks. Engineers can opt-in to collaboration, but the default is deep work.

3. Clear response expectations. We established SLAs: 24 hours for non-urgent questions, 4 hours for urgent issues, immediate only for production incidents. This freed people from the “always on” anxiety.

4. Meeting scorecards. Every recurring meeting has to justify its existence quarterly. We ask: Could this be async? What’s the cost (attendees × time)? What’s the value? We killed 40% of our meetings in the first month.

5. Async-friendly rituals. Our standups moved to Slack threads. Sprint planning happens in Notion first, then a focused 30-minute sync to finalize. Retrospectives collect input async, discuss sync.

The Results (So Far)

After six months, the data is compelling:

• 60% reduction in meeting time (from 20hrs/week to 8hrs/week average)
• 40% increase in velocity (measured by story points delivered per sprint)
• Improved engineer satisfaction (from 6.8 to 8.2 on our quarterly survey)
• Better documentation (our Notion workspace went from 200 to 1,500+ docs)
• Higher quality decisions (more time to think = better technical choices)

The Challenges

I’d be lying if I said it was smooth sailing:

• Initial resistance: Some senior engineers who thrived in meeting culture pushed back. “We’re losing collaboration!” It took data and patience to win them over.

• Learning curve: Writing good RFCs and async updates is a skill. We had to teach it explicitly. We created templates and did writing workshops.

• Inclusion concerns: We had to be intentional about ensuring quiet voices were heard. Async can amplify existing power dynamics if you’re not careful. We implemented “rounds” where everyone has to weigh in before a decision.

• Loneliness: Some people missed the social aspect of meetings. We added optional virtual coffee breaks and maintained a few key team rituals for connection.

The Key Insight

Async-first requires MORE upfront investment, not less. You have to document more, communicate more clearly, and create stronger structures. But once you pay that cost, the returns are exponential. Your team can work across time zones, people can think deeply before responding, and decisions get better because they’re not rushed.

The sync-heavy model optimizes for speed of communication. The async-first model optimizes for quality of work. In the long run, quality wins.

I’m still learning here, and every team is different. What async practices have worked for your teams? What challenges did you face? How do you balance the need for connection with the benefits of deep work?

[eng_director_luis]

Keisha, this resonates so deeply with my experience leading our distributed team at the financial services company. We have 40+ engineers spread across Austin, London, and Bangalore, and we hit the exact same breaking point about a year ago.

What struck me most about your post is the cultural dimension - when you’re managing across not just time zones but also different cultural norms around communication, the async shift becomes even more critical.

Our Async Standup Approach

We implemented what we call “async standup” using a Slack workflow. Every morning (local time for each engineer), they post in a dedicated channel using this template:

Yesterday: [What I shipped/progressed]
Today: [What I'm working on]
Blocked: [Any blockers - @mention relevant people]
Wins: [Small celebrations]

The magic is in the timing flexibility. Our Bangalore team posts at their 10am, Austin team at their 9am, London in between. Everyone can read the updates asynchronously, and we use threaded replies for questions. We still do a 30-minute sync once a week for complex discussions, but the daily standup friction is gone.

The “Wins” field was surprisingly powerful for team morale. People share small victories, and it creates positive momentum even when we’re not in the same room.

The Executive Challenge

One challenge you didn’t mention - and maybe you’ve solved this - is educating executives who expect immediate responses. Our CFO was used to walking over to the engineering floor and getting instant answers. When we went remote and async, he felt “disconnected” from engineering.

We had to do some serious change management upward. I created a weekly executive summary (written, in Notion) that gave him visibility into what we were working on, blockers, and upcoming releases. I also set explicit office hours twice a week where executives could drop in with questions.

It took about three months, but he eventually preferred the written updates because he could review them on his schedule and had a paper trail of decisions.

Cross-Cultural Considerations

One thing I’ve learned working with our Bangalore team: different cultures have different norms around “response urgency.” In Indian business culture, there’s often an expectation of immediate responsiveness to show dedication. Some of our engineers there felt anxious about the 24-hour response SLA because they worried it would signal they weren’t committed.

We had to explicitly discuss this in team meetings and get buy-in from the team leads in Bangalore. Now it’s actually become a source of pride - “we work smarter, not just faster.” But it required cultural sensitivity to implement.

The Incident Response Question

I’m curious how you handle real-time production incidents in an async-first culture? We still struggle with this. When the payment processing system goes down at 2am Austin time, we need people online NOW. We have an on-call rotation, but coordinating a major incident across time zones is still chaotic.

Have you found a good pattern for balancing “async by default” with “sync when critical”? I’d love to hear your approach.

The 60% meeting reduction and 40% velocity increase are impressive metrics. We saw similar gains - about 50% fewer meetings and a noticeable improvement in our cycle time. The documentation improvement is real too. Our Confluence instance went from being a graveyard of outdated docs to actually being our source of truth.

First-Generation Engineers and Unwritten Rules

One thing I want to add from my perspective mentoring first-generation engineers: async culture can actually be more equitable if done right.

In traditional meeting-heavy cultures, there are tons of “unwritten rules” about how to speak up, when to interrupt, how to disagree with a senior person. These are cultural signals that first-gen professionals often haven’t learned.

In async written communication, the playing field is more level. Everyone has time to craft their thoughts. You can edit before posting. The junior engineer from a non-traditional background has the same Slack canvas as the Stanford CS grad.

BUT - and this is critical - you have to teach writing skills explicitly. We run quarterly workshops on “How to write a good RFC” and “How to give async feedback.” We’ve created a library of exemplars. This investment pays off massively in clearer communication across the board.

Thanks for sharing your journey so transparently. The vulnerability about challenges is what makes posts like this valuable. Too many leaders only share the wins.

[maya_builds]

Coming at this from the design side, and honestly? Async made our design process BETTER, which surprised me.

When I was at my failed startup (yeah, still processing that), we had this culture of live design reviews. Everyone in a Zoom, designer shares screen, people fire off reactions in real-time. It felt collaborative and energetic.

But here’s what I realized: Real-time feedback is often reactive, not thoughtful.

The Loom Revolution

At my current company, I started using Loom for design walkthroughs instead of live reviews. I record a 5-10 minute video where I walk through the design, explain my thinking, point out areas where I’m uncertain, and ask specific questions.

Then I post it in Slack and give people 48 hours to watch and comment. They can pause, rewind, think deeply, and leave timestamped comments.

The quality of feedback improved dramatically. Instead of “I don’t like that blue” I get “At 3:42, the blue button doesn’t meet WCAG AAA contrast standards for our target users with visual impairments. Have you considered…”

People have time to actually think about accessibility, consistency with our design system, edge cases, etc. They’re not just reacting.

The Creative Spark Concern

That said - and this is where I have some tension with pure async - I do worry about losing the “creative spark” of live brainstorming.

Some of my best design ideas have come from chaotic whiteboarding sessions where someone says something random and it sparks a totally new direction. That generative, improvisational energy is hard to replicate asynchronously.

My current compromise: Async for feedback and decisions, sync for early exploration.

When we’re in the very early stages of a new feature (like, “what should this even be?” stage), I’ll do a live Figjam session with the PM and lead engineer. Anything goes, wild ideas welcome, build on each other’s thoughts.

But once we have a direction and I’m iterating on actual designs, it goes async. Critiques are async. Decisions are written in Notion.

This seems to get the best of both worlds - the creative chaos of sync when we need it, the thoughtful rigor of async for refinement.

Question: How Do You Balance Brainstorming With Async?

Keisha and Luis, I’m curious how you handle this in engineering. Do you have “brainstorming” moments for architecture decisions? Or is it all RFCs and written proposals?

I can see how some technical decisions benefit from real-time discussion (like, weighing trade-offs together), while others are better async. How do you decide which is which?

Design-Specific Async Tips

A few things that work well for design in async mode:

1. Visual async updates: I post design progress in a dedicated Slack channel every Tuesday/Thursday. Just screenshots with a sentence of context. Keeps people in the loop without meetings.

2. Recorded walkthroughs > static screenshots: Loom, Loom, Loom. The ability to narrate your design choices makes such a difference. Text alone doesn’t convey design rationale well.

3. Figma commenting workflows: We use Figma’s commenting system heavily. Each comment thread has a status (open, resolved, won’t fix) and an owner. This keeps async feedback organized.

4. “Design portfolio” for context: I maintain a Notion page for each project showing the evolution - early sketches, discarded ideas, final designs. New people can get up to speed asynchronously.

The last one has been huge for onboarding. New designers or engineers can browse the portfolio and understand WHY we made certain choices, not just see the final output.

The Vulnerability Piece

One thing I appreciate about async design feedback: it’s actually made me MORE comfortable sharing messy, early-stage work.

In live reviews, there was social pressure to present polished designs. You didn’t want to look unprepared in front of 8 people on Zoom.

In async, I can post rough sketches with a note like “This is very early, just exploring” and people meet me where I’m at. The pressure to perform is lower.

Maybe that’s just me and my startup PTSD talking, but the async format has felt psychologically safer for showing vulnerable, unfinished work.

[mobile_maria]

Mobile engineering adds another layer to this async conversation - we have to coordinate releases across iOS and Android, often with backend dependencies, across global teams. If there was ever a case study for why async matters, it’s mobile.

The Mobile Release Coordination Challenge

At Uber, I’m leading mobile platform for teams in São Paulo, Bangalore, and San Francisco. When we were sync-heavy, app releases were nightmares. We’d have 6-hour “release day” marathons with people joining from their evening/night to coordinate.

Someone in SF would find a crash. We’d wait for Bangalore to wake up to check if it was backend-related. Then São Paulo team would test on Brazilian network conditions. Back and forth, all day.

The “Release Window” Solution

We’ve moved to what I call “release windows” - planned periods where we have 4 hours of overlap between at least two time zones. During this window, we’re synchronous for critical coordination. Outside this window, everything is async.

Critically, we rotate which time zone gets the “off-hours” burden. One month, SF takes the early morning slot. Next month, São Paulo takes late evening. This distributes the pain fairly.

But 90% of release prep is now async:

• Release notes written and reviewed asynchronously
• Testing happens in each timezone with documented results
• Rollout percentage increases happen on schedule, monitored by on-call
• Post-release retrospectives start async (written), finish sync (30min call)

Result: Reduced release coordination from 6 hours to 90 minutes of sync time. Everything else happens asynchronously with clear handoffs.

Documentation for Emerging Markets

One thing I want to emphasize from the Brazilian/Indian team perspective: async culture REQUIRES excellent documentation, and that documentation needs to be accessible to non-native English speakers.

We’ve started using:

• Simple, clear English (avoid idioms, jargon)
• Visual documentation (screenshots, diagrams, video recordings)
• Multiple formats (some people learn better from video, others from text)
• Translations for critical docs (automated translation has gotten good enough)

This isn’t just nice-to-have. When your team is in Bangalore and they’re blocked on something documented only in a Zoom recording from SF at 2am their time, async breaks down.

The Junior Engineer Learning Benefit

Maya touched on this with design, but I’ve seen it in mobile too: async actually helps junior engineers learn.

In sync culture, junior folks often stay quiet in meetings. They don’t want to ask “dumb questions” in front of senior engineers. Or they can’t keep up with the fast pace of conversation.

In async Slack threads, I see junior engineers asking great questions and getting detailed answers. They can read the whole thread, Google concepts they don’t know, and respond when they understand. There’s no pressure to “perform” understanding in real-time.

Plus - and this is huge - they can read the decision history. They see how senior engineers think through trade-offs. It’s like having a recorded masterclass.

Specific example: One of our junior Android engineers in Brazil was struggling with our architecture patterns. Instead of trying to explain it in a meeting, our tech lead recorded a 15-minute Loom walking through a recent PR, explaining the “why” behind each decision. That video has been watched 37 times and is now part of our onboarding.

The “Always On” Trap

One caution from the mobile world: async can become “always on” if you’re not careful.

Mobile engineers often feel responsible for app health 24/7. The app is live, users are in every timezone, crashes can happen anytime. Combined with async culture, this can create expectation creep - “well, you’re working on your schedule, so maybe you can check this at 10pm?”

We’ve had to be very explicit:

• Response SLAs only apply during your working hours
• On-call rotation handles off-hours incidents
• PagerDuty for true emergencies only
• “Urgent” has a specific definition (user-facing crash affecting >1% of users)

Without these boundaries, async becomes “always available” which defeats the whole purpose.

Tools That Enable Mobile Async

For other mobile teams considering async, these tools have been critical:

• Notion: Our single source of truth for mobile architecture, runbooks, release process
• Linear: Work tracking with great mobile apps, keeps everyone in sync
• Loom: For demoing mobile features and explaining UI decisions
• Firebase Crashlytics dashboards: Shared visibility into app health across timezones
• TestFlight/Internal Testing slack bots: Automated notifications about build status

The key is reducing the need for “hey, what’s the status of X?” questions. Make status visible by default.

[product_david]

Product leader jumping in here - this whole thread is gold, and I’m taking notes.

What strikes me most is how async-first culture actually forces BETTER product discipline. Let me explain.

Async Forces Clarity in Requirements

In sync-heavy orgs, product requirements often get “clarified” in meetings. PM says something vague, engineering asks questions live, we iterate verbally, everyone nods, meeting ends. Three weeks later, what we built isn’t what anyone thought we agreed to.

Async doesn’t allow this laziness.

When I write a product spec in Notion and engineers read it asynchronously, every ambiguity gets exposed. They can’t ask me real-time follow-ups to patch over gaps in my thinking. The questions come in writing, and I have to answer them in writing, and suddenly I realize my spec was half-baked.

This is uncomfortable but incredibly valuable. It forces me to think more rigorously upfront.

The “No More Vague Meeting Decisions” Rule

We had a problem where product decisions would get made in meetings, but different people would leave with different understandings. The PM thought we agreed on X, engineering thought we agreed on Y, design thought we hadn’t decided yet.

Now we have a rule: If it’s not written in Notion, it’s not decided.

Every product decision gets documented:

• What we’re building (and NOT building)
• Why we’re building it (business context, customer pain)
• Success metrics (how we’ll know it worked)
• Open questions and assumptions
• Decision-maker and decision date

The meeting can still happen for discussion, but the decision gets formalized in writing afterward. This async artifact becomes the source of truth.

The discipline this creates is amazing. It’s much harder to make sloppy product decisions when you have to write them down and defend them asynchronously.

The Sales Team Challenge

One real struggle: Our sales team HATES async. They want immediate product answers because they’re on customer calls and need to close deals.

“Can we build this custom integration for Enterprise Corp?” - they want an answer in 5 minutes, not 24 hours.

Our compromise has been a “Product FAQ” that I update weekly. Common questions get written answers that sales can reference immediately. For new questions, there’s an async process in a dedicated Slack channel with clear SLAs:

• Simple questions (“Does our API support X?”) - answered within 4 hours
• Complex questions (“Can we build custom feature Y?”) - scoped within 24 hours, decision within 3 days

We also do live “Office Hours” twice a week where sales can drop in with urgent questions. But this is the exception, not the default.

It took training (both for sales and for me) but it’s working better now. Sales actually appreciates the FAQ because they can find answers faster than pinging me.

Product-Engineering Collaboration in Async Mode

Maya’s question about brainstorming is interesting from a product angle. We do have moments where we need creative, generative thinking with engineering and design.

Our pattern:

1. Discovery phase is sync: When we’re in early “should we even build this?” mode, we do live brainstorming sessions. Miro boards, wild ideas, building on each other.
2. Specification phase is async: Once we have direction, I write the spec async. Engineering and design review and comment async.
3. Refinement is async-first, sync-optional: Most clarifications happen in Notion comments or Slack threads. We only schedule a sync call if we’re stuck on a complex trade-off.
4. Execution is async: During build, updates are written (Linear, Slack updates, Loom demos).

This hybrid model seems to work. We get the creative energy when we need it, but default to async for the hard work of specification and building.

Async Improves Cross-Functional Alignment

One unexpected benefit: Async has improved how product, engineering, and design stay aligned.

When everything was sync, we’d have this game of telephone. Product tells engineering in one meeting, engineering tells design in another meeting, context gets lost.

Now, the Notion doc is the source of truth. Everyone reads the same thing. Design and engineering can see the customer research videos. Product can see the engineering RFC. There’s less information asymmetry.

We still have a weekly cross-functional sync to discuss strategy and blockers, but it’s 30 minutes because everyone already read the updates.

The Metric That Matters

From a product perspective, here’s the metric I care about: Time from decision to customer value.

Async culture has reduced this significantly. Why? Because:

• Less time wasted in meetings = more time building
• Better written specs = less rework and confusion
• Async allows engineering to work when they’re most productive
• Documentation means we don’t re-litigate the same decisions

Our cycle time from “decision to build X” to “X is live for customers” has dropped by about 35% since going async-first.

Where Sync Still Matters

That said, I agree with everyone that some things need sync:

• Customer calls (obviously)
• Crisis situations (major bugs, competitive threats)
• Early exploration and brainstorming
• Relationship building and culture moments
• Difficult conversations (firing, performance issues)

The key is being intentional about which mode fits which situation, not defaulting to sync for everything because it feels more “collaborative.”

Thanks for starting this conversation, Keisha. The metrics you shared are compelling, and I’m going to steal some of your ideas for our team.