

Developers, teams, and businesses of all sizes use Heroku to deploy, manage, and scale apps.
TV news tells us that working from home is the new normal. Or, at least, as normal as life gets right now. Zoom is a household name and ancient jokes about wearing pajamas under the desk are doing the rounds on social media.
But itโs not the same for us developers, right? We were using Slack back when it was called IRC and all we need to do our jobs is a laptop with a decent internet connection.
Maybe. Or maybe not. Successful remote work takes more than just a set of tools. And if your office-based engineering team has gone remote overnight then your biggest risk is getting team communication right.
One of the first things youโll need to consider is when to choose which type of communication. Hereโs what we at Heroku have learned over a decade of running distributed engineering teams.
There are exceptions but most conversations within a distributed engineering team fall into three distinct categories:
If youโre used to working in the same office as your colleagues, your go-to method for each of these may have been to grab a meeting room and whiteboard it out with the people involved.ย
In a remote team, you canโt check whoโs at their desk or even rely on people sticking to roughly the same schedule. And the methods open to you come with a different set of trade-offs.
So, for each of these types of communication, which methods should you use?
Say youโre working with a new API and youโre getting rate limited. You check the docs but thereโs no mention of what the rate limit is.ย
To get the answer you need to ask a simple question. Thereโs no ambiguity and no need for discussion. That answer is a fact. If someone knows it, they can provideย it. If they donโt, they can ignore the question.
That makes this sort of query ideal for real-time chat, such as Slack or Microsoft Teams chat, or even for a workplace social network such as Yammer.
Youโre optimizing for the trade-off between the work required and the opportunity for ambiguity. Where the risk of ambiguity is low, choose the communication method that has the least overhead.
Big conversations, on the other hand, take more effort. Should we use Redis or Kafka to queue inbound data? How should we architect our new product? Emacs or vim? (Only joking, thatโs not a discussion but an assignment at birth.)
Conversations about things that have long-term, larger impacts need:
As such, theyโre not well suited to communication methods that demand an immediate response. They need structure and time.
You might be ready to object because, in your office, the best discussions all happen in real-time around a whiteboard. Hereโs one of the great things about distributed working: it can introduce you to better ways of doing things that youโve been doing for years. After all, who does their best thinking in a badly ventilated meeting room where Jeff is talking over everyone again?
In a distributed team, bigger discussions happen best by email or a similar asynchronous, recorded medium such as the comments on a Jira ticket. Thereโs a little more overhead than jumping in Slack but the long-term benefit is a conversation that unfolds rather than getting lost in the scrollback.
For all the technology at our disposal, there are some situations where good old fashioned face to face communication is the only thing for it.
Learning a new concept from a colleague, trying to uncover a particularly evasive bug, dealing with a personal issue all benefit from the high bandwidth, low ambiguity of in-person communication.
But youโre on lock down. And, besides, the person you need to speak to is 2,000 miles away.
Video calling wonโt be how you conduct most of your communication in a distributed engineering team but it is the method youโll most often use for the really important conversations. That doesnโt mean that the subject matter must be important. Maintaining the human contact in your team is much easier with video calling, even if itโs just to take a break and chat about The Mandalorian.
Video and voice calling require that people break out of what theyโre doing and they take time. So, save them for when no other method will do.
It can be easy to forget that behind the text on the screen is a reasonable person (except Jeff, right?) who has been thrown into remote working and, perhaps, doesnโt know how best to express themselves.
Distributed working is weird if youโre not used to it and it takes intentional effort to do it well. Communication is, probably, the hardest part. Being choosy about how you communicate can both help to smooth over awkwardness and ensure that the whole team understands that their colleagues value their time.
Create your free account to unlock your custom reading experience.