How being "async-first" helped us unleash team synergy

Abstract banner image depicting a writing culture

Editor’s note

I got to know Snehal a few months back when we started talking about her team’s experience with async-first ways of working. Between a high level of work satisfaction, a shorter path to production and engaged clients, it seemed that her team had a lot going for them. We agreed that others can take inspiration from her team’s story, so Snehal consented to share her perspective about her team’s async-first shift. And here we are!

I lead a team of technologists that serves clients in a time zone that’s several hours removed from us. As you’d expect, we’ve faced all the familiar remote work challenges. We started with a meeting-centric way of working, like most other teams. But with multiple locations and time zones,  scheduling meetings was a tedious task. The result? Frustration and inefficiency. 

Ever since though, we’ve tamed that frustration and inefficiency, by embracing more asynchronous ways to collaborate. In this article, I’d like to describe how my colleagues and I work async-first. Through my experience, I hope you’ll find some inspiration to adopt these practices in your team. 

Guidelines and documentation create clarity

One of the reasons for teams to slip into meeting madness is the lack of shared understanding. It doesn’t help that some teams don’t have clear communication guidelines either. We’ve tried to address both of these aspects on our team.  

Shared understanding and clear communication guidelines underpin async-first team practices

For instance, when sharing stand-up updates, we defined a specific format and structure to ensure consistency. For each of our modes of communication, we’ve outlined the timelines for expecting responses too. Team members also know how we expect them to provide input or address any concerns, if we share ideas or proposals in writing.

Our team has also learned to use messaging tools effectively. Too often, an IM exchange starts with a “Hello”. It takes a few back-and-forth messages over several minutes to get to the point. We avoid this anti-pattern. Instead of just saying “hello”, we type a longer message with as much context as possible. This doesn’t just reduce interruptions, it helps us get to the point fast.

Agile methods tend to downplay documentation, but pragmatic documentation is essential on distributed teams. Done well, documents and artefacts can help teams build shared understanding at speed. So, instead of virtual meeting rooms, we turned to collaborative documents. These are among our primary tools to facilitate knowledge sharing and solve problems together.

Let me give you another example. Each time we propose a change, or a new design idea, or make a proposal in the team, we create a dedicated page on our wiki - Confluence. We follow the principle of “low-context communication”. The page provides thorough explanations, assuming that some readers may not be fully aware of the topic. Alternatives, their pros and cons, recommended approaches - they’re all part of such pages. Once we publish the page, all team members can contribute to it. If we need specific individuals to review the page, we tag them and provide them a  due-by date to share their perspectives and inputs. And hey, meetings are still OK! If we find any unresolved comments and thorny issues to address after gathering inputs, we get on a call to thrash things out. It’s “async-first”, not “async-only”. 

The value of being “async-first”

 
Image showing how Snehal's team benefited from going async first

The benefits of going async-first

 

We see a few clear benefits of operating this way. 

  1. We’ve become more inclusive in the way we make decisions. Every team member - introverts, non-native English speakers, and junior people, included  - has a voice. Writing also allows us to involve a broader audience than a meeting will afford. This way we gather diverse perspectives, which in turn, enhances the quality of our work.

  2. We’ve become more efficient at solving complex problems. Clear and concise writing solidifies understanding at speed, which then allows us all to “be on the same page” when making decisions.

  3. Work is less stressful. Written communication is “distribution friendly”. We can write a doc during our working hours and give our colleagues in another timezone the space to review it when they get to work. This may feel slow at first blush, but it reduces meetings, interruptions and the stress that comes with them. More importantly, slowing down encourages thoughtfulness. As the navy seals say, “Slow is smooth. Smooth is fast.” 

  4. We’re using overlap time efficiently. We find that clear writing avoids misunderstandings. This allows us to use our overlap time to get to “informed decisions” at speed. The more decisions we’ve taken, the more obstacles we’ve overcome. We can also trace back why we made certain decisions and explain the current state of our project. 

  5. Counterintuitively, the few meetings we have are better because we have a writing culture. It helps us prepare better, and disseminate outcomes. We can also limit the number of participants in a meeting because there’s no FOMO. After all, when we write, all information becomes transparent to everyone in the team.


As you may imagine, all these improvements have helped us be more efficient with the way we work. Our documentation discipline has helped us become more resilient in our practice of agile. Streamlined, async-first collaboration helps us free up time for deep work. We can focus on delivering software, and ultimately it helps us to shorten our path to production. 

Our async-first transformation is still a work in progress. Today we see our collaborative pages serve as hubs for information sharing. They facilitate seamless work handoffs across time zones.  In hindsight, they’ve allowed us to work out loud and share our experiences. These micro moves are helping our team foster an environment of growth, engagement, and productivity.

Snehal Wajpe

Snehal began her career in the cards and payments domain as a quality analyst. Over the last decade and a half, she’s held many positions, including test SME, operational lead, scrum master, business analyst and product owner. She’s built high-performing teams, managed co-sourced deliveries, created knowledge management assets and provided high-value solutions to customers.

At Thoughtworks, Snehal is responsible for leveraging talent, processes and technology to empower teams, cultivate talent and deliver outcomes in line with the company's vision.

Outside work, she enjoys traveling, trying new cuisines, playing outdoor games (especially volleyball) and spending time with family and friends.

https://www.linkedin.com/in/snehal-wajpe-214329103/
Next
Next

Deep work for executives: how “async-first” aids smart decision-making