async
8by3: Asyn
c O r how we lear
ned t o stop worrying
and lo ve asyn
chronou s commu
nicatio n.8by3:
Async O r howw
e learne d to s
top wo rrying and l
ove as ynchronousc
ommunica tion.8by3: As
ync Orh ow we lea
rned t o stop
worryin g and l
ove asy nchrono
us comm unicati
on.8by 3: Async Or h
ow we learned to stop
wo rrying and l
ovea
Or how we learned to stop worrying and love asynchronous communication.
alerts
An altering platform is the only system that you want to be interrupted by in real time. Systems like OpsGenie and PagerDuty exist for this exact purpose. They tell you when something is on fire so you can jump and put the fire out. Assuming of course everything is set up appropriately, and you are scheduled to get the particular alert for the particular system. As soon as signal v. noise ratio is off you will start to ignore these alerts.
meetings
Meetings are a valuable tool in an organizations' arsenal, which can be tactically used to solve focused problems. They are perhaps one of the sharpest sticks when wanting to hash out a complex idea, or come to an agreement. Like a sharp stick they should be used sparingly, and not be the default form of communication.
general meetings
For general purpose meetings there are a few steps that will increase their effectiveness and efficiency. A good rule of thumb is to use your camera in any meeting with between two and ten people, more on that later. As is the norm with in person meetings, if you are in one and not the person taking notes then you shouldn't be using your computer.
Agenda: This provides focus and defines the desired outcome for the meeting. An agenda allows people to better prepare in advance, and to know if the meeting was a success. An hour-long meeting without an agenda will typically last the full hour, sometimes longer as there is no clear stopping point. A meeting with a well considered agenda may only last seven minutes if that's how long it takes to satisfy its purpose. In organizations with strong agenda culture it is acceptable to decline a meeting without one, regardless of who has initiated the meeting as its impossible to know if you participating is valuable without knowing what particulars are to be discussed. Notes: If a meeting is held in the woods and no one was taking notes did it really happen? It is tremulously valuable for participants and interested parities to be able to look back and get additional insight into a thought process. All participants reviewing the notes helps ensure nothing important was missed and for a reoccurring meeting its good practice to rotate the note taker. Actions: As meetings are problem-solving opportunities, an ideal outcome in a plan or agreement. Instead of assuming this outcome will organically spread it helps for an individual to be made accountable for a particular result. Antipatterns
- If someone says "sorry, I couldn't find the mute button"; that's a sign they have checked out and either are the wrong audience or possibly the meeting has lost its purpose.
- The outcome of a meeting is another meeting.
- More than ten people sounds more like a presentation, it is hard for ten people to meaningfully participate in a conversation. Are they being invited because they don't want to miss out on an outcome, sounds like you need notes and actions.
presentations
While it is tempting to bring people together in real time to present something, the very nature of a presentation accompanied by a slide deck is an excellent candidate for recording and distribution. Especially in a hybrid environment where one can't assume everyone is going to be at their desk at a particular time of day, expecting a large group to be in sync in inevitably going to inconvenience some. One potential solution would be to send everyone a recording and then host some live Q&A sessions the next day or simply have a chat thread or forum tied to the recording.
stand ups / team syncs
These should be short, ideally a few minutes per person. Traditionally the script was to discuss what you were doing, any blockers, and what you plan to do that day. When everyone was in the office together this made sense, you were actually standing and you didn't have a computer so were all paying attention. When stand ups start to drag people have a tendency to checkout, which undermines the purpose of the meeting. Some teams opt for doing these asynchronously, others cherish the opportunity to regularly catch up with their peers.
one to ones
These are wonderful opportunities to connect with your colleagues. Both informally to meet people across your organization using some sort of random coffee bot and formally as with those between you and your manager. Going outside your normal working space may benefit the experience as it allows you to focus on the conversation instead of your typical working environment. This is especially true if it is hard to resist checking other communication tools. Going for a walk, or if you are worried about a choppy connection or a windy microphone, sitting in a nearby café can increase the value of these one to one conversations. This also affords a healthy break from sitting at your desk for eight hours. Not to mention staring at yourself in a video call for several hours in a day. While it may be counterintuitive, a one to one can be an ideal time to turn your camera off and just focus on the conversation you are having. Especially if you are on the move as attempting the outstretched arm video call can be treacherous.
chat: group messaging / instant messaging
Chat is a powerful tool but can quickly become overwhelming. To Quote 37 signals
group chat all day feels like being in an all-day meeting with random participants and no agenda.
real time
Just because a message is delivered instantly does not mean it should be read or responded to instantly. Having this expectation is a guaranteed productivity and happiness killer as deep work requires focus. Short knee-jerk responses can also make conversations harder to follow and delay clear communication. When communicating asynchronously it helps to front load your messages and provide as much context as possible, this ensures the recipient can write a considered reply in fewer messages which will be easier to follow for anyone else in the channel.
notifications
The only time @here is a good idea is if the building is on fire, notifications are designed to interrupt people, and it is unlikely everyone in any channel needs to be interrupted. An emergency should be handled via Alerts.
knowing what a channel is for
There are a number of existing prefix's used for channel names to make it more clear what a particular channel is for. E.g. if you are looking for help from team BananaRama you can ask in #help-BananaRama instead of #team-BananaRama. This allows the team to self organize and ensure one of their friendly Banana enthusiasts is watching their help channel whilst the rest of the team might have it on mute while they get on with work. While at the same time ensuring their internal team channel can focus on keeping the team ticking along. Using consistent prefixes also helps new people discover channels, while at the same time aiding in knowing where a message should go.
- help- For questions, assistance, and resources on a topic
- lang- Discussion of different languages (Programming or otherwise)
- proj- For collaboration on and discussion about a project
- social- For anything that isn't strictly work related
- team- For internal communication of a single team
- tldr- For high level summaries of an area
- tool- For discussion of a particular tool
dm vs. channel
DMs (direct messages) are intended for private conversations, which can be useful but is rarely the aim of communication at work. A good use of a DM is having a personal conversation with a peer, or a sensitive conversation between a manager and employee. Everything else should go in a channel. The preferred order should be Public Channel, Private Channel, DM. Information gets siloed and potentially lost in DMs, leading to repetition and confusion as well as circumventing efforts to protect peoples time. Just because Jane Smith helped with your Banana woes last month, doesn't mean she's free to do so today, you should ask in their help channel.
notification settings
Most apps will allow you to configure when days and times of day you will get notified, if you choose to use notifications they should only be enabled during your normal working hours. Some may decide to fully disable notifications and instead only check chat apps at set periods in the day.
mobile chat apps
Just because a mobile app exists, doesn't mean you need to use it. Some love the convenience of being able to keep up with work conversations when away from their computers. Though not being able to be away from your computer may be a symptom of an unhealthy chat culture, if something is on fire you should get an alert and not be constantly waiting on your chat app.
wiki
Our wiki is our brain, where we store our memories and our dreams. In addition to a plethora of useful documentation, both general company information such as policies and guides as well as team docs. Our wiki is also used for communicating long form, complex ideas. In the writing and sharing of the following ideas.
pitches
Similar to two pagers of yore although less formal and more iterative; one-pagers?. When there’s a product to be built, or a feature added the conversation can start with a pitch. We use a template though some details, such as “What is out of bounds” might not be immediately apparent and can be added when known. The provides improved communication and transparency across the org which helps us achieve crosscutting initiatives. Engineering can also use the pitch as a starting point to write a more in depth RFC with implementation specific details and always link back to the pitch. If creating a pitch is onerous it is possible you are putting too much detail into it, as it should be a light affair that can be done for any new piece of work. All the essential high level information that would be needed by engineering to actually tackle the problem. Think rough sketch instead of detailed spec.
rfcs (request for comment)
These are where the pitches hit the road, the draft idea starts to get turned into implementation details. Like a pitch, there is a template and like a pitch it is an iterative document. e.g. The FAQ section can only be filled after the RFC has been shared and questions have been asked and addressed. Ideally an RFC will exist for every pitch that has been agreed to be worked on, as it is essentially a continuation of the conversation that a pitch began. The pitch the first draft, the RFC the second and the work itself the final version.
source code in source control (git)
Code communicates through its functions, it's in line comments and its ReadMes. Ideally all three will convey meaning.
readme
Docs close to the code can provide tremendous value in better understanding what a specific app or service is doing. While more complex documents describing end-to-end solutions spanning multiple services are better situated in the WIKI, each repo should describe what it does.
code comments
Not all functions require comments. Linters that require such can be overly dogmatic and lead to filler comments that actually reduce readability. Complex functions, or even complex branching logic that embody intricate business rules may benefit from additional comments.
🏷️ #communication #async