Asynch and N’Synch

There’s a massive difference between simply allowing people to work remotely and fully embracing an asynchronous work culture. Many companies claim to be remote-first, but they’re still tied to a synchronous mindset—expecting immediate responses, instant meetings, and a set window of time where team members are supposed to have “butts in seats”. In contrast, asynchronous work fosters autonomy and flexibility, giving teams the space to work at their best, free from constant interruptions and rigid timelines.

Asynchronous collaboration is more than just a shift in work style—it’s a strategic approach to maximizing efficiency, creativity, and productivity. I’ve worked in both environments and I can say that there’s no world where an entire company works 100% asynchronously, but there are huge benefits to be gained from making a shift towards defaulting to asynchronous.

If you think about a company leaning on synchronous communication and collaboration 50% of the time. That means that almost half of a person’s day is based on reactivity. When you have teams in different time zones or with different working hours, teams end up being dependent on others, susceptible to interruption, and generally less productive for the majority of their working day. These team members have no time for and spend more time talking than doing.

On the other end of the spectrum, some companies take this a little too far for my personal liking. When you combine working amenities like total flexibility with unlimited PTO and async-first work culture, it can take days (or weeks) to align and solve a problem or make a decision — especially with international teams.

I’ve been recently reminded of the stark contrast between the two models and decided it was time to write down my thoughts on what works at scale. Whether you’re a small team of 5 (or less) or an organization of thousands of people, these are the things that I’ve seen make teams more efficient, effective, and impactful.

Best Practices for Asynchronous Communication

Communication is critical in any work culture but it’s 10x more important if you’re trying to foster an asynchronous-first working culture. Everyone needs to trust that everyone else is taking care of their piece of the puzzle so that it can all come together, and the best way to build trust is through transparency.

1. Use Slack for Updates, Not Urgent Communication

I love Slack and I appreciate it’s ability to keep teams aligned, connected, and focused. I even appreciate how effective it can be for real-time collaboration when troubleshooting, debugging, and gut-checking, but when misused, it can be destructive to asynchronous work and culture.

It’s kind of like the Rings of Power…

My Personal best practices:

• Keep it public - Avoid backchanneling in DMs or closed group chats. Use the relevant channel to provide updates or capture discussions.

• Clarify the urgency - Is it a critical decision? Let people know. Is it something you would love input on at some point in the next week? Let them know. Slack has a lot of different features built in to help users keep track and prioritize their messages. Trust that your team can choose one of them and remember to come back to it when they have time. Worse case, you remind them in a few days if you don’t get a response.

• Acknowledge and set expectations - Let people know that you saw their posts and, when appropriate, let them know when you plan to get back to them. In some cases, and emoji reaction may be all they need to know that you read and understood their update. In other cases, when they are waiting on feedback from you, it’s important to let them know when you are planning to get back to them.

• Don’t repeat yourself - Slack makes every post and thread linkable so it’s easy to point people back to discussions that have already happened or information that has already been provided. Instead of starting a whole new thread, identify your “canonical” discussions and link them in your internal documentation. When it’s time to revisit the conversation, revive the thread so you can keep the historical context close by.

• Link to full context: If you're referencing a decision or project update, include links to relevant documents or threads. This provides clarity and ensures that no one is left waiting for further explanations.

  • Note: This may mean that you also need to remind people to read the linked content before they start asking questions about your update.

Example: If I am providing an update about a launch timeline, I would include links to the original feature brief or prd, the updates I provided so far, the feedback gathered during the testing period, and our GTM plan.

2. Explore Different Formats

Not everything can be explained well through text. Tools like Loom are perfect for walking your team through complex concepts or product updates. Instead of scheduling a meeting that requires aligning multiple time zones, record a quick video and share it with the team.

If you don’t want to record a full video you can use tools like Scribe to automatically generate a step-by-step guide based on the steps you take in your browser. You can also leverage text-to-speech tools like Elevenlabs or NotebookLM to give your team a version of the information that they can listen to and process differently. Maybe they catch up during a bike ride or walk, maybe they listen to it on the way home from dropping their kids off at school. The goal is to make the information available, accessible, and clear.

Apply this same philosophy to your responses to improve clarity and to make it feel more human. Mark up your screenshots when you catch a bug or layout issue. Record a screen share when you experience something weird with the UX. Record a quick voice clip to send and share praise to make it more personal.

Again, the goal is not to completely replace real-time collaboration, but to reserve it for the things that will most benefit from it

3. Make Meetings Optional (But Record Them)

Meetings still have their place in product teams, but they shouldn’t dominate your schedule. Most meetings include people who are critical to decision making and people who should be kept in the loop (sometimes other people for moral support?) Here’s how to manage meetings in a asynch-first culture:

• Record and share every meeting: Not only does this build trust by offering a high level of transparency, it puts the ownership on others to stay in the loop. As long as you are making sure the information is available, it’s on them to provide input or feedback within a reasonable amount of time. Check out how Gitlab approaches meetings in their massive open-source handbook.

• Make attendance optional: For anyone who isn’t critical in making the decision or taking action to move forward.

• Set a deadline for input: If decisions need feedback, make it clear when responses are due so progress isn’t delayed.

Note: I love how Codas handles their “Catalyst” time to unblock any teams in real time by ensuring the top level decision-makers are consistently available. I heard about it on the “Behind the Craft” interview with Lane Shackelton.

Example: When you have a roadmap planning meeting, make it optional for engineers or designers who may not need to be involved in real-time but can later review the recording to hear the intent and vision the same way other members of the teams or leaders heard it.

Key takeaway: Make meetings optional, record them, and be very clear about what feedback you are open to or seeking and when it needs to be submitted.

4. Emphasize Clear Documentation

For asynchronous work to thrive, documentation needs to be thorough and accessible. Product teams should have a centralized space for documenting intentions, processes, decisions, and progress updates.

You should essentially hold your internal communication and documentation to the same standards we put on developer documentation.

• Use a centralized content platform: I personally prefer Coda. It has everything I need and I’ve barely scratched the surface of what it can do functionally. I know a lot of teams use Notion or Confluence as well.
  

  

• Ultimately what you need is:

  • A free form WYSIWYG content editor that allows for different layouts, embeds, and media.

  • A way to tag and notify specific people and/or teams.

  • A way to organize all of the content with tags, categories, etc.

  • A capable search tool that can find content, people, teams, projects, etc.

  • Some sort of function to display task lists, assignments, timelines, due dates, etc. (even if you track them in another tool)
    

• Keep a source of truth: You’re going to end up with many smaller posts and dos that are related to larger initiatives and it’s not efficient to go back through all of them and update each one. Instead, use something like a “Source of Truth” to help others navigate the information. Include links and high-level context to all of the different deliverables, discussions, and decisions that happened as part of the initiative as well as a clear summary of the project and its current status.

Example: If you’re building out a new feature that integrates with multiple experiences across the product, you would have a single source of truth for that feature set and then you might have separate threads for:

• Building the core functionality

• Designing the UX for each touchpoint across the product

• Implementing it in each product area

• Testing and feedback

• Launch planning

• Launch marketing

• Lifecycle marketing updates

• Existing user activation

Key takeaway: Documentation is the backbone of asynchronous collaboration. Ensure it’s detailed, accessible, and always up to date.

5. Set Clear Expectations Around Response Times

One of the challenges in asynchronous work is managing communication expectations. If you want people to do their best work, you need to let them work when they are at their best. Personally, I wake up at 4am and get an insane amount of work done before my kids wake up around 6:30am or 7am. I’ve been very open with clients and teams over the years that if we want to maintain real-time communication at all hours, they would need to be responsible to me during the early hours as well. All of them decided it was OK to wait a bit for a response.

Establish norms for how quickly team members should respond to different types of messages:

• Urgent issues: Use specific channels or tags (like @urgent) to flag time-sensitive matters, but make sure these are used sparingly.

• Regular updates: Clarify what the acceptable response window is—whether it’s 24 hours or 48 hours, so no one feels pressured to respond immediately.

When you default to “It’s not that urgent” teams tend to rally when something truly urgent comes up. It’s about m maintaining trust and mutual respect.

Key takeaway: Be clear about response times and what qualifies as urgent to avoid unnecessary stress.

Final Thoughts

The biggest piece in making all of this work is culture. You need people on your team who value focus time, who can trust their teammates to deliver, and who know what to do with the agency they are given. This means you need to place a high value on people who default to taking action and who tend to be creative problem solvers so that you enjoy the benefits without sacrificing efficiency.