Anti-patterns of asynchronous communication
In a previous post, I wrote about how asynchronous communications beneficial for meaningful decisions, fair evaluations and fast learning.
But like everything else, asynchronous communication has pitfalls and trade-offs worth exploring.
I’ve recently been invited on a CTO Craft panel to talk about Tools & Processes for Effective Technical Documentation. One of the questions I answered was “What are common anti-patterns? When you should not document?”.
Based on that, here are my top DON’Ts of asynchronous communication, with a documentation flavour in mind.
1) Don’t create more cognitive load than needed.
Any new information creates some cognitive load, but we shouldn’t abuse it.
“The downside of asynchronous communication is that it can quickly lead to a backlog of conversations demanding responses, which may exceed the individual’s ability to respond, overwhelming them, and potentially driving them into a state of information overload.” — C. Gunaratne & co
Tailor communication for the relevant audience.
- Is it a monologue? When I prepare for a presentation, I write down my ideas and iterate through them before publishing the final version.
- Is it directed to one individual, a team, multiple teams, the entire company?
- Is the language common knowledge or specific terminology that needs explanatory footnotes?
Trim it and prioritise the ideas and actions at the top.
- Write short, concise and clear sentences.
- Order the most important ideas and actions at the top.
- Use diagrams, flowcharts, images to reduce descriptive words.
- Link to other relevant documents.
Version your async communication.
- We version our source code, so we can version any sort of long-lived document.
- Label the status of the document at the top: Work-in-Progress (WIP), Needs Sign-Off, Version 1, 2… etc.
Use an appropriate format for the type of async communication.
The format readability depends on the type of document. For example, I use Markdown for ADRs (Architecture Decision Records) and PRDs (Product Requirement Documents) also work well.
Markdown is excellent because it offers structure (links, headers, code blocks etc.). The drawback is that the list of supported plugins, like Mermaid for equations and flowcharts, is not consistent across all flavours.
The way I approach writing most documents, technical or otherwise is:
- Start with simple bullet points.
- Convert the bullet points to headers (H1, H2…)
- Add a table of contents at the top (Medium lacks this feature 💡…).
Tip 1: Rewrite the headers to read like book chapters. This is optional, but I like anyone reading the table of contents to understand 80% of what the document is about, at a glance.
Tip 2: Make the document readable on smaller screens. You never know who’s reading it on their phone in the bathroom…
Tip 3: If you think your proposal might not deserve an ADR, take a look at Spotify’s decision-making diagram 🤓. Simple templates are available here.
“Enough small decisions can compound into a future problem that requires a large process or effort (ie. migration). Documenting these decisions doesn’t have to cost much. ADRs can be lightweight.” — Spotify
Make the desired acknowledgement explicit.
- Is the communication uni or bi-directional, i.e. requires a response? Specify the expected response timeframe.
- Where should the acknowledgement come through?
Don’t assume that other people will guess or use your preferred channel of communication, so clarify whether it’s commenting in the same document, an email, a Slack message, a phone call etc.
The more you funnel communication via a small number of channels, the less context switching you create for yourself and others.
2) Don’t under-commit to maintain what you’ve written.
Written documentation feels inefficient, anti-Agile even. One frequent argument is that it’s hard to maintain over time.
“Under-maintained wikis are where documents go to die”. — Popular wisdom
I’d argue that it might be a deeper problem: lack of commitment and accountability. There might be other issues like the lack of prioritisation or miscommunication of value.
Voice your disagreement and then commit
Commitment doesn’t imply the absence of conflict. Conflict can be a destructive force but we shouldn’t strive for zero-conflict workplaces either. Being in an environment where we’re not able to openly voice our disagreements is the opposite of psychological safety and leads to buried feelings that fester and destroy trust. Conflicting situations can be turned into a driving force, and I previously wrote about some ways to do that.
Commitment is also not consensus, as P. Lencioni eloquently explains, in his famous book about five dysfunctions of a team.
“Waiting for everyone on a team to agree intellectually on a decision is a good recipe for mediocrity, delay, and frustration […] Commitment is something of the opposite. It’s about a group of intelligent, driven individuals buying into a decision precisely when they don’t naturally agree. In other words, it’s the ability to defy a lack of consensus.” — P. Lencioni
The solution I found is to approach a tense situation like a collaborative problem-solving negotiation.
Hold yourself and others accountable for keeping documents fresh.
Accountability is universally-desired behaviour. At Touco, we tried our best to instil two-way accountability in our team. It’s not easy and I still don’t know which way is harder…
On one hand, we can’t control other people but we can control ourselves to do what we preach. On the other hand, we need to hold our team accountable for their shortcomings and avoid “correcting” or “improving” things on their behalf.
I recognised this textbook first-time CTO mistake after spending a couple of late nights “fixing” some missed efforts to automate database backups. The signal I sent to my team was not that I cared and I was trying to help but that I didn’t trust them or I thought my work was superior to theirs. My intent was good, but my approach was wrong. It was the direct feedback from my team, although uncomfortable, which made me self-correct.
It doesn’t mean we shouldn’t offer our help in a crisis, but long-term, this is a hugely harmful approach to building high-performing teams. It breeds martyrs and heroes instead.
“When it comes to solving the problem of the hero programmer, your options are limited: either kill the environment that breeds hero programmers, or kill the hero programmer by burnout.” — W. Larson
3) Don’t document when it’s time to experiment.
Even though async communication is not lossy of information, it’s lossy of human bonding and non-verbal cues like facial expressions, tone of voice and other body language signals.
Don’t use async communication as an excuse to avoid talking to your team and your customers.
It’s great to take the time and prepare experiments in writing and write the results of the analysis to keep track of the context and decision-making. In between though, we still need primary data to have meaningful validation and we still need to relate to other humans.
My practical advice is to follow-up a written document with a shorter, oral summary. While I’m a natural async communicator, this isn’t the case with the majority of people. For example, one of my co-founders heavily favours oral communication. The compromise we made was to follow up an entry in our shared decision-making journal with a conversation.
Even better, you can provide that summary while doing something good for your mental health, like…walking. During the pandemic, we started the habit of Walks and Talks, for our 1:1s. That’s audio-only talking on the go while taking the dog out or walking in the park. It’s simple, inexpensive yet very efficient to enhance wellbeing. It helped our team to recover from some of that initial video fatigue. Other companies have since adopted the practice. I’m very keen to experiment more with it in remote working setups.
Resources
- The effects of information overload on online conversation dynamics, C. Gunaratne & co
- Overcoming the Five Dysfunctions of a Team: A Field Guide for Leaders, Managers, and Facilitators, P. Lencioni
- When Should I Write an Architecture Decision Record, Spotify Engineering
- Architecture Decision Records, ADR Github
- What is the best way to write a PRD? With PRD examples from companies you look up to!, Vindhya C.
- High-Performing Teams Need Psychological Safety. Here’s How to Create It, HBR
- An Elegant Puzzle: Systems of Engineering Management, W. Larson
- How to look after your mental health using exercise, Mental Health Foundation
