Unlock async communication for engineering teams — Part 2
In this post, we’ll address the ‘bus factor’ and practical steps for creating asynchronous habits. Finally, we’ll be walking the path of creating a value system for async working by adopting a framework to aid in defining why we want to do this and most importantly, create some sticking power.
Encouraging behaviours, why async
Let us begin with an example of the bus factor. How many people leaving your team would impact value delivery? How many would halt support capabilities? This can be a sobering exercise. Sure, teams adapt to change, but wouldn’t it be nice that an additional cognitive load wasn’t placed on colleagues during such a loss? Wouldn’t it be ideal if velocity didn’t drop and your team is just as capable when dealing with incidents?
This is one of an abundant pool of reasons why async for information capture and delivery is great. The higher the velocity an organisation has, the less long-term memory it has by that very nature. Think of this as a sliding window moving forward, but not expanding. We have a remedy for such a symptom, the remedy is to write.
Consider the wisdom of former HP CEO Lew Platt who encapsulates the point beautifully:
If only HP knew what HP knows
Taking Action
Previously, we spoke about enhancing meetings via injecting async tools and processes. In this section we’ll touch on how to be a force for async, getting started, and build the habits that make this a part of your daily toolset.
1) Starting with why
You can be motivated and have the tooling to start async, but none of this will yield value without buy-in from the right people, your team members. Without this, you’re putting the cart before the horse. It’s critical that this happens and everyone sees the value.
To gain buy-in for capturing information which will enable async, we can use Simon Sinek’s Golden Circle model by first defining a ‘Why’ to communicate the purpose and benefits.
A brief example of this for our purposes:
- Why (The Purpose) — This is the reason you’re doing this; it has to mean something for everyone involved. Examples could be, increasing inclusivity, reducing repetition, decreasing knowledge silos, it shouldn’t be just a procedure (ie something you do), but justify something strategic too (a mission to complete). The company behind Wordpress (Automattic) uses both async and the Golden Circle method, their Why is to enable a global talent pool and maintain continuous productivity
- How (The Process) — Highlighting tools and how they’ll be used to enable the Why
- What (The Outcome) — What will the outcomes be, this may be reduction in meeting times, increased innovation, this should form as a single sentence, and have a few lasting, purposeful outcomes. Without outcomes that can be discussed and measured, you’ll won’t have method of knowing if what you’re doing is actually working
2) Get good at writing
The number one tool for transferring information, is written words. In the right medium, a digital document can scale to be read by millions of people over months or years. It can be versioned, edited, revisited, translated, searched and made accessible around the globe in seconds.
I want to highlight that writing is hard. But, it’s the unlocker for making async work. Just like starting at the gym after a long hiatus, it may be difficult at first. But you will get better, it will get easier. If that’s not enough, think about your Why, your purpose in doing this. Is it to empower people who are neurodiverse, non native english speakers, introverted? Remind yourself of Why when you don’t want to write.
With writing or recording, it enables more people to be involved in the conversations, capturing perspectives we would miss otherwise. It’s not just writing too, media recordings get a noteworthy mention as a medium that captures non verbal cues, tonality, and a demonstration of ideas. Whilst writing gets first place, creating media to express information is still on the podium.
3) Kill the mouse
You’re in a meeting and fortunate enough to have two screens, one screen has your meeting, the other Google Docs etc. Unless the session is interactive, you don’t need your mouse, the peripheral is a navigator, we don’t need to navigate. All this will do is welcome distraction via checking email, messages, that unit test that won’t pass, put it out of arm’s reach.
4) Create a hub of information
We need to put this information somewhere, naturally, this depends on tooling options available. What is important though, is agreeing where stuff will live, and how you’ll structure it (How). Some examples include:
- Meeting minutes, the outcomes. Initially, avoid using AI if viable because you won’t have a benchmark for comparison. Afterwards, assess whether tools capture key points and action items more accurately. Are they searchable and summarised? From there your team can make an informed decision
- ADR (Architectural Decision Records), often seen as a challenge for engineering teams to maintain, they give context and save tremendous amount of time reading about the evolution of a service. Experiment, find a system that works for your team, perhaps adding an ADR into the projects directory doesn’t work, and that’s ok, you can just link to the ADR’s in your projects README
- Stakeholder decisions aka business decisions. This is a no brainer, if you don’t have written down what you’re aiming for and agreed timelines, you’re going to get into trouble and create unwarranted pressure. Ever played the Telephone Game? You’re unwittingly playing this if things aren’t recorded
- PRs (if applicable), Placing links to these alongside all the information above creates and effective audit trail, seeing how a change happened relative to a business decision change
- Ideas, Have a great idea? Write it down! Put it in your information hub, enabling your team to review in their own time, the more complex the idea, the more difficult to discuss synchronously, enable thoughtfulness around the idea first before verbally discussing
There’s more to talk about here, but this is a great start, use introspection to decipher what you need to know first, define simple templates, make recording information easy and frictionless.
4) A Mantra
Once you’ve decided what to record (starting small can help) next is actually taking action, we’ve spoken about writing is hard, this is the remembering to record part, here’s some useful tips on ensuring this happens
- Who’s writing — In a meeting / discussion, ask at the start who’s capturing the information? Don’t write this in your Notepad or in a medium that’s local to you, always record in the tool you’ve agreed, else you risk forgetting to transfer
- Repeat — If warranted, at the end of a discussion, the writer should recap what they’ve written in a summarised manner, this may take 30 seconds, and not only is it useful to ensure information is correct but gives everyone a high level recap
- Post it somewhere —If you’ve created a new document and added it to your information hub, consider also posting in a dedicated IM channel for async updates, this gives a timeline of discussion and recordings
5) Respond with a link
Next on building your knowledge hub, If someone asks for information for which you have to explain regardless of communication medium, write it down, send a link. If you commit to doing this, over time you’ll have more context, history, time saving capabilities. It’s an investment that pays dividends.
There’s also the added win, that people don’t receive a slightly different interpretation or recollection of your thoughts and ideas each time you state them.
Conclusion
The path to moving async isn’t easy to follow, however, defining our purpose and commitment to change means we’re starting off strong. We humans are imitation machines, so vote with your actions and people will follow. It’s hard to start, but you’ll be creating a better present and future too.
