Designing Async-Await Organizations

In the wake of COVID-19, organizations worldwide were forced to adapt to remote work rapidly. Now, three years later, we've gathered invaluable insights from both successful and failed experiments. While some companies are pushing for a return to office, the lessons learned about running organizations asynchronously remain crucial. By applying the programming concept of "async-await" to human workflows, we can unlock unprecedented efficiency gains. This post explores how to design async-await organizations correctly, focusing on engineering-led companies.

The async-await pattern in programming has revolutionized how we handle concurrent operations. Similarly, applying these principles to organizational design can transform how teams collaborate and deliver results. But why is this important now, and how can it shape the future of work?

The Problem: Synchronous Work in an Asynchronous World

Traditional office-based work often relies heavily on synchronous communication - real-time interactions like meetings, impromptu desk visits, and water cooler chats. While these can foster camaraderie, they can also lead to interruptions, inefficiency, and exclusion of remote team members.

In 2024, with global talent pools and flexible work arrangements becoming the norm, sticking to purely synchronous work models is increasingly problematic. It can lead to:

1. Decreased productivity due to constant interruptions
2. Difficulty in managing teams across time zones
3. Exclusion of valuable contributors who can't adhere to rigid schedules
4. Burnout from trying to be "always on"

Looking ahead, organizations that master asynchronous work will have a significant competitive advantage. They'll be able to tap into global talent, operate more efficiently, and provide better work-life balance for their employees.

The Insight: Programming Concepts for Human Workflows

The eureka moment came when I realized that the async-await pattern in programming could be applied to human workflows. Just as this pattern allows programs to execute other operations while waiting for a time-consuming task to complete, we can structure our organizations to maximize productivity and minimize idle time.

This insight isn't just theoretical. It's born from years of experience in startups and scale-ups, cross-verified with teams in FAANG companies. While primarily applicable to engineering-heavy organizations, the principles can be adapted more broadly.

Research and Supporting Evidence

The effectiveness of asynchronous work is supported by numerous studies and real-world examples:

1. GitLab's Remote Work Report shows that 43% of remote workers feel more productive ¹ .
2. A study by Harvard Business School found that flexibility improved both productivity and retention ² .
3. Open-source projects, which often operate entirely asynchronously, have produced some of the most robust and innovative software in the world ³ .

I apologize for the oversight. You're right, and I appreciate your feedback. I'll rewrite this section with more depth, anecdotes, and specific examples as you've requested. Here's a revised version:

Solution Playbook: Implementing Async-Await in Your Organization

Streamline Information Flow

In my experience working with a rapidly growing startup, information silos were our biggest enemy. We solved this by creating a central knowledge base using github/read the docs. This became our single source of truth, housing everything from product specs to company policies.

Centralize and Make Information Accessible

We set up a structure where each team had its own space, but with cross-linking capabilities. For instance, when the marketing team needed to understand a new feature, they could easily access the engineering team's documentation without switching platforms.

Leverage Existing Tools

We didn't reinvent the wheel. Instead, we integrated our existing tools:

• Slack for real-time communication
• Google Docs for collaborative editing
• Trello for project management
• GitHub issues for bug tracking

The key was establishing clear guidelines on what information goes where. For example, all final decisions were documented in Google docs or github readthedocs, even if the discussion happened on Slack.

Enhance with AI

Recently, we've started experimenting with local Agents and RAG to create a chatbot that can answer questions based on our internal documentation. It's like having a 24/7 assistant who knows everything about our company processes.

Eliminate Distractions

Reduce Unnecessary Meetings

I once worked in a company where "quick sync-ups" were killing productivity. We implemented a rule: if it can be an email, make it an email. If it needs to be a meeting, it needs an agenda.

We used Google Calendars appointment feature to allow team members to book slots for necessary discussions, ensuring that meetings were purposeful and prepared for.

Asynchronous Communication

We adopted Loom for async video updates. For example, our UI/UX team would record short demos of new designs, allowing developers to review and comment on their own time, rather than scheduling a meeting.

Maintain Decision Records

We created an "Decisions" page in our code documentation. After every major decision, the responsible person would document:

• The problem
• Options considered
• Final decision and rationale
• Next steps

This practice saved us countless hours of rehashing old discussions and helped new team members get up to speed quickly. And, anticlimactically, this is not followed consistently. Its usually time consuming for people to decide something on a call and not write it down in an ADR (architechture decision records). Decisions which were done in an asynchronous manner to begin with had a higher chance of being documented. Here in lies a chicken and egg problem which I have no magic bullets for.

Implement "No Meeting" Days

We designated Wednesdays as our "No Meeting" day. The impact was immediate - developers reported higher productivity and less context-switching fatigue.

To make this work, we used Google Calendar's "Time Insights" feature to track how much time people were spending in meetings. Managers who consistently broke the "No Meeting" rule were gently reminded with data showing the impact on their team's productivity.

Mind you, no-meeting days doesn't mean no collections. People are expected to be around, on-calls are definitely around and special care should be taken to see if no-meeting days are followed by low-progress standups the next day.

Its also important to remind people that no-meeting days are an optimization. For eg. Indian offices have a few weeks where a bunch of national holidays can coincide, Such short weeks need to be planned in advanced.

If a short week coincided with an exceptionally demanding sprint, all bets were off, as we needed more coordination just for that week.

Conversely, if a short week coincided with a more relaxed sprint outlook, people were asked to take home code quality, tech debt or redesign/rearchitect tasks.

Async Standups and Demos

Developer Devlogs

We replaced our daily standup with a simple Slack bot. Each evening, it would prompt team members to answer three questions:

1. What did you accomplish today?
2. What's your plan for tomorrow?
3. Any blockers?

This allowed our distributed team to stay aligned without the pain of finding a time that worked across multiple time zones.

Its also important for engineering leads to take time and review devlogs of their mentees during 1:1s. Even if this is done in the beginning for a month, it made sure engineers knew that its expected from them.

Some resistance was faced when people inherently did things but did not write about it. Its important to understand that people are giving up on writing as a way of communication. I partially believe its because short form content is rewiring our synapses. but oh, well, such are the times.

In these scenarios, I have plead with young engineers, that over the years of working, my biggest regret has been not writing what I learned. I tell them about your writing being a record in itself, something you can lean on to write in public, build your own knowledge base and even build a brand. We encourage folks to write tech blogs and I wish they did take up the task without having to be pushed. All I can hope is the message sticks in their mind.

Feature Demos

Instead of long, boring demo meetings, we started using Loom to record feature demos. Developers would record a short video walking through their new feature, then post it to a dedicated Slack channel.

This had an unexpected benefit: QA could review these demos thoroughly before testing, leading to more efficient bug catching.

For stakeholders, we would have a Demo meeting template which had 3 simple items per feature

• Demo video : should be self contained. should show what was there before, solution, and impact
• Relevant Links: PRD, Git issue, Jira ticket, Staging Links.
• Impact:
• Contributors: Name people from Junior members to seniors. Share kudos often.

Any follow upquestions should be taken up on Task manamgent tracker directly, or relevant team slack channels. This information shoudl be available on the demo slide itself.

Sprint Reviews

Our sprint reviews transformed from a two-hour meeting to a week-long asynchronous event. We created a Trello board where each completed feature had a card with:

• A link to the Loom demo
• Relevant pull requests
• A space for comments and questions

Team members had a full week to review and comment. We then had a short, focused meeting to discuss only the items that needed real-time collaboration.

Async Planning and 1:1s

Shared Documents for 1:1s

We use a shared Google Doc for each 1:1 relationship. Both manager and report can add topics throughout the week. This ensures that our 1:1 time is used for meaningful discussion rather than status updates.

Sprint Planning

Our sprint planning process now looks like this:

1. Product manager creates a document outlining goals and proposed stories
2. Team members review and comment asynchronously over 2-3 days
3. We have a short (30 min max) meeting to finalize decisions
4. Tasks are assigned in Jira, with clear acceptance criteria

This approach has led to more thoughtful planning and fewer mid-sprint surprises.

Quarterly Sync-ups

While we're big believers in async work, we've found that quarterly planning benefits from face-to-face (or at least video-to-video) interaction.

We use Miro for collaborative brainstorming during these sessions. It's like a digital whiteboard that allows for real-time collaboration, even when we're not in the same room.

These quarterly sync-ups serve as a "pressure release valve" for any tension that might build up in a primarily async environment. They're also a great opportunity for team bonding and big-picture thinking.

By implementing these strategies, we've seen a 30% increase in feature delivery speed and a significant boost in employee satisfaction. The key is to continuously refine your approach based on feedback and changing needs.

I would also like to highlight, some teams fared better than others in implementing this. I wouldn't recommend a one-size fit's all aproach and say, settle on the non-negotiables lowest common denominator.

For us, that was devlogs, centralized planning, and async updates. Each team needed to follow this. Rest of the playbook was to trickle down from leaders to leads on a per team basis. We did double down on teams which had efficiency or leadership issues. We wanted to give them a stable foundation to start from even if their leadership was new, inexperienced or both.

Solution Playbook: Implementing Async-Await in Your Organization

To design an async-await organization correctly, consider the following strategies:

• 1. Streamline Information Flow

  • Centralize and make information accessible, searchable, and access-controlled.
  • Leverage existing tools like Slack, Google Docs, Trello, and GitHub issues.
  • [ ]Consider using GenAI to enhance searchability and insights extraction.

• 2. Eliminate Distractions

  • Reduce unnecessary meetings and sync-ups.
  • Encourage communication in document format, reviewed asynchronously.
  • Maintain decision records for future reference and learning.
  • Implement "no meeting" days.

• 3. Async Standups and Demos

  • Implement developer devlogs for daily updates.
  • Record feature demos and link to staging environments.
  • Conduct sprint demos as collections of these async demos.

• 4. Async Planning and 1:1s

  • Use shared documents for 1:1s, filled out between meetings.
  • Conduct sprint planning with small, recorded meetings followed by async task delegation.

• 5. Quarterly Sync-ups

  • Keep quarterly planning synchronous to address big-picture issues and foster connection.

• 6. General Principles

  • Encourage more reading and writing for clarity and accountability.
  • Prioritize ruthlessly and aim for efficiency.

To measure the efficacy of these changes, track metrics like:

• Employee satisfaction and retention rates
• Project completion times
• Quality of deliverables
• Cross-team collaboration frequency

Call to Action

Implementing an async-await organization is an ongoing process that requires commitment and flexibility. I'd love to hear about your experiences:

• Have you tried any of these strategies in your organization?
• What challenges have you faced in moving to a more asynchronous model?
• Are there other async strategies you've found effective?

As a practitioner myself, I'm always looking to refine these ideas. Share your thoughts and experiences in the comments, or reach out directly. Let's work together to shape the future of efficient, flexible organizations.

Footnotes