The wrong kind of async
Summary
Not all asynchronous collaboration is productive. There are four ways to get async, wrong.
Doing it without written communication.
Doing it without an explicit process.
Doing it without transparency
Ignoring the tradeoffs.
Fredrik Backman writes beautifully. I’m catching up on a lot of his work, and in one of his books he writes,
“People will always choose a simple lie over a complicated truth because the lie has one unbeatable advantage: the truth always has to stick to what actually happened, whereas the lie just has to be easy to believe.”
As I read those lines, I realised we can say the same about frameworks.
“People will often choose simple shortcuts over a more complex framework because the shortcut has one unbeatable advantage: the framework always has to stay realistic, whereas the shortcut merely has to be easy to implement.”
On some days I reflect on my work to evangelise async-first ways of working and feel rather proud. Lots of people support the idea today, and many are keen to implement these ideas on their teams. But there are other days, when I see how some people are implementing what they think is “async-first”, on their teams, and I notice that it’s not a framework, but a shortcut. I wish I could tell you that these shortcuts work, but no, they don’t. On the days that I encounter these shortcuts, I feel like I’ve unleashed a monster!
No framework is an unqualified good. I took care to list some pitfalls of asynchronicity in my book. But then again, a book can only say so much. For one, we have the constraint of length. If I were to write everything I know in a book, it’d fail every editorial filter. It’d also be rather daunting to read. Second, a book represents a snapshot of an author’s experience and observations from a certain time. Most authors will fine-tune their perspective about their pet topics, even after they’ve published a book. I’m no different.
So, I want to take a fresh stab at “the wrong async”, based on the anti-patterns I’ve observed in recent weeks and months. For those who’ve read my book or plan to read it in the future, I urge you to read the book in line with this article. Before I get into the anti-patterns though, let’s first examine the context of going async.
Context is king
When I started my consulting career, I learned to reach for hammers only when I see a nail, not the other way around. The async-first hammer belongs to the team. A team must employ it when they can associate the framework with the benefits that they seek. So before a team lead announces that they’ll “get rid of all their meetings”, it’s worth asking which of the following benefits your team cares about.
Deep work
A bias for action
Work-life balance
Diversity & inclusion
Better knowledge sharing
Communication practices that scale
Only if one or more of these benefits matter to a team, does going “async-first” make any sense. Recognising these benefits also creates intrinsic motivation for the team to question its practices and own the change.
But motivation alone doesn’t bring change. Change is rarely a straight line from a present state to a future state. There’s inevitably a period of chaos, confusion and disharmony when you change your ways of working. That disruption will often lead to lower productivity. Every team needs space to absorb change, so the team’s stakeholders; the business; must buy into the shift. Otherwise, your shift will fail the moment you encounter delivery pressure.
And last, applying the async-first framework, is more than the shortcut of “let’s stop all meetings from tomorrow”. Every team has practices and rituals they follow because they derive some benefit from them. If you drop synchronous practices without finding asynchronous alternatives that preserve value while eliminating stress, then you’ll struggle to achieve the benefits you’re seeking. Avoid the shallow, simple shortcuts. Embrace the complexity of the framework. With that said, let’s explore some common anti-patterns of going async.
The ingredients for an async-first shift
Async without writing
When you reduce the number of meetings your team has, you need a communication alternative. The most scalable and easy-to-implement alternative is writing. Nothing creates clarity faster on distributed teams, than sharp, well-written documents. I’ve said this before and I’ll say it again. There’s no asynchronous work without writing. It’s the fundamental practice for distributed collaboration.
Videos and voice memos won’t save your cheese. You can use such media to supplement writing, but not as the primary way to communicate. With the tools that most companies have available, writing is easier to produce, easier to tweak, easier to reorganise and easier to argue with, than audio and video.
I understand everyone isn’t a confident writer to begin with. But it’s a skill that we all have loads of experience with, thanks to our educational backgrounds. It’s a matter of honing that skill in a business context and using tools to make us effective.
If you don’t want to write, then don’t go async. You must read and write. Period.
Async without process
“At Atlassian, we’re extremely flexible with where people work. That means we can be somewhat flexible with when they work, but less flexible with how. In other words, we need to understand and validate how to keep our distributed workforce connected and advance how we collaborate.” - 1000 days of distributed work at Atlassian
You have a process, whether or not you document it. I understand that the word “process” gets a bad rap from its Taylorist background. But let’s not throw the baby out with the bathwater. An absence of process creates chaos. New challenges lead to a hyperactive hivemind of emails and text messages. This is worse than the repetitive Zoom-swarming that happens on teams that over-index on real-time collaboration because text messaging and email are slower and in their worst form, can seem like all-day meetings.
When you document your process and follow it week after week, you build muscle memory for it. People don’t have to reimagine their collaboration pattern for every new challenge. You know how to react whenever new work comes your way. Effective processes don’t just create a calm environment, but they also help teams manage themselves.
If you don’t want to define your work processes, don’t go async. You must define and agree on your ways of working. In writing.
Async without transparency
An effective async-first team works in a state of flow, with a low cognitive load. The cognitive load is low because the team makes all its knowledge transparent to each other. Whatever anyone knows, everyone can know. When you practice extreme transparency, people can focus on their current tasks, with the least amount of in-memory information as necessary. They know that when they need more information, they can always access it easily.
You don’t need sophisticated tools for such transparency - just a task board (on Jira, Asana, Trello or whatnot) and a team handbook (on Confluence, Notion, Sites and the like). The task board radiates information about the team’s work - past, present and future. You need no guesswork about accomplishments, work-in-progress or priorities. The team handbook catalogues the team’s knowledge. Whenever someone needs any information related to their work, the team handbook is their first port of call. If they want to share knowledge with others, that too goes into the team handbook.
The alternative is chaos. Teams that rely on meetings for collaboration, at least speak to each other regularly to share status updates and to exchange information. If you reduce your meetings without introducing the right information-sharing platforms, your team will always work in a state of confusion. You’ll create knowledge silos, and no one will ever be sure what the other person is doing.
If you can’t commit to information transparency, don’t go async. For async-first success, you need a task board and a team handbook. At a bare minimum.
Async without conscious tradeoffs
Last but not least, don’t forget that async-first is not async-only. It’s about making conscious tradeoffs when choosing a communication pattern. If you lose the spontaneity, breadth, feeling of connectedness and immediacy of synchronous communication, you must gain the thoughtfulness, depth, focus or future orientation of asynchronous communication.
The balance of values across async and sync communication
“Async, for the sake of async” is destructive. Yes, you can replace meetings with instant messaging and email, but I assure you that such a shift won’t be productive. When chat and email dominate your communication, it’ll be anything but focused, deep and thoughtful. Surely, you don’t want to spend large parts of your day, going back and forth on email and IM, just “talking about tasks”!
When online tools intermediate your team communication, you must agree on the purpose of each channel, the level of detail you’ll employ it for, and how soon people must expect responses from it. And here’s the rub - the faster the response and the shorter the communication, the less suited it’ll be for deep and thoughtful communication. To gain depth, you must sacrifice speed.
The corollary is true as well. Sometimes, “those emails and text messages can be a single meeting”. Instead of going back and forth all day on IM, get into a 15-minute meeting and sort things out. For the soloists on your team, institute office hours - a predictable time, when they’re always available on the same bridge, to help people with their problems. Similarly, instead of triaging incoming tasks using IM or email, organise what Cal Newport calls “docket clearing sessions”. 30 minutes each week, is plenty for most teams to take stock of incoming work. You don’t need depth here. You need breadth. And a synchronous interaction gives you just that.
If you don’t want to give your collaboration choices a serious thought, don’t go async. Async-first teams make meetings the last resort, but they also know when to employ meetings effectively. They also understand that all asynchronous collaboration isn’t equally productive.
Async-first is a simple idea at its core. But it’s not as simple as merely dropping all your meetings on a whim. No change ever comes for free. Async-first comes at a cost too - that of writing, process discipline, transparency and conscious tradeoffs. Teams that avoid these costs when attempting an async-first shift, will most likely face higher costs down the line when it’s time to pay the piper.
And hey, async-first isn’t a one-size-fits-all approach. I wrote a playbook for this way of working, so you can choose techniques that work in your context. If you never read my book, that’s ok too. This website, the async-first starter kit and the method stack will be freely available as long as they exist. Chart your course. Choose your adventure. But beware of the shortcuts! You’ll have a more rewarding experience without them.