Seven core habits for remotely working development teams

Original author: Andrew Scott
  • Transfer


I have been with the current company for more than three years. I have been working with my current team for a little over a year, and I was one of those who formed it - this was my first experience in creating a team and communicating in it from scratch.

In addition, the current team is the most geographically dispersed of all that I have worked with, but also the most productive. I do not think that this is a coincidence or just the result of selecting good specialists (but it is worth noting that they are really excellent professionals). We are now scattered across time zones from UTC + 3 to UTC-7. If someone is too lazy to count - this is a difference of 10 hours! We, moreover, mainly work remotely, so many of us do not have a specific workplace and schedule.

From the very beginning it was clear that due to the difference in time zones, we would need to make additional efforts and plan more to cope with the tasks. Below I give seven habits that have taken root in our team, which helped not only achieve the desired results, but also succeed in this.

Translated to Alconost

Excess communication


I'll start, perhaps, with the most important habit - excessive communication. If I were asked what is the difference between ordinary and excessive communication, I would answer like this: “If we were together in the same room, excessive communication could be annoying.”

Redundancy in communication for remote teams is important, because all colleagues must be aware of what is happening.

How to put it into practice?

  • Assume that the interlocutors have no context . Be sure to add the appropriate background to the messages, at your own discretion - links to previous comments, cards, chat chains - so that others quickly understand what they are talking about.
  • Use public and group feeds rather than private messages . If you really need to discuss something with  one colleague, this does not mean that the rest of the new information is useless.
  • Use both private and public chats as a team. For Slack users, I recommend setting up a private channel and an additional public channel, if necessary. I’m less likely to ask a stupid question in a forum with more than 200 smart (and sometimes quick-witted) specialists than in a channel where ten people sit, with whom I communicate every day.
  • Do not worry about what time it is . Provide up-to-date information as quickly as possible. If colleagues want to not be disturbed, they should learn to use features such as Do Not Disturb and Mute. Believe me: if I don’t want to be bothered, they won’t bother me.

Group (pair) programming



I (in real life)

Pair programming is a great thing! I admit: initially I was a little skeptical about this idea, but after numerous successful applications this year, I definitely changed my mind.

I will not go too deep into the topic, but if you are interested, here is a great article about it. I will only mention a few points that I myself try to take into account.

  • Beware of the formation of "microcommands" ‍♀️ . In the case of remote teams, it may seem convenient to work in tandem with those in close time zones. However, this should be avoided for a number of reasons. In the case of the formation of "microcommands" there is a risk that the project will have a combination of knowledge and skills that may seem good to several team members, but overall will be bad.
  • Pair programming is not always a good choice ‍♂️ . If you are bitten by a fly of pair programming, you may get the feeling that it needs to be applied to all tasks - and this may turn out to be a trap: in some cases, working alone is simply more effective, in others you can cool up your own skills trying to solve some then the task yourself. Before deciding on pair programming, you should carefully weigh everything.
  • Try asynchronous operation in pairs. This type of pair programming is associated with the following section. The point is to organize the process so that you can easily transfer the work in progress to a colleague in another time zone and, quite possibly, return to her the next day.



Summarize your work day


This item is pretty close to excessive communication, but it seems to me that it has enough advantages to set aside its own section. The habit of summing up daily is a great way to organize teamwork and keep colleagues in the know.

I do not like to wake up at three in the evening to chat with my European colleagues who are just starting their day, so it turned out to be useful to develop the habit of writing messages with the results of the day, which talk about the current state of affairs. In addition, colleagues, having a summary of the work done in their absence, do not waste time figuring out how things are.

What to include in the daily summary?

  1. Status of work done at the end of the day . Are there any applications? Is there any progress in the design documentation? Indicate only the main points.
  2. Unresolved issues . If you have been trying to solve the current problem all day, haven’t finished and decided to go to bed, tell us about what you’ve done and hope that your colleagues will figure out your task before you wake up tomorrow.
  3. Rejoice more often than done . This is the flip side of the previous paragraph: if at the end of the day you have reason to be happy, share it with the rest. Everyone likes to start the day with good news.

Document workflows


This section actually includes two habits.

  1. All important processes should be well documented and understood by team members.
  2. Review workflows more often and correct them as needed.

The main task of developing clearly defined processes is to provide several team members with the opportunity to work together, replace each other, understand where what is and what needs to be done next.

For example, we practice joint design: more than one person is engaged in designing new functions and receiving feedback - we do it all together, consistently request feedback and make corrections. For effective work on projects, each participant must have a clear idea of ​​what is happening.

Peer education and encouragement


Recently, I read an article after which it dawned on how much mutual learning and encouragement was needed, and not only in remote teams, so I would like to dwell on this.

Mutual learning. We all have different life experiences, different skills and hobbies. Sharing your knowledge with others is a great solution that is beneficial for both sides of the process. And if you notice that a colleague is knowledgeable in the subject you are interested in, ask him to share knowledge.

Reassurance.Sometimes it’s enough to simply add to the PR message that you thought was especially successful, or mention the work of a colleague during a daily meeting or retrospective. Gratitude and appreciation to colleagues for their work can positively affect the team as a whole. I am definitely starting to feel better when a colleague praises me for my work, and I am very happy when I can say the same thing.



Personal acquaintance


I really love remote work: the employer can hire the best specialists from around the world, and those, in turn, can work and live where it is more convenient for them - everyone benefits. Nevertheless, I would still recommend that remote teams get together at least once a year to talk face to face: this allows colleagues to get to know each other in a less business setting and get to know each other better. If you cannot get together officially, look for interesting conferences and think about whether colleagues can come to an informal meeting.

Experiment ️


From my own experience, I can say that in the best teams there are always a lot of curious people who are rarely satisfied with the current state of affairs, no matter what is discussed. One way to improve while working in a team is to experiment with different approaches and processes. To get used to a well-working process and stop experimenting is quite easy and happens as if by itself. If you notice this in your team, look for an outside observer who will be present at your meetings for several days in a row, ask questions and offer various ideas. Sliding into template thinking is a very real situation, so looking from the outside can help.

Not so long ago, I tried several solutions that I liked:

  • Informal morning chatter for coffee .
  • Constantly open team video chat at extraordinary meetings .
  • Change as a Scrum master .

This list is obviously far from exhaustive - so tell us in the comments about the habits that turned out to be useful to your team.

About the translator

Translation of the article was done in Alconost.

Alconost localizes games , applications and sites in 70 languages. Native-language translators, linguistic testing, cloud platform with API, continuous localization, project managers 24/7, any format of string resources.

We also make advertising and training videos - for sites that sell, image, advertising, training, teasers, expliner, trailers for Google Play and the App Store.

→  Read more

Also popular now: