Communicating well with your co-workers and managers is supremely important to a software developer, and even more so for the remote one. With a lot more remote workers due to the COVID-19 pandemic, this topic became a lot more relevant.
I’ve seen people hint at this more than a few times over the years, but I didn’t really “get it” until I started working as a fully remote engineer. I also find it important to understand not only what we should be doing to achieve efficient communication, but also why we should be doing those things in those ways.
To me, the single most important thing to keep in mind is that people’s mental resources: time, attention span, etc, like yours, are limited.
That might be obvious, but different management styles might make it seem otherwise – a more hands-on manager might kind of seem like he is acutely aware of what you’re doing all the time, but that is hardly ever the case. Managing styles aside, managers are, after all, humans like the rest of us and have limited time and resources. They can’t possibly have the same insight into each task as the respective engineers working on them.
The corollary to that is that it is your job to keep managers in the loop, providing the right amount of information at the right time through the right channel (text, video call, presentation…). Just like any other skill, this is something you can learn over time.
Similar reasoning applies to co-workers: people are usually deeply involved in whatever it is they’re doing, so they won’t usually know too many details about what you or other co-workers are doing all the time.
A lot of the things you need to do are fairly obvious and well-known: be clear about what you’re saying, keep communicating frequently, etc. Other things aren’t too obvious (at least to me, that is) and are worth sharing in this short blog post.
Don’t write a novel
Reading is hard. People’s availability and attention span vary. Try to get your point across with the least words as possible.
If I’m writing an issue update, pull request, or other technical information, I usually start with a more winding text and then prune as much of it as I can. This can be really simple, like changing “According to #85748, the problem I described started when…” to “The problem began when … (#85748)”.
This can’t be done at the expense of clarity, though. It is preferable to write or say “I think option B is the way to go” than an ambiguous “sounds good”.
Manage expectations
People don’t like to feel disappointed. To avoid unfulfilled expectations, it is your job to make sure those expectations stay realistic – the more so when the task evolves or unravels into something much more complicated than people originally expected.
As we all know, there’s a lot of uncertainty in this job. Something that seems easy might actually be super easy or might be very hard. Unexpected difficulties are expected, and most people are fine with that as long as they also think that those problems are actually problems.
That’s a huge caveat: if you’re unable to convince other people about the seriousness of the unexpected problems you’re facing, you might as well not say anything at all about them. People usually only believe what they understand, and it is your job to properly communicate that to people less involved in the task than you are.
Tailor to the audience
Different people use different lingo to express the same things. Sales people will use different terms than engineering people.
Adjusting your language to the audience isn’t just about replacing technical words with other words, though, but also about cropping the information in the right way.
Excess information that isn’t relevant to the point you want to get across generates noise and confusion. This might be seen as a broader definition of the first topic: if you can manage to get your point across with less information (whatever that is: spreadsheets, images, etc), then that is certainly desirable. If the person you’re talking or presenting to is only interested in 1 of the 3 columns of a spreadsheet, although the other 2 might be insightful to you, you should probably refrain from showing them at that moment.
And that is the note I’m ending this post on. These three things are probably obvious or second nature to a lot of people, but at least to me, it took a few years of remote work to fully appreciate them. Hopefully this post can be helpful to other like-minded developers.