In our line of work, this is an up-to-date topic not only during the pandemic. However, this will not be a text about applications supporting remote work or facilitating team management – everyone has already mastered these. It will be a text about something which is much more difficult in remote work, i.e. about the human factor – emotions, communication, and relations in a team.
For the last year, my team – much like the rest of the world – has been primarily working remotely, but like many developers implementing projects for foreign clients, we had to learn this art much earlier. Over the years, some of us have been working in our Wrocław office, and others in various places around the world. Hence, we’ve developed our own methods for not only effective work but also for reducing frustration and conflicts. Let's start with the rules that apply to the entire team.
Overcommunication is the key
In asynchronous communication, we always use the overcommunication rule. This means that if I give someone a task that they will start to carry out when, for example, I am already in bed, I do not just send them the task with the information "it's your turn". Instead, I describe everything that may be of use to them and even more – as all the stuff obvious to me will be new to someone who has not been in the project as long as me. It’s always better to write those two more sentences, even if they seem unnecessary than to find ourselves in a situation when someone has to wait 6 hours until I get up to ask me for some detail. This hinders both the work of the said developer and the entire project as well.
The benefit of the doubt
When someone takes over a task from another team member or when we do a code review, i.e. another developer checks if the first one hasn’t made a mistake or overlooked something obvious, the following situation quite often occurs:
The task was complicated, so the developer spent several hours working on it and produced a few lines of code. He/she went through various scenarios, tested all possible options, and chose the best one. There was a problem to be solved, and he/she solved it as was their task. And the person who is only supposed to check if everything is OK (a frequent case with young developers) looks at the code and says that it makes no sense, it should have been done differently, in a simpler way, and “how on earth did you spend so much time on it”? The reviewer doesn't take into account that this obvious answer which immediately occurred to him/her, wasn't the best one at all, and the person who had been working on the problem probably had to discard this very solution right at the beginning. There’s not enough faith in the fellow team member and no assumption that they actually know what they’re doing and have chosen this particular solution for some good reason. He/she thought it over, checked it, tested it. It's easy to criticize someone's hours of work in 5 minutes, but we won't get far with such an attitude.
Of course, it would be ideal if the first developer, when submitting the code for review, mentioned that they also tested three other solutions and this is one the best because of this and that… This would dispel the reviewer’s doubts straight away which brings us right back to overcommunication.
Short messages and perspective
In written communication where emotions are invisible (or somehow hidden), proper perspective and initial assumptions are important. We often write something quickly and laconically in order to give someone a reply and push their work forward, but at the same time to quickly get back to our own tasks, because we are busy ourselves, we’re rushing to a meeting or we are already after working hours. If replying to you is a man or woman a few time zones away, who is just on his/her way to pick up the children from the kindergarten, then they simply have no time for "great to hear from you, we haven't talked for a while". They will focus on giving you an answer that will keep you working – laconic but to the point. And you start to wonder if the person feels offended or irritated by your question, if something’s wrong or if that was maybe a dot of hate. Well no – usually it was just rush, so the basic assumption should always be that the person on the other side has neither bad emotions nor bad intentions.
Clear message and agreement
Sometimes it is easier and faster to clarify matters by calling someone than by sending messages. Even before the pandemic, we often asked if someone had a moment to call us. Now we have an agreement that when someone is available on Slack, we just call them just as if we approached them in the office and asked something. This is obvious, but when making calls, it makes sense to use the camera – it's easier to communicate when you can see somebody’s emotions. It’s 5 minutes of talking instead of 3 hours of typing.
And if a team doesn’t have fixed working hours (like mine) then it is worth informing each other who’s working when. If someone knows that they will be gone between 11 and 12 because they have to take Grandma to the doctor, they let us know, and we include it in our work schedule and don’t call them during this time. If someone’s working some unusual hours this particular week, they inform us exactly when, so as not to hinder the work of others and to facilitate communication.
Remote work gets drastically more difficult when developers working in different time zones have less than four hours of shared working time. It’s difficult to expect someone to call a developer from the other side of the world at 10 p.m. and explain some issues. That’s why – even with all the good intentions and following all the rules – the work often grinds into a halt. So if we have these four hours, we need to plan them well, exchange as much information as possible, and agree with the other party on everything that may be useful later.
Good and bad types of meetings
Let's move on to what a team leader can and shouldn’t do to improve remote work.
Unnecessary meetings that take half a day are the curse of our time. Hence, if the matter isn’t important, we do not organize meetings, if the problem isn’t urgent, we do not call. When someone pulls us away from our work, we need a minimum of 15 minutes to return to the task we were dealing with and focus on it again. Switching from one topic to another takes away a lot of productivity.
But there are also types of meetings, or rather conversations, which I believe – especially during the pandemic – have become important and necessary. These are those conversations that previously happened casually while making coffee, during the break between tasks – a simple chat with a man or woman at the next desk. To me, it’s very important to have close contact with the people I work with and whom I employ – to know what's going on outside of work.
At first glance, such meetings – be it one-on-one or in groups – are useless. However, they maintain personal contacts, and thanks to them I get to know my employees better and they get to know one another, and this, in turn, affects all the points I’ve discussed above. It facilitates communication, builds trust and the conviction that other people know what they are doing and do the best they can at a given moment. And if we know that someone is going through a stressful moment in their life, we won’t be angry at them when they reply with short messages. It’s better to work in a good and harmonious team.
In the office, such conversations happened naturally but during the pandemic, you have to find the time and plan for them, because this is an element that reminds everyone that apart from duties, tasks, and deadlines, there are also human beings on the other side of the screen.
The second type of meetings worth organizing regularly, not only during a pandemic, are strategic meetings. This means: “Let's talk about how the company is doing, what projects we are doing, what we are going to do, what the whole team would like to do, which way to develop”, etc. This builds a sense of community and shared responsibility. It shifts the burden a little from "I" to "we" and allows us to take into account a wider perspective when discussing specific solutions.
