The Remote Journey: references to start

Introduction

I started my professional career in an archipelago and I have been involved in Open Source for years so managing remote software related teams, departments and even organizations has been the default for me. I have been also working as consultant in a remote-friendly environment and now I am working at MBition remotely. I believe I am familiar with many aspect of the The Remote Journey, which is a topic I am interested on beyond my work, since it is tightly related to the way of life I want to live.

Remote work is a fairly mature topic at individual (software development), team and department level. It is maturing at company level too which means that there are already resources in internet that will cover most of the basic questions and topics that most of the companies struggling today with moving from colocated directly to remote-only environments might have.

This forced shift will have a major impact in every aspect of the company, in you as professional and in the way you understand your work, which is why I strongly recommend that you make yourself and your colleagues aware of the challenge and embrace it, which means to me at least two things:

  • Be ready to challenge most of what you currently know about how you work, how your colleagues work.
  • Be open to learn. Read and talk about what you and your colleagues are going through assuming that no, you do not have the situation under control. You will need to learn again what under control means.

The good news is that this worldwide crisis will change the way we all see remote work, hopefully for the better.

The Remote Journey

The journey from being co-located to a remote-only environment has different stages. There is no agreement on how to name them but in general, I will define them in the following way:

  • Co-located: teams/departments are located in the same physical location (office).
  • Distributed: teams/departments are located in different physical locations (office).
  • Remote-friendly: the workforce of the organization can work at a different location than the office part of the time. A mature remote-firnedly environment has a minority but significant part of the workforce working remotely and coming to the office frequently. Usually these workers are related with sales, support, business development… When it comes to product development or services, those remoters are senior professionals with wide experience in remote working so they can overcome the technical, process and cultural gaps they face on daily basis due to living in a colocated culture.
  • Remote-first: most of the workforce works remotely. The office is usually reduced to specific areas of the company like labs, administration, HR, junior developers… Mature remote-first environments usually have their workforce distributed across different time-zones/countries.
  • Remote-only: there is no office or when there is, working from it is voluntary. Employees are supposed to work from home/coworkings, including supporting services and departments like admin, HR, etc.

You can read a little about these definitions here:

There is one undeniable fact though, remote-only organizations not just exists, they are successful. In my opinion, it is up to each organization how they want to transit through this journey and which stage is their target. Obviously the current crisis has left many companies with no choice but to jump most stages and go directly to becoming a remote-only organization for a while, but still they can learn from other people journeys. There are plenty of additional articles about the different stages and how routines, processes, methodologies, performance, evaluations, etc. are affected at every level (individual, team, dept. and organization). They should be easier to find now that you know some of the nomenclature.

Team ceremonies need to adapt

It is my belief that in general, habits change mindsets instead of the other way around. When walking through The Remote Journey together with teams and organizations, I put emphasis in the ceremonies as a way to drive the needed change at every level: personal, team, department and organization. If you successfully adapt the ceremonies, your are in a great position to modify people’s habits.

Personal ceremonies are that, personal. I will not get into them. There is plenty of literature in internet about how to face remote work, the advantages, the challenges and how to approach them. I have my own routines. They are not static although some of them have been with me for some time now. Some have been affected due to the confinement state we are in right now in Spain so I am adapting them to evaluate how they work. My advice in this regard is that you read about other people routines, identify yours, track them and experiment to find the right combination. Again, assume they will evolve over time.

I have written in the past several articles about team ceremonies. These articles have helped me to explain certain basic topics. You will need to find the routines that work for you and your colleagues though, in the same way that it happens at individual level. The articles were written thinking mostly about team leads at any level but hopefully there is plenty of useful stuff for team members too:

  • Working in distributed / remote environments 0: presentation.  Motivations, introductions and some definitions. The article includes the link to the rest of the series.
  • Working in distributed / remote environments 1: daily short meetings. Tips and recommendations about adapting the team daily meeting that is so popular on colocated environments.
  • Working in distributed / remote environments 2: the calendar tool. Comments about the increase of relevance for any team that the calendar has in remote environments together with some tips on how to use it.
  • Working in distributed / remote environments 3: weekly meetings (I) and (II). Teams meetings are an essential ceremony to drive change, detect issues early, solve conflicts. They are essential in remote environments. These two articles provide an overview of how relevant they are, why and how to adapt them to the remote nature of the team.
  • Working in distributed / remote environments 4: one on ones (1:1s). in co-located environments, 1:1s are not perceived as a priority by many. Only when the organization grows beyond certain point, this ceremony gets the attention that in my opinion it deserves. In remote environments you cannot wait to get “big enough”. The nature of the work environment force you to establish proactive measures to align, define expectation based on company, department, team and individual goals and evaluate, together with the workforce, progress. The articles provide tips to adapt 1:1s to a remote environment.

You will see that in the articles I use the term distributed and remote environments (DRE) to avoid referring to the different stages of the journey. This is for simplicity. Ceremonies might slightly change depending on the stage the organization is at.

Companies

It is always good to have references, right?

Remote-first and specially remote-only companies need to pay an extraordinary amount of attention to company culture. They usually provide plenty of resources to their employees about this topic. These organizations start hiring experienced remoters at first but as they grow, they realize they need to educate their workforce in remote working, which requires the development of contents. These two links might be a good starting point to find the right companies, what are they doing and why:

  • FlexJobs is an online job board specialised in remote work. They publish the main list of companies walking through their Remote Journey regularly.
  • If you are focusing in tech companies culture, you probably will prefer this article.

Reports about remote work

There are three interesting reports I recommend to read if you like the remote work topic:

I have used them in the past to open conversations about this topic with managers and HR departments, for instance.

Books

I have to admit that I haven’t found yet THE book about the topic, and I have been searching for years. This is the one I recommend:

  • Remote. Office Not Required. It is from 2013 but still (sadly) the best. It is based on the experience of 37signals (now Basecamp). Their authors have accumulated an extensive experience in remote organization since then.

If you are not into buying books (what?), this is an online free book written by Zapier, a popular company in this field.

Social media

  • Twitter: follow the hashtags #remotework #workfromhome . Besides plenty of advertisements from coworkings, you will find useful resources once in a while as well as blog posts.
  • Other social media references: those of you interested in digital nomads or digital travelers, can follow #digitalnomad hashtag on Twitter. I joined some time ago the Digital Nomads Telegram channel.

Events

There are really good ones out there to learn about this topic:

  • The Remote Work Summit: a remote event with many interesting talks and material. You can get free passes to some content and online talks.
  • Nomad City: this event takes place in Gran Canaria, Spain (in English). It is a great one to meet digital nomads, digital travelers and remote workers as well as remote organizations leaders.
  • CoworkingEurope: it is not directly related with remote work but with flexible working spaces, but you can find useful references to companies and processes to follow from there. I have worked in coworking spaces at different locations around Europe. They are a great source of remote work knowledge.
  • I have been the last couple of years trying to join the Nomad Cruise. Let’s see if this year…

Summary

In my experience, going from colocated to remote-only environments changes way more things that you can expect at first. Keeping high levels of efficiency, alignment and workforce satisfaction requires time and effort. Do not underestimate them. The good news is that although not at the speed this crisis is forcing many to do, plenty of people and tech organizations have experienced such transition. Some have published lots of contents about their experiences moving through The Remote Journey or living and growing at a specific stage. Look for those content in internet. Hopefully they are easier to find after reading this article.

A single man experience is very limited though. You probably have experience too. Please share it as well as links to further content.

Nuevo grupo Meetup en San Miguel de La Palma, Islas Canarias, España

Una de las principales razones para unirme a Codethink era la posibilidad de trabajar en remoto desde mi casa en La Palma, Islas Canarias, España. Desgraciadamente, a los pocos meses de comenzar en esta empresa me di cuenta de que mi agenda de viajes era incompatible con vivir allí. El deficiente número de conexiones internacionales y la nula disponibilidad de una conexión directa al aeropuerto de Tenerife Sur hacían mis viajes complejos. Tampoco había internet lo suficientemente bueno por aquel entonces. De modo que tuve que elegir entre mudarme a una de las islas mayores o buscar otra localización. Acabé eligiendo Málaga, donde ya había vivido con anterioridad.

Sigo visitando La Palma con frecuencia. Cuando la actividad de la empresa baja trabajo en remoto desde aquí. El pasado año por fin llegó la fibra óptica a mi casa. La cobertura de esta tecnología está aumentando poco a poco en la isla. Aún no existen espacios coworking pero el movimiento de nómadas digitales en otras islas está creciendo tanto que espero que pronto llegue a La Palma. Esta isla tiene tanto que ofrecer…

Pero para llegar ahí hay que tener ciertos deberes hechos. El primero de ellos es crear una comunidad de profesionales y aposionados por la tecnología que vivan en la isla o la visiten frecuentemente. Sólo así podremos dar otros pasos para atraer a visitantes que quieran quedarse aquí unas semanas, mientras trabajan.

Así que despues de darle vueltas durante meses y diferentes conversaciones con amigos, me decidí a lanzar un grupo Meetup en La Palma, puesto que no existen precedentes en funcionamiento.

El nuevo grupo se llama San Miguel de La Palma tech lovers

La Palma se confunde habitualmente con Las Palmas, la capital de la isla de Gran Canaria y la ciudad más grande del archipiélago canario, de modo que he usado el nombre oficial completo de la isla para la denominación del grupo. Espero así evitar malentendidos entre quienes no conocen nuestra geografía.

Carezco de experiencia previa en la organización de grupos de Meetup pero sí en la organización de eventos technológicos de diversa escala, así que espero poder llevar adelante la iniciativa haciendo sentir a los interesados bienvenidos, promoviendo la organización de eventos así como la delegación en un futuro próximo de todas las responsabilidades en aquellos más entusiastas y eficientes. Esto debe ser una acción colectiva para tener éxito.

La Palma cuenta con una nutrida comunidad alemana así como de países como Holanda o Austria de modo que el grupo será multilingüe, lo que dificultará su gestión. Asimismo, como nuestro público objetivo es reducido en número y de intereses dispersos, debemos abarcar inicialmente diferentes temas, lo que incrementa aún más las dificultades de tener éxito.

Espero en cualquier caso que podamos construir una comunidad activa de tech lovers sobre la base de temas como el trabajo remoto, el software libre, herramienas web o marketing digital, procesos de trabajo modernos, etc. Será todo un reto. El planteamiento inicial es complementar las charlas y workshops con actividades al aire libre como el senderismo o la bici de montaña o astroturismo, tan populares en esta isla.

Únete al grupo. 

La constitución del grupo es solo el primer paso de un excitante viaje que vamos a disfrutar. Próximamente comenzaremos la organización de nuestra primera actividad. Estate atento.

Working in distributed / remote environments 4: one on ones (1:1s)

An important part of any (people) manager’s work is to evaluate how things are going for your team members, the people under your responsibility. When managing distributed or remote teams, the one on ones (1:1) become even more relevant than in collocated environments. In extreme cases, they represent the only opportunity a manager to have an honest conversation with a member of your team.

The older I get, the more relevance I provide to 1:1s. I have found myself in several occasions feeling that my manager did not paid enough attention to me, to the problems myself or my department or team were going through, that affected my motivation, the project I was working on or the organization as a whole. If is not a fun feeling, specially in remote environments, where isolation plays against you. In all cases, there was a common factor: 1:1s did not work well.

Whenever I can, I like to have short but frequent 1:1 with my team members. My preferred option is a weekly 25 minutes meeting through video chat, at the beginning of the day. I try to avoid 1:1s late in the afternoons, depending on time zones. This is tough to achieve when working with Asians (I am located in CET/WET), but it is worth making the effort.

Why weekly 1:1s

A significant number of people tend to dislike such frequent meetings initially, specially when working remotely remote. In my experience, it is often underestimated how important it is to have a healthy channel with your manager, specially when times get rough for whatever reason: personal reasons, due to frictions with colleagues, workload peaks, changes within the organization, strategy shifts, etc.

If you experience such resistance, I recommend you to invest some time early on to justify why you will schedule these weekly 1:1s. Do not take for granted they will agree with them. I provide the following arguments:

  • If I am the new guy, I need to learn about how things work so I need help. Having frequent meetings the first couple of months will help me to shorten my on-boarding process.
  • If you are trying to push changes, you want your direct reports to participate in the decision making process. Use these meetings to get feedback from them.
  • If anybody under your direct responsibility just joined the team, you want to make sure their landing process is smooth, specially if they manage a team themselves.

There are two additional points that help to overcome significant resistance to have weekly 1:1s:

  1. When there is no relevant topic to talk about or the team is experiencing a working peak, the meeting can be skipped if there is a common agreement. I rarely skip two 1:1s in a row though.
  2. These meetings are primarily to deal with people management topics, not execution topics.

In most cases, if you have regular performance evaluations, there are always topics to go over during these 25 minutes slots, that might help to develop your colleagues professional career and performance. As a manager, it is a great learning experience too.

There is a special case I try to pay special attention to. There are times in which a member of your team is already overloaded with too many meetings. Your priority then is to offload that person and clear her agenda. 1:1s become then the desired useful tool. The same principle applies to you. If you perceive the 1:1 with your manager as inopportune, you might need to take a closer look at your agenda. They never are, or should be.

Ground rules on 1:1s

Before the first 1:1 with a member of my team, I prepare a shared document including the most important ground rules for the meeting. Most  ground rules are generic so I will focus on those influenced by the special nature of a distributed or remote environment (D.R.E.):

  • Meeting goal: write down clearly the meeting goals and priorities. I recommend to put people management topics first and, only when those are covered or there is none, move on onto other kind of topics. In the absence of face to face interactions with her colleagues, other managers or yourself, these kind of meetings might be the only chance to deal with people management topics a person might have in your organization.
  • Use corporate approved channels only: this might sound like an obvious advice but there are occasions where it might become a topic>
    • I have found many engineers, specially in the Open Source space, unhappy with using proprietary tools or tools that imply the installation of an application or a plug-in that track data from their machines. This specially sensitive for contractors. Be sensitive with this case if you can.
    • When working in Open Source projects, having a clear separation between what is or is not confidential might not be easy. Confidential information should flow in corporate approved channels only. 1:1s should be consider as such so the default video chat tool might not meet legal requirements in this regard.
  • Define the process to change the schedule of the meetings: the idea is to be flexible about when to meet but strict about how the process of changing the schedule of the meeting should be done, specially when it comes to notify changes in advance. Both parties need to consider how difficult it is to manage agendas when working in distributed environments where people is located in a a wide range of time zones.
  • Start on time: add this explicitly along with how to communicate that you will be late. Remember that if people around you systematically joins late, you will end up reproducing such behaviour. This is a hard personal battle to fight.
    • What has worked for me in the past with people that systematically joins late is to agree to make a note in the shared document when your counterpart or yourself arrive late. In the performance evaluation, when you find several of these notes, the point become a topic as something to pay attention to in the coming evaluation period.
    • The toughest situation comes when executives or customers are frequently late, specially when they are not remote. Do not let the situation get into a point in which you become passive aggressive about it. If you give up with them, you will end up giving up with your team too. Make it a point.
  • Describe what is the shared document for and how to use it: I will come to this later.
  • Add links to the description of key processes and HR documentation: mature companies in distributed environments tend to have well defined written processes. The escalation process is just an example. I like to explain it so the other person understand what will it happen when he request you to escalate a topic.
  • Add the contact information of the participants: I find it very handy.

The shared 1:1 document

The mission of this document is to track those conversation points that any of the participants consider relevant enough. Every time I make sure we both agree with the written text. This is extremely important to me. If there is no agreement, we work on the redaction of the text until we do. I there is no possibility to reach an agreement, both entries, mine and hers should be included.

In my experience, the shared document only works well if it is confidential.

The goal is to reflect when a common understanding has been reached and, if it hasn’t, where is the discrepancy. By default, I suggest to track at least the following topics in the shared document:

  • Agenda: during the week I introduce an entry in the document for every topic I want to raise in the meeting, if there is time. Sometimes there is no time so adding some description of the topic prevent you from having a additional meeting to deal with them. It also helps me as a self note. I tend to easily forget the topics I want to raise during these meetings, specially when I have several with different people during the week, or they are bi-weekly instead of weekly.
  • Escalations: when for whatever reason I have to escalate a point, I make sure it is written down in the document, in agreement the other person. This is very helpful when the escalation process or the resolution takes some time.
  • ToDos: sometimes the outcome of a conversation is a task. I keep track of them and who is assigned to.
  • Points related with the performance evaluation process: these points should only be written down under agreement.
  • Outcome of interesting conversations for one of both parties.

Any other topic can be translated to the document if any party wants to. My 1:1 shared documents frequently have the following sections:

  1. Document title: 1:1 (name surname):Agustín B.B. (this helps me to find the document easily.
  2. Contact info of both parties.
  3. Index
  4. Entry for each meeting with the following heading: Meeting #. Weekday YYYY/MM/DD
    1. Closed ToDos (on this week)
    2. Agenda items
    3. Open ToDos

Some other tips I recommend you to consider when it comes to using the document are:

  • Be short and accurate. This is not about tracking everything. It is not about taking minutes but about sharing a common understanding and agreeing on the outcomes.
  • Provide context. This document is meant to be consulted several times per year, like during performance reviews, for instance.
  • Although the document is confidential, write as if it is not. This is a general rule, in my opinion, to every communication.

Meeting how-to

I always start the meeting asking the person on the screen if there is any point she wants to raise. If an additional meeting is needed to go over the agenda, it should be because there was no chance to go over my points.

In my experience people with none or little experience in distributed or remote environments tend to avoid raising topics at the very beginning of the conversation. Being direct, adapted to the environment, takes some time. It is a learning process we all have gone through. If that is the case, I ask general questions about how is she doing. If nothing is raised, I like to check a couple more times during the meeting.

Only if there is time left after people management topics have been discussed, I introduce execution related topics. In any case, I like to dedicate some minutes to work unrelated topics, at the beginning or the end of the meeting depending on the agenda.

I like to configure the calendar to get a notification in my screen 5 and 1 min before the end of the meeting so I avoid cutting down the conversation abruptly. It is so easy to loose track of time…

Some additional points to consider

Do not forget about the intrinsic limitations of a communication through video chat, specially when feelings are involved. Compared to a face to face conversations, this is a serious handicap you will have to overcome as manager. Creating the right atmosphere during the good times will help you a lot when rougher times arrive, and they will.

These meetings might be the only chance for your counterpart to “talk to” or get “first hand information from” the organization. The impact of your words might get magnified by these two circumstances.

Since the nature of the relations between peers is different in remote environments than in collocated ones, managers has a higher chance to get “caught by surprise” during the one on ones by a problem, complain or a demand you had no previous information of.  If that is the case, be transparent about it and ask for some time to digest the information and provide a credible answer. Schedule another meeting if necessary. There is no award for providing a quick answer.

Do not underestimate the language barrier. It is already hard enough to talk with a manager openly through a screen about a sensitive topic. Add the fact that you have to do it in a language other than your mother tongue and you will soon realise that the shared document might work as a great ally. Cultural barriers are also higher to overcome in remote environments, as I have mentioned in previous posts of this series.

Conclusions

1:1 meetings are an essential “resource” for any manager. As expected, the remote or distributed nature of a working environment has a significant impact on this “tool” which makes it harder to master, at least in my opinion.

I prefer to have frequent and short check points than infrequent and long meetings. I also prefer to schedule an additional meeting than overrun the current one, since you loose very little time in joining/dropping from a meeting when working remotely. This might not be the case in distributed environments.

I like to create, pay attention to and put effort in translating the outcomes of interesting conversations into a shared and confidential document, keeping in mind that 1:1s are above all, about having an honest, transparent and direct conversations. Having them through internet makes the communication tougher which requires a higher doses of experience from any manager to make them meaningful, specially during stormy weather.

Working in distributed / remote environments 1: daily short meetings.

Agile establishes conversations as one key principle. The set up in those companies that follow agile methodologies are designed to maximise the interaction among developers and other people involved in product or service development. When working in distributed environments, the need to have those conversations does not change, but since the environment is significantly different, the required set up must adapt which affects to processes and practices. An immediate question comes to mind…

Should we do stand-ups?

My recommendation is to not have stand-ups. Instead, substitute them for a different type of meeting, with a slightly different goal.

The new meeting

The name

Let me start by the name. I like to avoid calling these meetings stand-ups to minimise the association with what most agile methodologies propose. Different goals, different set up, different dynamics… different name.

These new meetings I have run in the past, have been heavily determined by the availability of the participants (time zones, productivity peaks of each participant, breakfast habits depending on participants culture, etc), the set up (partial or fully remote, for instance), the company culture, the nature of the team (with fixed or variable/flexible composition, with the participation or not of stakeholders, etc), the room I have as manager to propose these kind of actions, etc. I have used several different names like sync-up, fast-track… meeting.

I really do not care about how to call it as long as we do not use the word “stand-up” to avoid a direct association to the agile ceremony.

Mandatory?

Nowadays it is common among distributed or remote teams that most developers agree on having short, daily meetings, but there used to be a time in which I faced strong opposition. Back then and today, I tend to avoid making them mandatory. I promote them by example instead. In my experience, this is one of those topics where peer pressure works better than top-down or a general policy approach, specially when senior developers, reluctant to participate, are involved.

The video chat tool

There used to be a time in which finding video chat solutions that worked on Linux was the main challenge, whici was the excuse to push back on these kind of meetings for many. Phones/Android has come to my rescue many times in the past. Hangouts were my preferred option for a long time. Although now there is a wide variety of options that works on Linux, in combination with the Google Calendar, Hangouts (now Meet) is still my favourite.

As manager, I have faced several obstacles with the video chat set up that I have had to overcome.

  • Technical limitations: I named the lack of solutions for Linux during a long time. Another challenges has their origin in the limitations employees face on the applications they can install on their machines. This is becoming less of a problem nowadays since more and more companies are understanding how important it is to provide at least one on-desk video chat solution. When working in environments where people from different organizations participate like consortiums, you end up with several video-chat solutions installed. Configure each one of them so they do not collide, which can become a challenge. Again, Android has come to my rescue a few times in such situations.
  • Legal considerations: legal restrictions have to be considered in every case. Using freemium services, for instance, or free accounts of commercial video conferencing service providers for internal topics is unacceptable in my opinion. Convenience has limitations. Having managed corporate teams that work in the open for some years now have made me familiar with this issue early-on. An “open by default” policy helps to overcome many of these challenges but any team needs a channel that meets corporate standards when discussing through video chat internal topics, no matter if you the team is working in an Open Source project, a standard company or a consortium.
  • Business considerations: GitHub has been recently bought by Microsoft. For those who compete against Microsoft in a specific market, or are providers of those companies who do, the purchase might bring challenges. The same concept applies to the use of video-chat tools. Google Hangout or Skype, for instance, might be great but not compatible with the activity your company develop for a variety of reasons. This factor needs to be considered when choosing a video-chat tool.
  • Religions: we all have prejudices/biases. Very frequently engineers install in their machines all kind of programs downloaded from a variety of sources to do their job, but they refuse to install a plug-in from a specific vendor to use a specific video conferencing option. Most sales people I have worked with are devoted members of the “Apple Religion“. Many designers are so used to paying for their tools that they become suspicious when an Open Source tool is offered to them with little or no cost at all. I am a Firefox user, I dislike solutions that requires a specific browser. As irrational that these and similar examples might sound when it comes to choosing a video chat tool, I tend to put effort in satisfying team members biases as long as no freemium services for company meetings are used and there is an available option for Linux users.

I am currently using the following tools on regular basis:

  • appear.in for BuildStream project (paid account).
  • Hangout/Meet since Codethink, the company I work with, uses some of the Google services.
  • Zoom for Linux Foundation stuff, since I represent Codethink in that consortium.
  • Skype for conference calls or regular phone calls.
  • Onconference for some meetings at Codethink.
    • People who work on the road, specially sales people, tend to prefer the phone over video. For these cases, where some people join through phone and some through video chat, there are solutions out there that work very well so you do not need to choose between one or the other way to connect. You have both.

The main goal is to have productive meetings where everybody joins because they feel that is important, without you as manager having to worry about legal issues. In general, I think that the tool should not get in your way as manager. Nowadays there are plenty of good enough options. Try several options before sticking with one and be ready to change it and have more than one.

Where?

One of the ideas I like about agile is the co-location concept when it comes to the office set up. The best way to translate some of the benefits that such agile practice offer into distributed and remote environments (DRE) is to join the meetings from your desk. It reduces the preparation time and the overhead associated to meeting rooms reservations.

Even if part of the team is at the same office, my recommendation is that everybody live the same experience during a meeting. Use your laptop or PC and get a headset. Mute yourself when you are not speaking, raise the gain of your mic so you can whisper and be perfectly heard, which helps to not disturb those colleagues around you, and enjoy the ride.

When working from home, I recommend to use headsets too, so people hear you with no echo, your dog does not become a participant, etc. I do not always follow this last advice because my current set up at home is a good one. I should anyway.

Meeting goals and dynamics

Duration, start and finish

Due to the nature of the channel used, short, daily meetings will need to be slightly more structured than stand-ups, which normally increases their duration. Try not to pass the 15 minutes mark including the “connection time”. It seems hard at the beginning but it is perfectly doable.

Due to the lack of face to face interactions on regular basis, short, daily meetings become essential for those working on DRE. While people connect, it is a good time to chitchat with your colleagues. Providing those initial 2-3 minutes before starting is frequently (not always) a good thing. Somebody got a haircut, the weather at somebody’s place is particularly sunny, a team member has a new banner at his office, it is Monday morning and one participant joins after her vacation… these are quality moments for any distributed/remote team. Honour them.

If the video-chat room closes when the chairman leaves, make sure the chairman keep it open a couple of minutes after the meeting is over. Again, chitchatting in this context is a good thing.

Stop reporting!

If you can only afford one takeaway from this post, take this one: in distributed and remote environments, meetings are not for reporting. Report offline, preferably in advance.

Meetings are expensive, hard to manage and exhausting. But in DRE, they are more expensive, significantly harder to manage and even more exhausting. I will talk about this more extensively in another post related with team meetings and 1:1 but, for now, I would like to say that because of these arguments, you should maximise the time for topics involving short discussions, brainstorming, dependencies discovery, opinions, etc.

So I recommend to remove the concept of “what I did yesterday and what I will do today”. Keep reports on the diary (I will talk about the diary in another post), promote a habit of reading the diary in advance and focus the meeting on topics leading to participation. And if you do not like the diary concept, use dashboard to visualise the WIP, described on tickets, make engineers report about their activity through mail on regular basis, etc. Whatever it fits your need except using meetings to report or communicate information that can be sent offline in advance.

Good practices

I like people to take these meetings seriously because they are really important in the long run. Sometimes I come across people that attend to these meetings while having a walk and smoking or they turn off the camera while doing something else. It is a consequence of the old school “conference phone call” culture.

I perfectly understand that attention does not necessarily depend on being in front of the computer and that a relaxed atmosphere is frequently a plus in some meetings, but I discourage these behaviours on this kind of meetings. I tend to be more flexible with “ad-hoc” 1:1 meetings.

No matter how informal these fast-track meetings are for you, think about those colleagues at the office who cannot do what you are doing, or the impact that generalising your practices might have on the team or the project.

In video chats, unlike f2f, somebody always need to be in control because you cannot afford having two people talking at the same time, due to technical limitations, for instance. Some formality is always required. Here are some tips to consider:

  • Create a routine that helps you to avoid moderation like:
    • Using a pre-determined sequence for providing turns. There are tools in which participants are ordered based on when they join, or their user ID, etc. Use those features in your benefit to reduce the need for moderation.
    • Favour those who join on time over those who arrive late somehow.
    • Make sure people join “on mute”.
  • Create key words for highlighting technical issues like somebody’s mic is not working or the connection “is choppy”.
  • Do not take notes by default but make sure people keep track of the action points or further conversations that needs to happen.
  • If something comes out of the meeting that requires in depth discussion, schedule a specific meeting. Make a note, say it out loud and move on. Keep “the flow”.
  • Make use of any possibility provided by the video chat tool to add labels or tags to your screen, like a state and emoji…everything that provides context or information about your state helps.
  • Provide the link to the video chat room in the calendar event.
  • Add 1 and 5 minutes notice notifications for these events. Those integrated with your desktop notification system are way more efficient than the mail ones for daily events.

Summary

I believe that remote teams benefit from having a short, daily meeting focused on participation over reporting, where there is some room for chitchatting, using a tool that everybody feel comfortable with, that also meets corporate policies and, when working in the open, Open Source community standards. The experience for every participant should be the same so I recommend having those meetings at your desk.

As soon as there is one distributed or remote person in the team, you are working on a remote environment. Adapt the short daily meetings to that reality.

Other articles of this series

  • 0. Introduction: introductory article where I explain the motivations to write this series of article and my goals.

Working in distributed / remote environments 0: presentation.

I have been working in distributed or remote environments (DRE) since 2003 approximately. I started back in the Canary Islands using IRC, wikis, ticketing systems, mailing lists…all designed to work remotely, avoiding VPNs.

A few years later I moved to the mainland of Spain and the situation in this regard became even more complex. I managed ASOLIF, a fully distributed organization back then.

Later in my career I have worked from companies headquarters but my teams or department were distributed or fully remote. Now at Codethink, a UK based company where 2/3 of the staff is located in Manchester, I work from home and travel frequently, visiting the office around once a quarter.

At Codethink I (am) have participated in Open Source projects driven by consortiums like the Linux Foundation or GENIVI. Currently I am helping on BuildStream, an Open Source project that creates an integration tool-set. They are distributed or fully remote environments.

In summary, I have worked as a manager, consultant, executive or owner in several organizations with a variety of DRE. A few weeks back I attended to a talk at OpenSouthCode about working remotely from home and I left it thinking that it might be a good idea to share what I have learnt on this topic, what it has not worked for me and what I haven’t tried, so others can tell me if I should. New ideas are always welcome.

But above all, my goal is to write down what I end up explaining over and over again to those I work with when they have little or no experience working in distributed or remote environments. I find very useful to send those people links to read and ask them for their thoughts afterwards instead of telling them the same story over and over again.

One of the things that calls my attention is the lack of a significant number of good books on the topic. One of the good ones is listed in the Reads section of my site but some of the topics I want to cover are not thereeither. There are several good blog posts though, but most of them are written from the remote person point of view, not the team, department or organization manager/executive point of view. I will list some links to good articles in further posts.

Definitions

Let me clarify what I mean by distributed environments and remote environments:

  • Distributed environment: I will refer to distributed environments to organizations that have several offices or sites, not when the employees or contractors are working from home. In general, those people based at the office that travel or work from home only partially will be consider also under this category.
  • Remote: I will refer to remote for those setups where the employee/contractor is working at her own place, a co-working… in no company site, with no other company member co-located.
  • DRE: distributed or remote environments.

Please, help me.

I would like to hear from you about topics you might be interested about that I can cover in this series, in addition of the ones I have in mind. Feel free to propose them so I wrote about them. I would also welcome references to blog posts or books on the topic that you have found useful, so I read them and avoid repetition, referencing them in this blog and my Reads section.

If you have a wide experience on this topic, maybe we can write the article together and publish it here or somewhere else.

Articles

The articles related with managing distributed or remote teams so far are:

  • Short, daily meetings: article about the substitute to stand-ups when working in DRE.
  • The calendar: article with tips and ideas on how to use the calendar in distributed or remote organizations.
  • Weekly meetings: two articles providing tips and experiences about how to run team meetings in distributed and remote environments. Article I and article II.
  • One on ones: advices based on toscalix´s experience running 1:1s remotely.