-
The world of work has changed considerably since the start of the global pandemic, as many of our teams are now highly distributed and remote.
Remote and distributed teams can experience burnout if they operate in primarily a synchronous manner.
If you’re building software or doing knowledge work in today’s day and age, you limit your productivity if you depend too much on meetings and tribal knowledge. You need effective written communication and the ability to do deep work.
The ability to work asynchronously, where people don’t have to be in the same physical or virtual space simultaneously, has several benefits.
Better work life balance
Higher inclusion
Improved knowledge sharing
Communication practices that support scale
Time for “deep work”
A culture that defaults to action
-
Your immediate team is a logical place to introduce async-first practices. Here’s how to go about it.
Focus on the value your team expects to get out of this shift. The more aligned they are to the benefits, the more they’ll warm up to the change.
Make the change small. Use the spectrum of synchronousness to guide the shift-left to a more asynchronous way of working. Every win counts.
Make a Ulysses pact – “Meetings as the last resort – not the first option.” By making this basic commitment, the team makes conscious shifts to reduce unnecessary meetings.
Appreciate that you need a balance of both sync and async communication. Both modes have their benefits. When you understand these benefits, you can choose the right communication patterns for the problems you’re solving.
Key points from “The async-first playbook”
In my book, I end every chapter with a summary of the points I discuss. This page consolidates all the chapter summaries for your benefit.
Part 1 - Adapting to the new normal
-
If you’re leading an async-first team, you must work async-first yourself. This requires a mindset shift.
Start by thinking how you can get the most out of yourself. Here are a few ideas.
Scrutinise your recurring meetings and decline or delete the ones that are "meetings without agendas".
Meetings are the last resort. Use that rule to make the meetings you have, more efficient.
Reduce repetitive communication and save time by committing them to a more permanent medium.
Use asynchronous communication to amplify your own voice and to be inclusive of your other leadership counterpart.
Be the change you wish to see in the world. By working asynchronously, yourself, you set the right example and you avoid being a bottleneck for others.
Reduce the busy-work you do by taking a systems-focus over a transactions-focus.
Take it on yourself to be a champion for inclusion. This involves rethinking collaboration.
Unlink the notions of speed and productivity. Many collaborative activities for software development benefit from slowing down.
Design inclusive communication. For example, use silent meetings to surface perspectives before diving into discussions.
Treat communications as a process and not an event. Use written communication and audit trails to connect various interactions.
Improve your team's resilience by reducing their dependence on you. Use asynchronous communication to improve information flows and to empower your colleagues.
-
Leaders of teams that go async-first, must use their judgement to decide a few factors that influence the team's success and the environment they'll work in. I'm calling these five factors, "environment variables".
Organise team boundaries and interactions to maximise autonomy and flow. Matthew Skelton and Manuel Pais’s team topologies provide you a framework to think about organising your teams.
Create a lean, maker-centric team. Add pure management roles only when necessary.
Keep a calm work environment when going async. Avoid these common mistakes.
Creating second shifts for communication.
Expecting results too early.
Being too busy to improve.
Be conscious about building a team culture. Spend time identifying team values and encourage behaviours congruent with them.
Align on a common team purpose. In the long run, this will help you retain team cohesion and a sense of collective ownership.
-
There’s no asynchronous work without writing. It’s a fundamental practice for going async-first.
If we don’t meet to communicate, then writing is the quickest and most cost-effective alternative. It has some clear benefits.
It’s inclusive by default for non-native English speakers, introverts, and neurodiverse people.
It’s thoughtful and deliberate – slowing down allows us to study problems and structure our thinking around them.
Writing is indexable, searchable, easy to structure, change and interact with.
Unlike conversations, written communication has a long shelf life. You can write once, run many times.
Asynchronous audio and video can serve as a substitute for writing especially when the content is uni-directional, has a short shelf life and when you don’t expect people to interact with the content.
We must acknowledge that face-to-face and even video communication win against writing, on speed and fidelity. Writing however, wins on inclusion and the ability to share context at speed. Most real-time communication benefits from an async-first approach, where you can reference a written artefact.
Writing well is a skill we all can get better at. By applying the inverted pyramid of journalism and using readability tools, you can guide yourself through the learning process. To avoid misunderstandings, you can supplement your writing with emojis and recorded video.
-
Before you start tweaking your team’s practices to be more async, you must set up some fundamental processes and protocols for working in a distributed fashion.
Show your workflow transparently on your task board. Everyone should know in a single view what the team is up to. Define ownership for each stage of the workflow and design for the best average cost and not the worst case.
Make your task board the primary hub for communication. Email and IM should be for external and interdepartmental communication first, general team communication next, and task-based communication only as an exception.
Adopt a consent-based decision-making process instead of trying a consensus-based or democratic decision-making approach every time. This'll help you default to action, while improving the overall pace and quality of decisions.
Agree on response times and reply expectations for each channel. Without these expectations in place, people will suffer from FOMO and you'll risk becoming an ASAP culture.
-
Meetings, while necessary to some extent, are the biggest blocker to asynchronous work. To be async-first, meetings should be the last resort, not the first option.
Audit your existing and upcoming meetings using the ConveRel quadrants. Meetings for conveyance can generally move async. Convergence may need some real-time interaction.
When you meet, follow the best practice we’ve discussed in this chapter, to keep meetings effective.
If you expect regular cross time zone meetings, aim for at least a four hour overlap between all members of the development team. If your clients are in a distant time zone, it helps to have at least an hour or two of overlap.
Connectedness is a feature of synchronous communication. This helps you navigate to the right of the ConveRel quadrants. So don’t lose your humanity. Make time for team bonding, in person or online.
-
Small moves from individuals and teams can help us vote with our behaviour, for an async-first work culture.
Personal plays help us broadcast our commitment to an async-first culture.
Set your chat message to broadcast that you're working asynchronously.
Write an email signature that tells people that they can reply when they are back at work.
Schedule your messages and emails to go out at times when you expect your recipients to be at work.
Block out focus time on your calendars so it's clear that you're in the middle of deep work.
Replace "quick syncs" with "async".
Team plays help us accelerate our shift leftwards.
Institute an inviolate four-hour block each day, when there are no meetings and everyone actively avoids distractions.
Choose a day of the week to designate as a no-meeting day. I recommend Fridays.
Delete all recurring meetings and from that point on, set up meetings that follow best practice.
-
Messaging can be a useful tool on distributed teams, provided we use it effectively and reduce the interruptions and noise it can otherwise generate.
Use chat as primarily an asynchronous tool and avoid thinking of it as "instant".
For urgent matters, don't use chat. Use a channel suitable for urgent communication, such as a phone call.
Name your chat channels intuitively, so they’re discoverable. If you can’t get consensus on these conventions, start by naming the channels that are in your sphere of influence.
Use your chat status to broadcast what you're doing right now and respect others' statuses as well.
Reduce the number of notifications you generate for people by writing detailed messages, using emojis as reactions and getting to the point in a single message.
Target your conversations to the people who need to actively participate. Summarise these later for the group, so you reduce noise.
Use and respect threads so conversation is easy to follow.
When things get complex, slow down and write things up.
Don't resolve arguments on chat. Choose a synchronous medium instead to diffuse tensions.
-
Sprint ceremonies can add several hours of meetings to each of your development cycles. These meetings can impede asynchronous ways of working. There are two alternatives that can significantly reduce the number of meetings you need to run your development process.
Approach 1 - embrace continuous flow.
Work through a tightly prioritised backlog in descending order of priority.
Use throughput and cycle time as measures of productivity, instead of velocity.
Use the sprint only as a common denominator for measurement.
Release often, report regularly, but conduct demos only when you have something substantive to show.
Approach 2 - use the “Shape up” approach
Operate in two-tracks. A small group of people shapes pitches so teams can execute them in six week cycles. They work in parallel with development teams that work on these pitches.
A dev team has full autonomy on how to execute the pitch. They hammer scope to achieve the outcome and report asynchronously using hill charts.
If a team can’t ship in six weeks, work on that pitch stops. This represents a capped downside for the process.
-
Story kick offs and desk checks build quality into the development process. To adapt them to a remote work environment you have two options.
Approach 1 - go fully asynchronous
Align on the definition of ready (DoR) and definition of done (DoD).
Collaborate amongst the three amigos to detail out the story well enough to pre-empt a kick-off.
Queue "ready" stories in advance so developers can pose questions to the three amigos.
Use recorded video in lieu of desk-checks and use standard checklists to guide these recordings.
If you still see a reason to meet, do so, and follow best practice.
Approach 2 - retain the synchronous practices but plan for them
Represent both kick-offs and desk checks on your task board and measure their impact on the workflow.
Ensure that you have enough overlap time to make both sync and async communication productive across roles. Agree team norms such as turnaround times.
-
Pair programming is a highly productive synchronous activity and if your team sees value in coordinating it, you should continue the practice. Here are some ideas to implement it in an async-first team.
Design your work patterns for flexibility so pairing doesn’t create a rigid work schedule. Try the baton-pass pairing routine as a way for developers to start and end their days at times convenient to them.
Use the right pairing tools, otherwise the dev team will struggle to pair efficiently. That in turn can be morale and productivity sapping.
Everything we've discussed thus far about personal discipline becomes even more important. You're now responsible for two people's time.
Be pragmatic. You don't always need to pair. Find ways for people to work solo and to learn from their own mistakes. Consider pairing as a way of having a design or accountability partner even if most of the work is asynchronous.
-
When you avoid big upfront design, you will inevitably design your software in parallel with delivering it. To communicate ideas, and functional or technical design, there are three kinds of documents that come handy.
Idea papers allow you to nurture fresh ideas by articulating them clearly. People can use this as a reference to share feedback and enrich the idea. Decision making is also easier if everyone can understand the idea well.
Feature breakdown documents serve as a single resource to catalogue all information about a feature. As the team enhances the feature, this document becomes a single source of truth about it.
Technical design docs are an efficient way to communicate about software architecture and technical solutions. These docs precede an architectural decision record. They benefit from detail, though brevity is an important consideration too.
-
Adopt a write once, run many times approach to creating onboarding assets. You can avoid redundant, ephemeral conversations this way.
Enrich your FAQs to preserve new hires' "dumb questions budget”.
Use checklists to take away the guesswork from onboarding.
Focus on automation and reuse.
Use containers or scripts to automate the dev environment setup for new hires.
If you have the appetite for it, set up a dev portal to share software templates and to help team members discover APIs, events and shared dev tools.
Assign a buddy for every new hire, so they have a friend to guide them in their initial days.
Use synchronous interactions to build connectedness and camaraderie with new hires.
-
Face to face (F2F) meetings are a special kind of synchronous gathering. We must be thoughtful about the value we seek from such events.
Overcoming time zones is a good reason to travel, but it can’t be the only reason to meet F2F.
There's a significant cost to F2F meetings. Productivity and efficiency aren't big enough reasons to justify this cost.
The true value of F2F, is in building strong, lasting relationships. This is something that can happen remotely, but it takes a long time.
Avoid the trap to avoid "looking productive" and making the office the sole venue for an otherwise vibrant purpose.
Be conscious about building relationships through in-person interactions. This’ll mean setting aside time and discretionary budgets for the purpose.
-
A team handbook helps make information about work explicit to existing and new team members. This is a crucial asset for async-first work.
Focus on writing things up for your team first. Don't worry about organisational knowledge at the start. If you're successful, your handbook can be a blueprint for the company.
Divide your handbook information by project context and project content. Context that lays down how you work together. Content describes what you work on together.
Avoid being too fancy and use the tools your company already provides.
Expect everyone to improve and update the handbook and designate editors on a rotational basis. Start small and iterate on the content and design.
Use the DEEP acronym to remind each other about the triggers for documentation. Printing it on team merchandise is an effective way to make the triggers visible for remote colleagues.
-
Standup meetings for status updates can easily become an asynchronous activity. This frees up a few hours for the team, each development cycle.
Use the signup, tasking and commenting features of your project management tool to make updates continuous.
As an alternative to #1 , automate the standup using tools like Geekbot or Butler.
Avoid making it a one-size-fits-all interaction. For leaders and higher level managers create summarised reports of progress so they don't get overwhelmed.
If you’re leading your team, help everyone make peace with lag. You may need to remind them about their updates at the start, so they get used to the new practice. And stay open to feedback.
-
Frequent retrospectives are an effective way to maintain a positive team environment and a culture of continuous improvement. However, we must approach retrospectives more as a process and not as an event.
Going by the ConveRel quadrants, retros aim for convergence with a group that enjoys a strong relationship. So you can gather input and synthesise them async.
You can choose to asynchronously vote and prioritise issues for discussion, but since this is a short exercise, you may not get much benefit doing so.
Be sure to set up the retrospective environment in advance with all the synthesis in place, so you can run the meeting effectively.
You can use the Mural templates on our companion site to give yourself a head start with setting up the retro environment.
-
Tech huddles are usually ad-hoc meetings, to solve techinical problems or make technical decisions for the project. They can also be scheduled conversations to address a wide array of tech topics that concern the team. To reimagine them for an async-first environment, lead with the following questions.
How much autonomy exists on your teams? Consider a decentralised model of pods to devolve decision making to smaller groups.
How necessary is the “sync up”? If possible, slow down and write things up first and then take it from there.
What's the worst that could happen if people default to action? Adopt a consent-based decision making approach for reversible decisions.
If you have to meet as the last resort, then how can you make that interaction less disruptive, better prepared and more productive? Follow the best practices we’ve learned so far.
And lastly, scheduled huddles aren’t as problematic as the ad-hoc ones. Not only do they serve as a fast-paced triage of topics the team must discuss, but they also serve as a fun, social gathering.
-
Audit trails provide the team to back track from the current state of a project or codebase and understand why things are a certain way. These are the most frequent forms of documentation on a software development team.
Meeting notes. These help you share outcomes of a meeting with the rest of the team, in an easy to consume format.
Business decision records. These documents track the business-driven decisions you make as a team and for the software you’re building.
Architectural decision records. Each time you make a change to the architecture of the system, log the decision in an ADR document. These documents serve as a record of how the software’s architecture has changed with time.
Commit messages. Developers create these each time they make a change to the project. It helps the rest of the team understand how the code has changed and why.
Pull requests. These represent a mechanism to contribute changes to a codebase and to receive feedback about these changes. If you manage these well, they can be a great tool for code reviews and a healthy collaboration culture. Item description
-
To help new developers hit the ground running, and to keep your entire dev team aligned, you need some stable, lightweight documentation.
Clearly state your ways of working, especially how you collaborate in the team, your environments and access control and your project metrics.
Write a sharp README file for each code repository that helps developers start contributing to that codebase in a short time.
Limit your documentation efforts to solve real problems. Where possible, automate documentation using modern tools, so everything's always up-to-date.
Part 2 - Prepare to go async-first
Part 3 - The practitioner’s guide
Part 4 - Async-first leadership
Part 5 - Navigate the pitfalls
Part 6 - Bring it all together
-
As a manager, you are the employee’s bridge to the organisation. To show that the company cares, you must show care as well. Here are the three ideas we explored.
Aim for a 1:5 ratio or less between managers and direct reports. That way managers will have time to spend with their people without oversubscribing themselves.
Run effective 1:1 meetings. Focus these meetings on building relationships, sharing guidance, and offering help. Avoid transactional discussions here.
Share timely, atomic feedback. The radical candour framework is an effective way to do this.
-
Handbooks and documentation are only a part of your company’s knowledge management solution. Holistic knowledge management solutions also help you farm tacit knowledge and build connections between people.
Point to point collaboration tools make teams efficient, but they also lead to knowledge silos.
Over and above team collaboration tools, invest in systems that offer most of the following capabilities.
Serendipitous discovery.
AI assistance.
Reputation patterns.
Means for expression.
Structure, after the fact.
To decide which tools you may need, start with a systems audit. Map your systems across two axes.
Audiences and sources (known or unknown)
Content/ questions/ insights (known or unknown)
Aim to cover all four quadrants of the above matrix and use that to drive decisions about investments in an improved toolset.
Stocks are important for stable knowledge. For emergent practice though, you must also enable flows between people.
Focus not just on the strong ties that exist in the team, but also on weak ties across the organisation and outside. This is where serendipity happens.
Build your handbook, but also implement an internal community platform. This’ll help keep knowledge up to date in your company.
In addition, staff community managers at the level of each community and curators at the organisational level. They add a layer of “sense-making” to your stocks and flows.
-
Tools enable remote and async work. So it’s worth spending some time figuring out which tools you need.
Adopt a “less is more” approach to tool selection. Balance the incremental benefits of introducing new tools with the costs you incur. Onboarding, compliance and the cost of confusion can set you back.
Evaluate tools based on the capabilities you need. Use the must-have, good to have, and optional extras lists to help you think through what your team needs to be effective.
-
Aside from writing, you need three other superpowers to be an async-first knowledge worker.
Distraction blocking helps us work uninterruptedly, so we can immerse ourselves in the work at hand. What do you gain? Deep work and flow.
Reading and comprehension complements a writing culture. There’s no incentive for people to communicate in writing, if no one will read. So we all must build our reading muscles even if we’ve lost touch with the practice.
To work asynchronously, we must learn to work independently as well. This is in line with the “manager of one” philosophy. Self-signup, proactive communication, and defaulting to action are by-products of being able to work independently.
The Covid-19 pandemic forced the knowledge work industry into remote work. Today several companies and teams continue to work remotely, though they still follow office-centric work practices. In this part of the book, I argue that these ways of working must change so we can take advantage of our new, distributed work arrangements.
Now that we understand the need for change and are prepared for some challenges we may face, it’s time to lay down the foundational elements for an async-first way of working. This part of the book addresses the fundamentals you must have in place before you address any of your team’s development, communication and collaboration practices.
It’s time to roll up your sleeves and examine the way you work. Each chapter in this part addresses specific collaboration practices that software development teams follow. You’ll either come away with ideas on how to execute these practices more efficiently with an async-first approach, or how to improve them if they still must remain synchronous.
It makes sense to adopt async-first practices at the individual and team level first. Few teams operate in silos, though. Without effective management and leadership, teams may experience the pressure to regress to old, real-time ways of working. This part of the book describes how you can be a supportive leader and adopt an async mindset in your management style.
-
It’s natural to believe that a “hybrid” work policy where every employee spends a few days remote and a few days in office is a “best of both worlds” approach. In fact, this is the hardest work mode to orchestrate.
If organisations respect people's work preferences, they'll automatically be hybrid. There's no need to make every individual hybrid. This lowers everyone's productivity to the lowest common denominator.
"Forced hybridism" threatens to erode gains in operational efficiency over the last two years, in areas like hiring, staffing, and training.
Forced-hybridism is also a costly move. Employers pay for infrastructure and office space, employees pay with a poorer quality of life and society pays with poorer inclusion, brain drain and environmental impacts.
Many arguments in favour of forced hybridism are weak. They stem from a status-quo bias and a lack of deep thought, rather than from data or research.
When leaders force their view of hybrid-work on employees, the decision may seem asymmetric. There's negligible impact on leaders' work lives but employees pay a disproportionate cost in comparison.
The perception of asymmetry could eventually leave companies vulnerable. Top talent will migrate to employers that afford a flexible workplace.
Instead of forced hybridism employers should consider making the right investments in systems, people's learning, retreats and social events and new ways of working. This'll help them stay ahead of the future-of-work curve.
-
When working apart for long, remote, async-first teams can become victim to some toxic anti-patterns. Here are four major anti-patterns that you must guard against as you transition to a remote native, async-first way of working.
Celebrating long hours and unsustainable pace sets the wrong example amongst people. It’ll eventually burn people out. This benefits no one.
Proximity and visibility bias can force an always on culture. People may feel obliged to be in every meeting, every chat, and every email exchange. This leaves little time for work and erodes the efficiency of our communication systems.
Going async doesn't mean being insensitive and not talking to people when there's a good reason to do so. If anything, when we neglect time sensitive work with a slow, asynchronous back and forth, it can shake people's faith in this way of working.
Async-first isn’t anti-meeting. We must invest effort in better meetings as well. Effective facilitators can help in a big way. Promote effective facilitation by helping people on your team build these skills.
-
A team that’s an “async-island”, is an antipattern that any async-first advocate must avoid, in the long run.
External organisational forces can overwhelm a team that has a vastly unique way of working from the rest of the company.
Async-first and sync-first ways of working need different skills and different mindsets. Very few people can switch between them. This makes rotations and inter-departmental collaboration hard.
If you don't have an organisational default way of working, people will always have to recalibrate themselves based on the team they work in. This makes it difficult to gain fluency, where the way of working becomes second nature.
To protect your team’s way of working and to precipitate change in the rest of the company, we discussed a few strategies.
When you start your journey, enlist support from the entire vertical slice of the company that your team interacts with. This includes managers, execs, stakeholders, and partners.
As you build evidence for the success of the async-first approach, share these stories with departmental colleagues so they can learn from your experience. Use data to tell these stories.
Create a community of practice focussed on effective remote work. This’ll help spread your ideas further than your sphere of influence.
Share tools, templates, and sensible defaults so you can make it easy for others to adopt this new way of working.
Async-first and remote work isn’t without its pitfalls. This part of the book will describe a few common pitfalls in detail, so you can prepare to avoid them.
This is the last part of the book. It’s now time to bring together everything we’ve learned so you can bring an async-first shift to your team and a new mindset to your work.
-
The async-first starter kit is a collection of tools and templates to guide your team through their shift to an async-first way of working. The kit guides you through a five-stage process.
In stage 1, you agree on the goals for this shift and how you’ll celebrate if you achieve those goals.
In stage 2, you’ll gather and tabulate baseline data. This may generate some insights for the team and encourage you to commit to additional goals.
Stage 3 focusses on some fundamental agreements, such as meetings as the last resort, how to use your team’s communication channels and protocols for meetings.
At stage 4 you’ll start acting. First, you’ll defrag your calendars so you can free up contiguous blocks of time for deep work. Next, you’ll identify meetings that you can delete, shorten, or modify.
Finally, in stage 5 you’ll sign up to build different sections of your team handbook and agree on your collaboration guidelines. You’ll also find a list of plays you can implement for the long tail of your async-first shift.
-
In this chapter, we explored five trends that’ll influence the future workplace.
Most knowledge workers want flexibility at work and the number of people who want to work remotely all the time is increasing. Some countries may even grant remote work as a right for employees.
Even in a slowdown there are plenty of jobs for skilled knowledge workers. People with in-demand skills can get the work conditions they demand, and this will only get better with time.
As people have more disposable income, they'd like to improve their lifestyles. Travelling while working, i.e., digital nomadism is no longer a fringe trend. Several countries already support such mobility.
The 40-hour work week may be a relic of the past for knowledge work. The four-day work week movement is gaining steam in some parts of the world with several successful experiments to back it up.
Gen Z will soon be a large part of the workforce. Their values and expectations are already influencing corporations and will undoubtedly also shape the future of work.