Team Management and Cooperation

Hi, guys! Continuing the theme of the workflow organization, we would like to pay special attention to communication within teams. As you know, Riter provides our users some tools for their interaction during joint work on the tasks. In particular, you can discuss tasks using comments, attach necessary data there, mark unclear requirements, find out what other team members are working on, assign tasks to them, and so on. Nevertheless, Riter is not a complete substitute for existing means of communication, such as email or messengers, which are widely used by development teams. Both using emails and instant messaging serves the common purpose, although in different ways. The success of your work depends on which of them you will use in a particular situation.

Is email outdated?

Nowadays, especially since the appearance of all kinds of slacks, you can often hear the statement that email has finally died and those who use it for business communication are hopeless mastodons who are just about to leave for dinosaurs. And it has already been dying for ten years since the appearance of the "Basecamp". But it is still alive. And all these "mastodons from emails" continue using their outdated means of communication as if nothing has happened. Each time, with a release of a new and extremely convenient communication tool, its creators promise that it will finally put an end to email with a crushing blow. However, years pass, and everything remains unchanged. And there are several reasons for this:

  • Proprietary. Slack, Telegram, Skype, Basecamp and similar products are designed to monopolize your attention and workflow. It is impossible just to replace one of them to an alternative software with keeping the same work processes. If you once choose Slack or Basecamp, you will pay for its usage without possibility to change that or you are risking to lose the whole communication history and be forced to revise your workflow completely. Email, on the contrary, is decentralized and each its particular service can be easily replaced.

  • Personal preferences. Email allows you to configure its filters, labels, processing rules according to your own preferences and other team members are not influenced by your choice. You are the only one who controls these settings. In slack, the configurations are reduced only to the choice of color, the presence of an avatar and decision how frequently you want to receive notifications from all your channels. As a rule, large teams create several channels for different needs to simplify filtering of dialogs, but later they anyway communicate in the first chat, which they find among others.

  • Asynchrony. This is the most important criterion that affects work processes directly. Chats are designed to communicate in real time, so that both of interlocutors stay online to read and answer each other's messages instantly. Such dialogs can last for some hours, interrupting developers from their main work or, conversely, during non-working hours. Email, however, assumes that you formulate your issue completely at once, and does not distract recipients from other activities.

The list can be supplemented with other arguments, but these ones are, in our opinion, the most important advantages of emails before using chats for team communication. Email will never die. It can change beyond recognition, use updated protocols, delivery methods, but it will still be email. With open protocol, distributed and universal. But slack will disappear and its place will be taken by a new "email's killer".

Instant messaging problems

Of course, the foregoing does not mean that email can completely replace chats. Instant messaging can also be used to simplify communication within teams. The main thing is to understand in what situations the chat is reasonable, and when it is better to avoid it in order to keep the work efficiency.

Now, in the era of total remote work, chats are often used as a way of talking to colleagues about some kind of trifles, even if it is a little related to the current project. In this conditions, employees, as a rule, are divided into two types. The first one prefers to follow the conversation just in case of "they can say something important". Another type has an opposite opinion on this matter. These developers do not read common chats in general until you personally ask them about that. They are not distracted by bullshit during work, and become very angry when you invite them to participate in such a discussion. As a result, we have two camps for chat users: the first one is very distracted by them, the second one does not use them as intended. And the benefits of chats for these two groups are minimized.

Nevertheless, as all other rules, this one has an exception. There is a small number of cases when an instant chatting within a team is more profitable than any other means of communication. This happens when a team is small enough. For example, it consists of two or three participants. Maximum of four ones. In other cases, the chat should be treated as a guff in the smoking room or in the kitchen and you should never keep important information or solve work issues there.

Riter development team