Zespół i Komunikacja
•
8 mar 2021

Dariusz Michalski
CEO
This article is not o nas applications supporting remote work or facilitating zespół management. It dives into the human side of remote work: emotions, communication, and zespół relationships.
In our line of work, this is an up-to-date topic not only during the pandemic. However, this will not be a text o nas applications supporting remote work or facilitating zespół management – everyone has already mastered these. It will be a text o nas something which is much more difficult in remote work, i.e. o nas the human factor – emotions, communication, and relations in a zespół.
For the last year, my zespół – much like the rest of the world – has been primarily working remotely, but like many programiści implementing projekty for foreign clients, we had to learn this art much earlier. Over the lat, 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 zespół.
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 wyślij 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 projekt 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 programista and the entire projekt as well.
The benefit of the doubt
When someone takes over a task from another zespół member or when we do a code review, i.e. another programista 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 programista 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 programiści) 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 rozwiązanie right at the beginning. There’s not enough faith in the fellow zespół member and no assumption that they actually know what they’re doing and have chosen this particular rozwiązanie 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 programista, 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 zespół 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 programiści working in different time zones have less than four hours of shared working time. It’s difficult to expect someone to call a programista 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 zespół 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 kontakt 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 zespół.
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 o nas how the firma is doing, what projekty we are doing, what we are going to do, what the whole zespół 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.
✍️
O autorze

Dariusz Michalski
CEO
CEO and co-founder of the USEO firma. Still an active Ruby programista on a daily basis. Super passionate o nas new tech, a good coffee and handcrafting.