How To Communicate Better on Slack
Written by Adam Blanchard
Asynchronous communication (async comms) is a big and important part of how we work together in Famly Engineering. Simply put, async comms is communication that doesn’t happen in real-time (e.g. in-person, on a video call etc.). Async takes place via many of the written tools we use such as Slack, Jira, Asana, email and so on.
We value being async-by-default which means we should attempt async comms before interrupting someone or booking a meeting. On top of being more efficient, it has further benefits such as keeping decisions and knowledge documented, increasing searchability and improving resilience as Famly grows across different locations and timezones. There are definitely times to use sync communication, such as in strategic and complex discussions, or for more personal sensitive topics.
This blog post will help you level up your async game by sharing a bunch of the top tips and strategies we’ve learned in Engineering at Famly.
Sync communication (i.e. a real-time conversation) is blocking by default. That means, you ask a question or for a decision, and you wait until the person replies. This is often why it feels more efficient or faster to go and talk directly to the person who can “unblock” you. Unfortunately it blocks whatever they were already doing, and if everyone blocked each other every time they felt like they needed an answer on something, the whole workplace would grind to a halt.
Instead, it’s more important to create a working environment which gets blocked less, and an async-by-default approach can get you there.
1. Leading with intent
Leading with intent means you communicate what you intend to do in advance, including any decisions you plan to take, instead of communicating at the time when you need a decision.
For example, let’s say you need to write a weekly update to the rest of the company on the status of a project, but before you send it you need to get feedback from your manager. If you write the draft in private and request feedback when you’re ready to send it, your manager will block you from sending it until they can reply.
Instead, write the draft in advance and share it for feedback with an intent to share it in a reasonable timeframe.
The difference is quite nuanced, so here’s a real example:
Bad, blocking example:
Leading with intent, non-blocking example:
Notice how in the second example, both of you can continue with your work without blocking each other.
2. Urgency indicators
A frustration you may experience when communicating async is when you feel you must wait around for a response. That means if anything feels even slightly urgent, it can feel necessary to go sync straight away. Also, from the angle of the receivers, and as async comms increases, it can feel overwhelming to receive so many messages throughout the day. This is where urgency indicators can help!
The first thing you need to do is set a default expectation for how long async replies should take. We define in our “Flexible Working Policy” that you should expect and respond to messages within one working day by default.
If something does have some urgency (e.g. requires a response as soon as the receiver sees the message), then you should be explicit about that. In the same way, if something really is not urgent, be explicit about that too.
Urgent example:
Non-urgent example:
3. Response-time expectations
The first two tips above are aimed towards the sender, but you can also communicate time expectations as the responder if it’s not clear or they need to be different.
Even if you can’t respond straight away, it’s a great idea to reply with your expectations of when you can. It’s also good to give context (e.g. why you are currently busy) and always give the opportunity for them to respond with clearer expectations in case you misinterpreted the urgency of their request (e.g. asking them to let you know if that won’t work).
While it also takes some time to send responses like this, over time it helps to build a better async culture, since they serve as reminders to people that time and urgency indicators are really helpful to include — hopefully in the first message they send next time!
Remember, async comms happens all over the place. Pull requests being another one. If you need more time before approving something, you could ask for more time with a clear response-time expectation (instead of just leaving the requester hanging):
4. Over-indexing context
Have you ever sent a message in slack and someone instantly asks for more info? To avoid the back-and-forth of async comms, it’s really important to over-index on sending all the context behind your message so others have all the required info to they need to act.
Example missing required context:
A more effective message with lots of context up front:
In this example, Cool Coworker wrote a much more effective message. It had the question at the top so it was easy to scan what it was about. It had a lot more context following it, including a “leading with intent” action and a timeframe for when more help will be needed (to remove their access). Adam had enough context to give a meaningful response. Because he had all the context, he could also provide a much better way to solve the problem 🙌 — bonus win!
5. Pre-empting questions
In a similar vein to over-indexing context, it’s also important to think of all the potentially obvious questions people will first ask when they read your messages, and answer them up front. This also helps avoid the slow back-and-forth trap in async comms.
What would be your first thoughts after reading this message? Maybe which environment they are testing on? Or what actually happens when they click the button? Is it broken for everyone? Have we initiated the incident response process? How do they want someone to help exactly?
When you’re sending a message, you can put yourselves in the shoes of the reader and try and answer some of the obvious first questions up front. Here is a better example:
This message is much better. It includes a very clear request for help on the first line, intent for next steps and includes answers to the potentially obvious questions.
6. If-then responses
Yet another way to help avoid the back-and-forth trap is to give if-then responses up front. A good example is when you’re helping someone debug an issue, both because they can be very blocking problems for people, and the nature of debugging is itself very back-and-forth.
This first example is frustrating and time consuming for everyone involved. It also forces a context switch for Adam every time he hears that the last suggestion didn’t work. Here’s a much better approach:
This time Adam added a bunch of steps to try if the previous ones don’t turn out to be successful. As a bonus, he sets a clear expectation that if it doesn’t go to plan, Cool Coworker can go sync with him and he’ll be available to help — what a friendly and helpful chap!
These are some of the key tips and strategies we’ve learned while becoming more async in Engineering at Famly so far. If you have any other tips, or have different approaches to collaborating in an async way effectively, drop a comment below or reach out to me at ab@famly.co — I’d love to hear about them!
