Most people working in startups spent their teenage/young adult years on chat: IRC, ICQ, AIM, MSN Messenger, Skype, Campfire, iMessage, Hangout, HipChat, Slack… Name your messaging app, we probably used it.
In the last couple years, Slack blew up and all a sudden a lot of businesses are moving from email to company/project based instant messaging. I hear managers and C level execs tell me how awesome the transition has been. The latency whenever they have a request is greatly reduced, people feel in sync and overall things move faster… I’m more skeptical, the engineer in me experienced first hand the cost of context switching. Shallow tasks can in some cases help move things faster, but in other, they are a total productivity killer. Here is how we’re addressing this issue at Splice.
Async vs sync communication
When working in an organization, there are two main types of communication, the asynchronous communication such as email and the synchronous communication such as walking to someone’s desk or calling them over the phone. It’s usually said that sync communication is more efficient since you get immediate feedback and the cost of that communication is cheap.
The cost of sync communication
Often my work requires “going deep”, holding in my head a virtual world of components and how they interact with each other. Each interaction will cost me X amount of time to rebuild this mental representation of our system. This is true for engineers but also for product and graphic designers. I’m a true believer that taking a bit more time (maybe ~20% more) in the design phase will save you a lot of pains later on. I’m not advocating for a waterfall process I’m just saying that jumping on writing code or designing UI/UX without taking a minute to think about the ramifications is a dangerous thing to do. The problem is that a phone call, a tap on the shoulder or a slack message can ruin a lot of concentration work. Cal Newport talks a lot about the value of deep work in his recent book.
Advantages of sync communication
As mentioned earlier, using sync communication closes the feedback loop faster and that can be extremely valuable when decisions have to be taken quickly. I rarely discuss priorities with my cofounder over email or Slack, it would take much longer than talking on the phone and going quickly back and forth.
The other big advantage of sync communication is that people feel together, there is a sense of community and sense that we are all walking towards the same goal. This “poking” throughout the day is critical to some of us, for instance my cofounder “worries” when the Slack channels are quiet all day, he’s wondering if everything and everybody is alright. You get a sense of community when people share moments together and that’s important to have that happening at work. You cannot and should not expect people to get that feeling only when hanging out after hours. That wouldn’t be fair.
Almost 2 years ago we came up with a new idea: codifying our usage of messaging vs email. Let’s be explicit about what needs to be sync vs async. We came to the conclusion that anything that isn’t critical can wait until the next day and therefore should be sent by email. We also realized that batching emails would be more efficient. Finally, we realized that we spent a lot of time in our standups talking about what we did but it was sometimes hard to parse since not always relevant to the entire team. We therefore introduced a new concept: the end-of-day email also known as the EOD email.
EOD email
The format is straightforward:
- Shipped today (alternatively: worked on today)
- To QA
- Requests / Misc info
Shipped today is what the team should celebrate, things that went out. It helps us focus on delivering value often. It also helps the team stay in sync. Because of the email format, we can easily go back to it later on or respond with questions in an async manner.
The “To QA/review” segment has now been replaced by a QA queue Google Docs spreadsheet where team members enter their PRs to be merged by the QA team and pushed to prod. This was done because we increased our QA bandwidth and development velocity meaning that we didn’t have to have a 24H buffer to QA things. I still think it’s a good practice to note what we expect to be QA’d.
Requests are very important and easily ignored via Slack. Because sync communication is cheap, it’s easy to ask for a lot of things but when you have to batch them, you might realize that they aren’t as important as you thought. Having the requests in an email at the end of the day, reduces the interruptions during the work day and these requests are usually tackled by the team first thing the next morning.
Slack communication
Slack is used for two things: ongoing chatter/community building and urgent requests. The rule is simple, if you aren’t specifically mentioned via a @username or @here, you can safely ignore/read later the content of the chat. @username, DMs or @here are to be used when we know that we might cost context switch to someone but we think that’s critical.
The beauty of this approach is that you can set notifications to come to your phone and you know you will only be notified of important things and go deep when needed without worrying about missing out.
What is your experience with sync vs async communication, any tips or recommendations?
January 18, 2016
