Not a week goes by and another company publishes its commitment to embrace post-pandemic remote work.
“As employers, we have an opportunity to create an even better workplace — one that allows us to be more connected to each other, find more balance between work and home and advance equality — ultimately leading to increased innovation and better business outcomes.” — Salesforce
The overwhelming answer from the tech workforce is that remote work is here to stay. However, we still need to iron out some bits, like difficulties in collaboration and communication.
Remote collaboration and communication are of particular interest to me. People who have worked with me describe me as a natural async communicator. I relished the chance to put this into practice during the pandemic at my own company, so here are the main benefits of asynchronous communication that I like the most.
It may feel counterintuitive at first to communicate in writing, because it’s faster to tell people, for example, in a meeting. However, oral communication is lossier compared to the written one and this becomes clear over time, as the CEO of GitLab puts it well:
“It’s slower than any other option. However, it allows people […] to build upon a change. When they take that extra time, it’s building a foundation for the next thing. I think of it as bricklaying. Every piece of information is a brick. At GitLab, there is a well-structured house […] it has a strong foundation and we can build it very high.” — Sid Sijbrandij, GitLab
Writing things down is a slow process and there’s no going around it. To create a meaningful positive impact, the handbook mindset has to be adopted for more than just technical documentation, to include culture, product, vision and business strategy documents.
Perhaps the most interesting is the value of asynchronous communication for better decision-making. Annie Duke, a Psychology PhD turned international poker player, hints at that in her recent book, How to Decide.
It’s the only repeatable path to learn to make better decisions, by associating a timestamp of a decision with a context (the information we had available at that time) and revising those as things change.
It increases empathy towards ourselves and others because we can evaluate the effort and consideration that went into the decision-making process. I previously wrote about how important it is to have empathy, especially as a leader.
Having traceability for our decision-making and an observable learning process leads to open, fair evaluations of ourselves and others. We expect interpretability, fair and ethical decisions from machines, so it makes sense to require it from ourselves, first.
It’s essential to consider the context of a decision.
What information was available at a certain point in time?
What were the steps to collect and process that information?
How did those steps connect to the final decision?
A written document offers us a glimpse into all of these steps and as a result, we can offer much better-targeted feedback.
If we version decision-making the same way we do with technical documents, we can see why and when a decision needs to be updated, because the context has changed.
Has the context changed?
Have we given the last decision enough time to reveal significant results?
Do we have extra information to justify changing that decision now?
At Touco, I struggled with both “cold-feet” before important decisions, like pivoting our company and the following impatience, waiting for meaningful results to kick in.
One way I dealt with it was to ask my two co-founders to collaborate with me on a written decision journal. It served both as a timestamped breadcrumb guide and a pressure release valve.
How to Decide offers more similar practical tools worth checking out, like the Knowledge Tracker.
We often evaluate ourselves on outcomes only but the reality is that not all good decisions lead to good outcomes. At least half of it is luck…but it doesn’t have to be dumb luck.
Many leaders are praised for quick decision-making, explained as a mysterious trait, often part of that person’s Unique Selling Proposition: gut feeling. There’s nothing wrong with gut feeling and knee-jerk reactions. In fact, it’s useful in a crisis or when it’s telling us not to touch a crawling creature.
However, operating only on opaque gut feeling means that we don’t develop the muscle to make a fair decision next time.
We risk overfitting decision quality to outcome quality, by repeating errors which, thanks to luck, resulted in a good outcome, and avoiding good decisions that didn’t work out for the same reason.
We also can’t teach gut feeling to others. However, we can pass on a repeatable thinking process and combine it with fast learning loops.
One of my serendipitous encounters was with Dr Christian Busch, who rigorously researched the role of luck in business, in his book, The Serendipity Mindset. He talks about the difference between random luck and smart luck. Serendipity is smart luck, or “connecting the dots”.
Timing is a form of serendipity and has been shown to be the most important success factor in startups. The other things I found personally useful to increase my own luck are:
Knowledge, ideally both practical and theoretical, because a set of limited, repeated practical experiences has more bias than a wide range of experiences.
Social capital, meaning access to relevant networks of peers to engage and solicit feedback from, either as mentorship, coaching or sponsorship.
Intentionality and resilience to repeat this process. Intentionality means conscious effort to volunteer information and seek understanding and is double the effort in a remote world. Resilience means energy to pursue learning, despite failure. Success is, ultimately, Intelligence x Serendipity x Energy².
If decision-making feels like navigating a maze, the next time we have to revise a decision or make similar ones, we can follow the previously written traces like breadcrumbs in a labyrinth.
The opposite of decision-making traceability is black box thinking.
“A lot of the stuff you don’t know lives in other people’s heads.” — Annie Duke, How to Decide
Imagine an organisation where there are a few walking “oracles” hoarding ideas and context *in their head*s. When those thinking heads leave, everyone else is left scrambling to piece together the decision maze which led to a particular path/culture/situation. That’s not an easy foundation to build a transparent company culture upon.
One of my friends, who leads teams inside a large startup, told me that this is personified by Brent, in a now-famous book, The Phoenix Project. He puts this in even a more memorable way:
“Those that don’t document a meeting are doomed to repeat it!” — Nick Mullen, Babylon
The volume and complexity of the information we need to process on a daily basis is so great, that we all struggle with cognitive overload, which diminishes our ability to execute safely, reliable and correctly by memory alone.
Information overload is one of the shortcomings of communication in general, whether async or verbal. Our brain is a funnel for information from multiple sources and our mouth is a megaphone which amplifies that communication. We need to apply some filters.
One potential filter is checklists, which are proven to enable a higher standard of baseline performance. It can also help us flash out unknowns by encouraging inquisitiveness and reflection ahead of a task.
That’s why I’m a fan of The Checklist Manifesto.
“Checklists […] remind us of the minimum necessary steps and make them explicit. They not only offer the possibility of verification but also instill a kind of discipline of higher performance.” — Atul Gawande, The Checklist Manifesto
I noticed a clear trend towards checklists and flowcharts in the developer community. Frameworks, languages, principles and practices change at huge speed. Our brains can’t cope with too many long-form texts, so we need more practical formats.
That’s why I started an open-source project (work-in-progress), to benchmark if checklists lead to shorter commit → review → deploy cycles, improved code quality, increased number of potential issues discovered ahead of releases, fewer severe incidents and in general, better knowledge loops in and between teams.
Many companies are wiring this sort of checklists in their DevOps at critical times, for example in Pre-Mortems ahead of risky decisions or blocking releases if some checks haven’t been completed.
Checklists are just a tool. The ultimate goal is not to tick boxes but to create a culture of discipline, high-performance and teamwork. That’s a long-term process and has to become part of a company’s DNA to be appreciated.
Same as other forms of written documentation, they’re slow to create and hard to keep updated so the only realistic way to implement them is through conscious effort and collaboration.
In summary, being able to articulate our communication, decision-making and overall thinking process in writing allows us to:
Increase the feedback quality by allowing targeted feedback.
Speed up learning by enabling fast iterations on top of existing work.
Create openness and transparency by collaborating and sharing information that evolves over time.
Flush out unknowns by encouraging inquisitiveness and reflection.
Win the trust of others by showing the effort we’ve put into a decision.
Gain trust in ourselves by pursuing a process rather than relying on blind luck for good outcomes.
Like everything else, asynchronous communication has pitfalls and trade-offs.
I’ve hinted at some of them here but I’ll write more about ways to mitigate them in an upcoming article.
I’m always keen to get feedback from my industry peers. Feel free to drop a comment or share this article, if you’re keen to make valuable asynchronous communication the norm in your organisation.
The Serendipity Mindset, Christian Busch
The Phoenix Project, Gene Kim & co
The Checklist Manifesto, Atul Gawande
Is Success Luck or Hard-Work?, Veritasium
The Mythos of Model Interpretability, Zachary Lipton
The Single Biggest Reason Why Startups Succeed, Bill Gross