A lot of people are taking to remote for the first time because of the pandemic. While doing software engineering remote is well and good enough for most people, it's the communication that they struggle with. If you do not see the other person what techniques can we use to get our thoughts through?

The points in discussion are very valid even for in-person communication. We are just discussing how to make them better in context of Remote.

1. Meetings

The hardest hit of these are meetings. When there is nobody to laugh at the jokes, how do we measure the impact?

1. Make sure you need a meeting

Many meetings happen because they can. If you are not getting feedback from people in the meeting, not allowing them to build off each others ideas, then the meeting could have been an email.

Atlassian has published a guide to check if your meeting is necessary.

2. Make sure all the attendees need to be in the meeting

Many a time we tack on people for meetings, but at the end don't invite the most necessary people. As Julie Zhuo writes in Making of a Manager, if the design team has a meeting to push backward all the dates for engineering team, the result is disharmony. But if representatives from the engineering team themselves are invited and a decision is made with suggestions from both parties, then it gains trust from both departments.

Harvard Business Review has a calculator for finding the cost of each meeting

3. Always write an agenda for your meeting

It might seem wasteful on the part of the manager.

Oh! I'm going to meet them in person in a few hours, I will explain it then.

But do remember that springing surpises on people isn't the best way to get feedback from anyone. Everyone takes some time to actually understand the graphs and bullet points that are spread on a PowerPoint presentation.

If you give people an agenda on what is to be discussed:

• They are aware that this is a meeting they should attend
• Allows people to catch up on what has been discussed even in between action items
• Actually prepare points to discuss.
• A prepared person can beat group-think.

NoteJoy has examples and templates for you to write an effective meeting agenda

3. Make sure results of the meeting are understood for all attendees.

As a meeting host gathering feedback, it is possible that you understand what the results of the meeting are. But if you do not communicate that with the attendees, then the meaning and ownership are lost on them.

• Meeting results are to be actionable.
• Each meeting result has to be under the ownership of a person
• It should be documented through email or any other note service used.

It doesn't have to be immediate. Time can be spent after the meeting to calculate costs of alternatives discussed during the meeting and included in the results to reach an effective solution.

2. Slack/Teams

Or some other software where employees are divided into channels and predominantly text/image based communication happens.

1. Use channels

Channels are very useful for general questions. This is primarily because:

• Anyone can answer your query
• Other people might have same query as yours in the future.
• The project manager can collect common questions and add it to documentation FAQ.

So many companies outright ban personal communication for work and prefer channels for all communication.

Arkency has a guide explaning why their teams are asked to stick to channels

But also know that this is helpful only when the teams are divided into very small channels. Assume the case where an employee wants to discuss if confirmation has to be added in his secuity design. To communicate this in a channel with all employees, they would have to explain the entire context in anticipation that even other employees should 'get' where the alert box is. If it gets too big, no one reads, the only person who could answer in the first place also gets confused. When this happens, you would see that all communication in the channel has been striped down to Can I have a call? which is more harmful that the original intention of the rule.

2. Long form communication

Remote Teams communicate mostly through written text (if you don't then, aspire to communicate through written text). This is because unlike videos, text is indexable and searchable for all the employees. Even if you don't show up during a specific time, you can provide feedback to an RFC or go through all the comments as they happened.

Basecamp Guide to their Internal Communication is a great primer on this.

3. Praise in public, criticise in smaller groups.

Often times we 'see' people only when they make a mistake. Because of the channel rule, this often leads to pointing fingers in a public group. While this is fine, it is a criticism with some feedback, it is still important that it is kept to the people who need to hear it. If you have feedback for a person in the design team, add it to the respective channel, would the others in the company be interested in it? Probably not.

However the opposite holds true when you want to praise an employee for their work. Choose the largest channel where it does not get annoying and offer praise. It inspires other employees to do better and let's project managers, HRs, business executives to notice the employee.

3. Over-communicate

Remember that the CEO cannot see you in the elevator ask you about work. People can forget that you are working there unless you tell them.

4. Intentional Watercooler

Sometimes you can have anyone can join team meetings/watercooler moments to keep your yourself close to your collegues. Remote companies don't have watercoolers, cafeterias or free gyms. To see other employees, to feel part of a company sometimes, it helps to meetup (virtually) in some zoom coffee shop background.

You could also have Basecamp (or similar) software setup to ask all the employees social questions so they can communicate amongst themselves on common interests.

Olark talks about their watercooler zoom chats

Practice Social Distancing and Stay Safe Everyone.