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 3: weekly meetings (II)

This is the second and last post of the Weekly Meetings series. If you haven’t read the first one, I recommend you do before reading this one.

Where?

There is a very simple rule in distributed environments. If one of the participants in the weekly meeting is remote or at a different office, everybody is remote, or should be.

Take advantage of what the technology provides and participate in the meeting from your desk instead of from the meeting room together with part of the team. I pointed several reasons for this in a previous post. Let me develop further:

  • You do not have a white board to support your explanations. You will need a virtual one and its usage is more effective when everybody can collaborate, getting the same experience. There are plenty of tools nowadays for this purpose. Your screen is your projector. If you need to show something to others, sharing your screen becomes trivial compared to the set up required in a meeting room, no matter how prepared it is.
  • Let me insist on how important it is for building a healthy team that everybody lives the same experience at meetings. It is not just that participation and follow up is harder to those who are not present in the meeting room, it is that the meeting becomes less efficient because those joining remotely become listeners instead of active participants.
  • When teams are used to meetings at their desks, efficiency increases. It is easier to start on time, the sound quality is uniform, less time is wasted in moving to the meeting room, flexibility to organise meetings significantly increase, etc.

How many participants?

Since it is significantly easier to manage a meeting in person than remotely, I recommend to reduce the number of participants in these weekly meetings in distributed and/or remote environments.

It is a common mistake to assume that the ideal team size does not necessarily need to change when moving from collocated to remote. In my experience, distributed teams should be smaller than collocated teams. Remote ones should be even smaller.

Weekly meetings with 8 participants in a room are manageable if the team is disciplined. That is not the case, in my experience, with such meetings through video chat.

Meeting Length

I mentioned in the previous post that meetings in distributed and remote environments should be short. People gets tired of looking at a screen and talking through a mic. I also mentioned already that due to the need of talking once at a time, these meetings have a slower page, which bores people to death.

If you can, make them no longer than 30 minutes. Allow a little more for chit-chat if there are plenty of topics. but in general, avoid reaching the one hour mark. If you reach it on constant basis, analyse and distil the topics, try to preparation them better, send the descriptions in advance, promote offline discussions before bringing the topic to the meeting, control the time better, etc.

And if still is unavoidable, split the meeting in two 30 min meetings if your team can afford it in terms of agenda. Remember that for some, these meetings might require a personal sacrifice because they might need to happen very early or late at night. Two 30 min meetings are far more productive than an hour long meeting when managed correctly.

If any topic requires significantly more time than you can afford during the weekly meeting, propose an “ad hoc” meeting for it. Make sure though that the schedule of such future meeting becomes a a topic on the current meeting. Remember that schedule meetings for the whole team is hard, specially through asynchronous methods.

When?

Applications like Doodle or Pollunit (there are more) can help you and your team to decide in which time slots are better to schedule any meeting. The weekly team meeting is a good example. Every serious calendar has a free/busy time feature that allows you to avoid conflicts. Make sure you master them.

Ensure everybody adds in their calendars the working hours and you define yours so you get an alert when you are trying to schedule a meeting out of somebody’s working hours. I think I did not mention this on the post about the calendar tool. 😮

Serge Broslavsky showed my a trick I use ever since. In a sheet, he added the names of the team members (column B) and the UTC hours of the day (row 2). Then he marked in green, orange and red the times in which meetings were acceptable for each team member. When you have to manage a large number of people around the globe, that simple visualization makes scheduling meetings easier.

Avoid scheduling meetings out of green working hours. If you cannot, try at least to avoid putting any colleague in a position in which they cannot negotiate their own agenda in amber or red hours. In remote environments with different time zones involved, people need to be flexible about their availability, but being flexible does not mean there is no impact. Remember to promote the culture you would like to live in.

As mentioned previously, in DRE it is important to arrive to the meeting prepared so I tend to avoid “first time in the morning” meetings. Like everybody else, I hate interruptions so I tend to concentrate half hour meetings in 2 hours slots and have 1 or 2 hours slots free of meetings, at least a couple of days a week. Promote among participants to reserve a free slot before your team meeting starts.

If you are managing managers, it is extremely important to decide if you want to have your weekly team meeting before or after your colleagues (managers) have had their own weekly team meetings. By default I would prefer to have my weekly meeting after all my managers have had theirs but that depends on the type of job and how is it organised.

Roles

I like to pre-assign roles to avoid any discussion about who should play which role. I add to the meeting ground rules how the roles are selected. Pre-defined rotation is a system I have used. Let the team choose the one they prefer. The point is to start the meeting already knowing who does what. Start the meeting confirming who plays each role, after allowing one or two minutes for chitchatting. The roles are:

  • Scribe: everybody takes notes. Is one of the good things about having every participant in front of their laptops. But there is somebody responsible for completing the notes, record them and publish them.
  • Timer: this is critical since meetings needs to be short so participants need to be concise. The timer not just controls the time assigned to each topic but also that nobody goes off-topic or eat all the available time.
  • Topic lead: the meeting agenda should include a topic lead for each topic. That is the person in charge of making the discussion at the meeting worth it which frequently means that the right information has been sent in advance, questions has been asked and answered and that participants understand what is the expected outcome of the meeting. It will also ensure that the notes reflect the state of the art and will highlight if the topic needs a follow up in the next meeting, for instance. If there are actions points, the topic lead will ensure they have been recorded and/or properly tracked.
  • Meeting owner: I mentioned that you, as manager, should be the meeting owner which does not mean you manage the meeting. Make sure your role is clear, set the boundaries of such role and use your “power” wisely. Assign a person that will substitute you when you are absent.

You can add more roles but I only do in extraordinary occasions.

Some final tips

I will summarise some additional tips in no particular order:

  • Since the environment in these meetings is more hostile than face to face ones, making these weekly meetings short and to the point has to be an essential goal which requires more preparation in advance compared to face to face meetings.
  • Make sure the agenda is sent to participants in advance. Provide a time estimation to each topic, assign a person to lead each agenda topic and make sure you do not fill out the 30 min. I would recommend to not have a pre-defined agenda beyond 20 minutes. Meeting’s pace in DRE is slower than in face to face meetings. Include in the agenda time for AOB (Any Other Business) but be aware that this topic can be used to come to the meeting to discuss topics that has not been prepared in advance. Do not let anybody misuse AOB.
  • Every description, report, detailed opinion, statement or positioning should be sent in advance, as I have mentioned before, with enough time for others to read and answer in written form before the meeting. This saves long turns and explanations during the meeting.
  • When there are more topics than time, ensure those topics related with people management has preference. The others should wait until the next meeting or be a matter of a future “ad hoc” meeting. Since scheduling those topic-specific meetings is so complex, specially in remote environments, use the AOB section to schedule it or at least get a tentative date and time for it.
  • If part of the meeting deals with tasks, blockers etc., make sure the tickets have been updated in advanced so WIP (Work In Progress) can be clearly visualised by all participants. Provide the links to the dashboards to the participants in advance.
  • During the meeting, ensure that every time somebody makes a reference to a specific page, the link to that page, ticket, image, etc. is provided through chat to every participant.
  • I find slides very useful when describing a complex idea or when the amount of information to be provided is high. Screen-share is your friend here. I recommend though to make the slides available to everybody beyond that screen share. They will be easier to follow, participants can take notes, click on the links, etc..
  • I really like dashboards, specially kanban boards as a WIP visualization method (through tickets), even if you are not following the methodology. I use them during meetings to go through hot topics. When going over tickets, repeat the number and title of the ticket you are referring to more than once so everybody can follow you.
  • Predefine a way to communicate that somebody’s turn is taking way too long, or that the participant is repeating herself, that the information is irrelevant , etc. In summary, find a way for anybody to cut anybody politely. The timer role should be the default person for this, but everybody should participate on this tough task.
  • It is common that participants start talking while mute. It happens to me more often that I will ever recognise. There are video chat applications that has solutions for such cases like a notification, or the possibility for another participant to activate anybody’s mic. Try to use video chat apps with these features. If yours does not have it, use a keyword to notify to the person that she is talking while muted.
  • Since in a video conference only one person can talk at a time, muting participants should be a normal practice. Nobody should take offence. Sadly only most experienced people do not. Try to avoid muting people while speaking unless it is strictly necessary if your time has little or no prior experience working in distributed environments or remote. Assume by default that the muted person might have taken it as a rude gesture from you. Talk to the person offline to clarify the situation. Make it an acceptable practice (in specific circumstances) little by little.
  • When the connection of any participant introduces noise or is choppy, muting the affected participant is a must. Mention why you did it, and move on. You cannot afford stopping the meeting flow because of somebody’s bad connectivity. Participants should have alternatives for these cases. I usually have a 4G connection as secondary line in case my default internet connection fails. If the affected person is the topic leader, move on to the next topic. If it happens to a different pre-defined role, make the next person in the queue adopt the role. If it happens to you… well, use the opportunity to “lead by example”.
  • Do not join team meetings through wifi. Do not underestimate the amount of bandwidth that several participants require, even with the best video chat app or plug-in. No, shutting down your video camera is not ok. Take the meeting as seriously as everybody else.
  • Do not close the video chat room once the meeting ends. Allow some minutes for off-topic chatting. Stay once in a while a few extra minutes yourself to participate in those off-topic conversations.

It takes time for any team working in DRE to have smooth and productive team meetings. Keep pushing and do not accommodate, tendencies are usually perverse when it comes to meetings dynamics.

I would like to finish pointing that weekly team meetings for groups that work in distributed or remote environments (DRE) might be the only time where they get together during the week. It is essential to keep in mind how hard it is to generate a sense of team work when there is little or no face to face interaction. This action, the weekly team meeting, represent the best opportunity generate a team spirit, which is a fundamental mission for every manager.

I am sure I have left behind important tips or you might not agree with some of the above. Please let me know. This is not a science.

Working in distributed / remote environments 3: weekly meetings (I)

This is the first out of two parts dedicated to share my experience around weekly meetings in distributed and/or remote environments (DRE).

Introduction

As a manager I cannot tell you how many times I have listened colleagues of mine complaining about having too many meetings, but specially about too many unproductive meetings. Sadly, they are frequently right. And you know what, for every meeting any engineer I have worked with usually have, I have three. And no, attending to meetings is not my job either. It has never been, thanks God. And yes, they usually are at least as unproductive as those the engineers complain about.

I wrote in a previous article that in person meetings are expensive, hard to manage and exhausting. I also mentioned that, in distributed or remote environments (DRE), meetings are even more expensive, harder to manage and far more exhausting.

You will find very few people who dislikes unproductive meetings more than I do. I am not a fan of long meetings either. The best way to avoid unproductive long meetings is to have a real purpose for them. And that purpose has its reflection on an agenda. In short, no agenda, no meeting.

So my first point is, if you are a manager, reserve a slot for a weekly meeting so everybody takes it in consideration in their agendas. But the meeting will only take place if there is an agenda. If your team is healthy, there will most likely be topics to discuss every time.

This principle applies to any professional environment, but due to the nature of DRE, unproductive meetings have a higher impact on participants. Keep that in mind specially when coming from co-located environments.

Who owns the weekly meeting?

I enjoy working in organizations where technical leadership roles are separated from other management roles like product or line management. I definitely recommend to have at least a clear separation between technical and people (organizational) leadership roles. When the tech lead is the line manager….

These weekly meetings can and should serve the team. At the same time, as a line manager, there are occasions in which you need the flexibility to modify the agenda or even own the meeting entirely.

So answering the question, you as manager own the meeting, which does not mean that you manage it, conduct it or even play an active role on it by default. In fact, I recommend not to. Just be clear about the possibility for you to change the agenda in short notice. Be wise about this power though. It might have some negative impact on your colleagues if it is abused.

Weekly meeting main goals

In my opinion, the weekly meeting has the following key goals in DRE:

Alignment

Autonomy is widely perceived as beneficial and a necessary step towards reaching mastery. But autonomy does not come for free, it is associated to a risk, specially as teams/ departments grow: that risk is called alignment.

As a manager in DRE, your number one goal is to promote alignment across the organization and specially across those under your responsibility. I explained this focus shift that any manager should face, referred to working in the open, which is a specific case of DRE, a few months ago.

So my recommendation is to focus these weekly meetings in improving alignment.

Discussions

There are times in which discussions through mailing lists or chat become so complex that the right approach is to discuss the topic in a meeting. There are other occasions in which the topic under discussion is sensitive to one or more team members. Those implicated in such discussions might benefit from a chat through video, experiencing the advantages that some body language and bigger doses of empathy might bring.

Call the attention of your colleagues when overdoing the discussions or when they reflect frustration and invite them to move the conversation to the coming weekly meeting.

Consensus

Alignment frequently requires consensus. Reaching  consensus through mailing lists or chats might be extremely hard, specially the last mile. One or more discussions through video chat might help.

Take some time during weekly meetings to work towards reaching consensus on key topics, instead of having one “ad hoc”meeting to solve it, at least until the discussion is mature enough. Remember that alignment is your outstanding challenge. Work on it on regular basis.

Conflict resolution

In order to understand how important team meetings are in DRE you need first to be aware of the strengths and weaknesses that remote communication has.

Strengths:

  • Direct
  • Aseptic
  • Accurate
  • Easily traceable and recordable.
  • Higher latency, which sometimes help.

There are also weaknesses:

  • Lack of body language which represent a significant decrement on the amount of information transmitted.
  • Requires experience to do it right.
  • Latency: sometimes plays against you.
  • Irony, humour, passion… hard to transmit emotions. So aseptic communication channels might play against you and your colleagues many times.
  • DRE communication is not taught at school. It takes time to master it. It is one of the great advantages of participating early on in your career in Open Source projects. You learn to communicate in DRE.

Back to the conflict resolution point, supporting written communications with conversations through video chat are extremely important in DRE to solve or contain all kind of conflicts, before they escalate.

Use weekly meetings to solve simple conflicts or to expose them. Take a deeper evaluation and potential solutions offline and come back to the team meeting with the result and evaluation. The message is that, when problems or conflicts affect the team, weekly meetings are a better forum to expose them than mails or chats.

More serious conflicts require a different approach. Using the weekly meeting to fully identify them, evaluate them or attempt to solve them might not be a good approach.

Hot topics

In DRE, it is significantly harder to schedule meetings in short notice than in collocated environments. It might also have a higher impact in people personal life.  I always recommend to reduce the drama associated to meetings announced in short notice. Having a scheduled weekly team meeting will significantly reduce that drama while having a positive impact on any team dynamics.

Most hot topics…. can wait one or two days for the weekly team meeting.

Learn about the state of art.

As a manager, you get a significant amount of information about how things are going for your co-workers,team, department or organization in front of the coffee machine, at lunch or at the hall, listening and talking to those you work with. You do not have such luxury in DRE so weekly team meetings represent a unique opportunity to understand how things are going, beyond tickets, merge requests, reports, chat channels and mailing lists.

Following the same argument, employees get fewer information about how is the company doing when working remote. Weekly team meetings become an outstanding opportunity for them to ask you and comment about corporate related topics.

Escalations

In the same way that in DRE, you have limited opportunities to “talk to the team”, they have the same number of opportunities to “talk to the company”. As a manager, it is your responsibility to create the environment in which escalations are properly communicated, discussed, tracked and managed.

Team meetings, together with 1:1, become the default forum where to define and trigger escalations. No matter how flat your organization is, you need to define a clear escalation process that works for both, the company and the employees. This is specially true when you are, de facto, the default company interface because you are the line manager.

Participation.

In organizations or teams where people is spread in different time zones, joining a weekly meeting might involve sacrifices. Now imagine a colleague of yours joining a meeting at 22:00 to realise that 75% of the time has been consumed by a colleague describing a topic, summarising what she did about X or reporting about what somebody else did with Y.

Do you really expect that person to pay full attention?

In order to “encourage” participants to remain connected to the meeting, many managers and teams developed techniques that frequently do not apply to on line meetings. I love the “no laptops allowed” one.

But even face to face meetings, many of them does not work. The human brain have an outstanding capacity to take us somewhere else without others noticing. I developed such skill at college. The normal outcome in an online meeting where reporting is the norm and not the exception, is that participants listen while doing something else.

A waste of time and passion.

It is well known that the key to successful meetings is active participation. This is specially true in DRE. Looking into a screen and listening others through speakers is hard enough already. Add to it lack of participation and you will end in a set up for failure. Descriptions, reports, etc. should be provided to participants in advance. They should read them and come to the meeting ready to participate. Dependencies, blockers, feedback, etc. should be the meat of these weekly meetings.

It is amazing how effective meetings might become in DRE when participants develop the habit of sending and reading reports and descriptions in advance. Promote preparation in advance over longer meetings.

Participation comes with a challenge. Managing fluid conversations through video chat is hard. Experience and simple tips, like something that is equivalent to raise the hand (ask for turn) or a nice way to make somebody aware she is talking for too long, etc.  help a lot. Try some. Some video tools provide some nice solutions to mitigate this challenge.

Stay tuned for the second part of the post.

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

Agile established 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 be too 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 slightly different goals.

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 (distributed or 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 those.

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 solutions that worked on Linux was the main challenge, so a general excuse to push back on these kind of meetings. 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 can become a challenge. Again, Android has come to the rescue a few times in such situations for me.
  • 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 are 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 with 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 offered something open with little or no cost. 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 are 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 DRE 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 DRE. 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.