Working in distributed / remote environments 2: the calendar tool

One tool I think you should master as a manager in DRE (distributed or remote environments) is the calendar. It usually gets less attention that it deserves based on its significant impact in environments that promotes autonomy. Dealing with agendas in distributed or remote environments is so important that I recommend you to take the management of a calendar tool in your area of influence as a priority, specially when people is distributed across different timezones.

This post describes some basic features a good calendaring tool should have in my opinion and why they are important when working in DRE. I also provide some advices based on my experience. Feel free to comment if there are some others important to you that I haven’t mentioned. I would love to know about them.

Reflect your availability in the calendar

When managing collocated teams, co-workers know if you came to work that day, if you are at your desk…. Your co-workers might guess if you will be available later on and pass by your door on their way to the coffee machine to check when you return to your seat. That is not the case in DRE.

The calendar is the best tool you have to set up the right expectations about your availability among your colleagues. Make sure EVERY meeting, appointment, long call… everything that takes you more that 15-20 min. is reflected in your calendar, specially if it is a recurrent activity. Remember that being transparent about your availability is not just important for you, but also to your co-workers. They need to know when you are available for them.

When you do not answer a ping from your colleagues, they might wonder if you are sick, if you are dead, if you are ignoring them on purpose, if you are concentrated in something else or you are participating on an unexpected meeting. In the mid term, that uncertainty plays against you as a “remote” worker.

If there is a time window when you do not want to get disturbed, add the slot in the calendar. For instance:

  • I usually reserve 90 or 120 min. at lunch. It is well known that Spaniards take long lunchs but that is not the reason I reserve such slot. I like to have some time to work without disturbance and, at the same time, have some flexibility about when I eat. I usually add to the calendar a long lunch slot and try hard to prevent others from scheduling meetings during that time. It is not infallible but it helps.
  • I have worked with people that need to pick up their kids from school early in the afternoon, that visit their mother for lunch on Tuesdays, that pick up their partner at work early in the afternoon or that commute to a co-working space or Café after lunch. Add those slots to the calendar in such cases. Make sure your colleagues understand when you will not be available for them.
  • If tomorrow you have a hard stop time, add it to the calendar. Your colleague in the Canada might ping you at that time and wonder why you are not answering her.
  • If you will start later next Friday because you need go to the bank, again, add it to your calendar.

Those with little or no experience working in DRE write mails or ping others through the chat to ask you for your availability. Experienced remote workers talk through the calendar… or should. An invitation is always a question, not a command. Notifications are king. Provide the justification for the appointment in the description or notes section of the calendar event, add the resources, include links…. reduce the mails and chat entries you create for things you can do with the Calendar tool.

Those managers who make heavy usage of the calendar do not have to create a fire to have and urgent “ad hoc” meeting. They simply add a key word in the appointment title, or use any other trick to avoid the need to communicate such urgency through a different channel, making “urgent noise”. Again, use the calendar to its full extend to avoid unnecessary communications, misunderstandings, unmet availability expectations, appointments at inconvenient times, etc.

And finally, remember that, when working with people across different time zones, it is very easy to make mistakes that affects people’s personal lives when managing appointments. Promote a culture where flexibility is compatible with the required availability. Intensive usage of a good calendaring tool helps to promote such culture, in my experience.


I am a big fan of the “open by default” approach when it comes to information management so I try to reduce to the minimum the information I restrict from being accessible to others in general. The calendar tool is no exception.

As a manager, you will have meetings you do not want others to know about or are confidential by definition. Advanced calendaring tools provide options to restrict the information you share about appointments and availability. Pay attention to these features when deciding which calendar tool to use.

Team/department/product calendar

Translate your organization chart and product/service structure to the calendar tool and make sure your colleagues are subscribed or pay attention to the right calendars. This way, when you need to have a retrospective, define a release schedule, or communicate through video chat to your entire team a corporate decision, for example, you do not need to do anything special or use a complementary channel to get quorum. Remember that setting up meetings in DRE requires more coordination effort than in collocated environments. The usage of calendars significantly reduce the mount of coordination effort required.

Other useful calendars

There are specific events in any organization that can benefit from being managed through or reflected on a calendar tool when your teams are distributed or remote. I will put two examples. There are more.

Vacations calendar

In some countries, there are legal limitations to the information a company can share related with their employees. Assuming those restrictions, as a manager you need to evaluate the impact of a vacation request on the team, the department work or the project/corporate goals, etc. If your organisation does not have a Vacations/Holiday calendar, propose to HR the creation of one.

Having the vacations of your team members in a calendar together with other key dates, will help you to avoid unfortunate mistakes approving vacations. It will also help co-workers to check the availability of their colleagues, which explain why they are not or the chat that day. At the same time, they will self-manage the necessary availability of a qualified team member for key tasks during vacation times without you asking for it.

Bank holidays

It is not just that different countries have different bank holidays, it is also that some bank holidays are more important than others. depending on the religion or culture your co-workers practice or are part of.

As you can imaging, in DRE the bank holidays might become a topic when planning. Make sure you have a calendar that includes all the bank holidays affecting your team members, department or product team. It will be very useful, and not just for you as manager.

Evaluate the number of bank holidays that hit your team on Tuesdays and Thursdays. The natural tendency we all have is to take such opportunities to ask for one vacation day and end up enjoying 4 days off. Prevent extra work re-scheduling meetings later on the affected Mondays or Fridays.

Rooms/resource management

One of the most important features of modern calendar tools applied to distributed environments is the resource management integration: rooms, boards, projectors, etc. It is extremely important that the resources management is associated with the calendar so you have a single place where to create an appointment and book at the same time the needed resources. This feature for remote environments is less relevant.

Not just distributed, but open…

In asynchronous environments with higher latency than corporate ones, like Open Source projects, the email is an essential communication channel. Make sure you configure the calendar to send notifications and invitations through mail to better adapt the calendar to developers workflows when working in the open. If they make intensive use of a chat tool, send the notifications for important events through that channel too. But be clear about the complementary nature of these notifications. Paying attention to the calendar is, in any case, essential.

I find extremely useful when working in the open to have a public calendar with the most important events for my team or project, like conferences, release dates, monthly meetings, etc. It does not seem to be a widely adopted practice though.


I would summarise the post in three points:

  1. It is essential to provide a clear expectation of availability on regular basis when working in DRE. Calendars are of a great help.
  2. Promote the usage of calendars across the entire organization to enable a corporate culture where autonomy is an essential value.
  3. DRE represent a challenge in the conciliation between personal and professional life. Calendar tools help managers to prevent and detect undesired situations that might contribute to lower satisfactions levels or even burnouts.

Back from Akademy 2018. What an event!

A few days back I wrote about Akademy 2018 and my expectations and duties at the event. This is a report based on that previous post.

Akademy 2018 in Vienna, Austria, has been the best one in I’ve attended to in recent years. We event got a record number of sponsors, Codethink among them, and some of them for the very first time, which is always a good sign. The organization went smooth, the location was comfortable and several talks were very good. As a point to improve, I would mention the location of the Sunday party (sorry, social event), which was small for so many people.

Codethink as sponsor

This Akademy there were more first timers than in previous editions. Most of them knew nothing about Codethink. So being a sponsor allowed me to talk for 3-4 minutes to the audience, right before the closure, about what Codethink does, specially about the FOSS projects freedesktop-sdk and BuildStream. I will write more about them in the near future.

Representing Codethink also allowed me to attend to the sponsors dinner. I have attended to several of them before, either as a KDE eV Board Member, as the local organiser or as a sponsor representative (SUSE and now Codethink). This one worked very well. I was sit by the openSUSE Leap release manager Ludwig Nussel, former colleague of mine, Chris Lamb, Debian Lead and Alan Pope from Canonical, which allowed us to have interesting conversations about topics like reproducible builds, telemetry in distros, automotive systems, upstream events, etc. I also had the opportunity to introduce BuildStream to them.

Flatpak – Snap BoF

As part of my duties at the event I participated in the Flatpak – Snap workshop to introduce briefly the work Codethink is sponsoring on freedesktop-sdk and BuildStream:

  • freedesktop SDK 1.8 was just released before Akademy. flatpak-gnome and kde runtimes are based on it.
  • freedesktop SDK uses BuildStream as build tool. The integration team at GNOME too. So it was about time to talk about the project among KDE people. When it comes to build tools, the key selling point for BuildStream within KDE community is the advantage of creating a single set of definitions (recipes) and get different outputs like flatpaks, rpm-deb packages and hopefully in the future, snaps. Outputs depend on plugins that can be developed and maintained by contributors to BuildStream if they are not already available.
  • I am happy with the response BuildStream got and hopefully after the coming v1.2 release the project will support some KDE contributors in trying out the tool. It will be interesting also to support the KDE community in building the flatpak-kde runtime.


I introduced BuildStream to several developers. In general, very few knew anything about it which is not surprising since, except among the GNOME community, we have barely made any noise about the project. The coming release will help us to start mitigating this issue. The KDE community produces flatpaks, snaps, .deb and .rpm packages, has Yocto recipes… . A tool set that provides you all these outputs by maintaining a single sets of definitions, being simple to install, update and maintain, becomes attractive at first sight. The challenge is major, but a nice one to face.

Third edition of the Freedesktop Summit?

Several years ago, driven by Alison Lortie and sponsored by openSUSE, I organised the first freedesktop event ever. The following year I participated in the organization of the second one, that also took place in Nürnberg, Germany. During Akademy I talked to some people that might be interested in participating in a new edition. I did have some conversations around this topic at GUADEC too so, although it is still nothing but an idea, I will invest a few cycle to mature it. Who knows, maybe we can organise a third edition of the event next year.

KDE for automotive

As you know, I have been advocating at KDE for putting effort to showcase our software in automotive R&D and pre-production environments, knowing that Qt is the default graphic toolkit in the industry. Last year I provided a lightning talk about it which, together with the improvements in Plasma Mobile, triggered the interest of some developers at KDE, which are professionally involved in Qt companies working in embedded/automotive already. We had a BoF back then and we created a roadmap to shorten the gap between what we had and what would be interesting to show in such environments.

Andreas Cord-Landwehr and Volker Krause has managed to create two Yocto recipes together with the infrastructure to update them regularly. Both had a talk at Akademy. Andreas introduced the audience to Yocto and talked about the created recipes while Volker showed during a lightning talk the plasma mobile shell working on a RPi3 with the Raspberry 7″ touchscreen.

At the BoF we evaluated the technical, coordination and promo actions taken as well as the coming ones. The ultimate goal for the coming year is to showcase at different events KDE apps on top of Plasma mobile on automotive dev as well as to increase the attention of more KDE developers on embedded as a potential target market for KDE software.

I am excited about this progress. I believe putting some effort to move towards embedded can bring more attention and new energy to KDE.


I participated at the annual KDE eV AGM (general assembly) on Monday August 13th. As you know the KDE eV AGM is a close doors one, so private. It was a good move to provide room during the event for the working groups to summarise the work they have done. These reports used to be done during the assembly. As consequence, the AGM was shorter.

There used to be a time in which the KDE eV AGM was long and tedious. Over the years we have put effort in making it shorter and more dynamic. Mission accomplished.


It was great to meet all timers but also new openSUSE contributors. I could take some time to talk about points that require some attention in the distro, learn about the improvements on the delivery process that has been implemented on Leap 15, some of the actions in progress and future plans. Finally I did not update the Leap version in my working laptop (a Slimbook) because I had more work than expected during the event. I will update it during the coming weeks. Overall I am happy with Leap 15 in my personal laptop (a Lenovo) so far.


I was happy to see Slimbook booth at the event. As you know I am a Slimbook happy customer. I had the chance to talk to other customers at the event and I would highlight how happy we are with the post-sale service they provide.

Did I mention I would like to have a 11″ SlimNoteBook. I definitely did to them.

Free Qt Foundation

I cannot get tired of telling everybody within KDE and specially outside the community how important is the Free Qt Foundation, not just for KDE and the Qt ecosystem, but also for the entire Free Software movement. I never loose the chance when I am among automotive professionals to highlight the enormous impact that this entity has on their businesses. There is still a lot to do to provide The Free Qt Foundation the attention it deserves. By the way, it is always a pleasure for me to talk to KDE e.V. representatives there, Martin Konold and Olaf Schmidt-Wischhöfer.

What a great contribution they do.

Other topics

Did I mention how cool it is to have Mycroft integrated with KDE? All the demos I have seen are so promising… openSUSE Tumbleweed has packages to enjoy Mycroft on Plasma. The same applies to having KDE software on phones. It seems that we will have Qt6 in 2020 and that the transition from Qt5 is planned to be smooth. Breaking things when updating is never a good strategy in my opinion.

I love KDE Connect and I had the chance to learn about some coming new features, which is always a plus for coming to Akademy.

Sebas and Valorie got awards this year. Well deserved, as the rest of the winners. I like the fact that we as community, put some effort in recognising those who make significant contributions to the project.

I could have chats with people that I respect, new developers, key contributors… . As I said, a great event.

Thanks to the organisers

I will finish this Akademy 2018 report thanking the organization team who worked hard to make Akademy 2018 one of those hard to forget.

Thank you.

Codethink is sponsoring Akademy 2018 and I am attending.

Back in July 2017 I wrote a blog post, published by Codethink, explaining why is a good business to support community driven FOSS events. This post is related to that one.


I will be attending to Akademy 2018. It will take place in Vienna, Austria, from August 11th to 17th. I will be there representing Codethink, which is a proud sponsor of this 2018 edition.

I attend regularly to Akademy since, as most of you know, I have been an active contributor, a user of the software, a supporter of some of their activities and/or a KDE e.V. member for some time now. I learn a lot during this event, and not just about KDE related topics.

This edition has several specific points of interest to me:

  • I am involved in a project called BuildStream, a FOSS integration tool for declarative systems and applications. Currently its main user are the GNOME integration team and the Freedesktop SDK project. We would like to expand our user base among communities like KDE.
  • Freedesktop SDK are a platform and a SDK runtimes for flatpak apps and runtimes based on freedesktop modules. Several colleagues of mine are behind this project that is about to release a new version.
  • A year ago, during an Akademy BoF, some KDE contributors decided we wanted to put some effort towards enabling KDE software on automotive. This year the first modest results will be presented to the wider KDE community. I have been preaching about this move for some time now so it is exciting for me to see others involved and making progress.
  • I will attend to the KDE e.V. Annual General Assembly. KDE e.V. is the orga34f05-logo_kdenization that supports the KDE community which is an important activity.
  • I will update my working laptop from openSUSE Leap 42.3 to Leap 15, taking advantage of the presence at the event of a couple of former colleagues from the extinct openSUSE Team at SUSE, and Slimbook, the guys I bought my laptop from. Make sense, right?
  • Codethink is always looking for talent willing to move to Manchester, UK, or exceptionally, work remotely. Come talk to me if you might be interested.

It will be, as usual, a great event. See you all there.

Consolidating my blogs in WordPress

I have imported all my post from Blogger into this site. There is a plug-in that do the import for you. It works well but obviously is not perfect. So if you end up reading a post published before I moved to WordPress, that is in 2016/2017, you might find little formatting issues or links pointing to Blogger.

If that is the case, please notify it to me and I will fix it. Meanwhile, I will keep both of my blogs at Blogger in maintenance mode. These blogs are:

Another little step taken towards reuniting all the info into a single place.

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.


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:

  • 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.


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.


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.