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.

Business model as a variable to consider when choosing Open Source software.

p { margin-bottom: 0.25cm; line-height: 120%; }

A couple of weeks ago I gave a talk at an Open Source event for professionals. A senior developer asked me a question that got my attention. It was something like…
So do you recommend to consider the business model when choosing a particular piece of Open Source software, beyond the license?
My answered was something like…
In general yes, specially when that piece of software is core to your product/business and definitely in cases where you distribute/sell it to customers.
 
Thinking about it later and reviewing some of my talks and posts, I thought it would be interesting to develop that answer a little further.

Key questions

Any analytic report about who writes the code in open and collaborative environments will reflect how corporations involvement is increasing in Open Source software development at every level. More and more companies are transitioning from becoming FLOSS consumers to producers and almost every new software company out there has Open Source as a core strategy or even as part of their DNA.
But who is sustaining the development of that key piece of software that will be a core part of your future product? Who pays those developers? Why? How does the key stakeholders benefit from the outcome of the ecosystem and the software they produce? How much do they invest in the production of that software? For how long? How do they get their income? What is the relevance of the software produced by the ecosystem they feed in their business models?
These and similar basic questions need to be fully understood before a specific software becomes part of your key product or business. Knowing the answers to the above questions might not prevent you from surprises in the future but at least can prepare you for the potential consequences. What it is clear to me is that these answers are becoming more complicated to find and understand over time, specially for those companies who do not have a strong background on Open Source.

Choosing a specific piece of software based on purely technical variables or even present healthiness of the community around the project/organization, expectations of the number of contributors or impact in general might not be enough any more. A specific community or project will become “your provider” so the business model behind it is equally important.

Examples

You might base your new product on a technology produced by a company that is heavily investing on it but that has no clear associated business model. It might be for instance a service company and the software might not be core to their services since it has no significant impact in their income. This might not be your case so you can end up relaying on a provider that do not have “your use case” as a critical one, no matter how big you are and how profitable your business could be.
Think about the case when your product relies on a technology that is disruptive but sustained by a start-up or a company that is not profitable yet. Engineers might be extremely excited about this new technology for good reasons, the community around it might be on fire at the point when you are analyzing it, but the future of the business might be unclear due to, for example, the inexperience of the executives leading the project, the market they are playing on or the strategy of the investors supporting it.
A well established project has suffered a fork, attracting the core developers. Very soon a boost of energy is noticeable in the development front, which leads to an increase in the number of contributors. They gain customers rapidly but it is unclear if they have a solid business case to sustain the development effort with the current growth in the short term.
The above three cases and many others out there show that, although there is no question that published Open Source software development represent an advantage compared to proprietary when it comes to sustainability, that doesn’t mean it is at no cost. This is specially true when safety critical and/or long term support are essential variables for you. 

Sometimes choosing a technology/project with a business model more aligned to yours could work better than choosing the leading or hot technology/project. In other cases, going for a more conservative but solid/veteran project might be the right choice. In some others, assuming risks can be the best choice.

Key considerations

I believe that for any organization, moving from being a good Open Source citizen to becoming an Open Source company also means that:
  • You evaluate the business models around the organizations/projects that produce the software you contribute to and/or consume. This requires involvement of business related professionals in key decisions related with selecting Open Source software.
  • A key part of your sustainability effort is to create feedback loops with your providers also at a business level, contributing to their sustainability as Open Source project but also as organization, specially when you are bigger/stronger than they are. Ideally, your business model should be compatible with those from your providers so your success has a positive impact on theirs.
  • You put in place mitigation actions to reduce the risk of severe changes in your key Open Source software providers situation that in the worst scenario, might compromise the future of your product or even company.

Conclusions

The fact that Open Source is done in a collaborative way might reduce sustainability risks in most cases compared to proprietary business models. But the nature and complexity (dependencies) of many Open Source ecosystems introduces new risks that requires to consider variables beyond the technical or community aspects.
This is why it is so important to choose carefully which FLOSS software you will use, produce and contribute to, looking at the business models supporting the selected project/technology stakeholders.
As a company, you will not control any more the relation with your FOSS providers as you used to. Open Source has changed the nature of that relation, that goes beyond the license or any further contract. To take advantage of this new reality, you will need to adapt.

Final reminder

Open Source is also about providing more control to creators. If you want keep similar levels of control that you had in the proprietary world, contracts will not be enough anymore. You will need to write the code yourself, which means, become upstream.
And the smartest way to achieve sustainability writing code is through collaboration.

Business around AGPL software? Oh yeah…..

I’ve heard many times to executives say that AGPL is a license incompatible with business. This is a well spread idea specially in the web world.

A few years ago a friend of mine, a visionary, Gonzalo Aller, from Fotón SI, the oldest Spanish Free Software company,  told me that AGPL is the GPL of the web world. He tried to convince me to put that license in a web project I was involved with. I thought he was crazy, like many times before (and later). I was one of the ignorants who used to see AGPL as business unfriendly.

Like many times before, little by little, I changed my mind and I got convinced, once again, that license define conditions but never determine business. Business is more related to having good ideas, taking smart decisions, execute them correctly and put your hart on it, and not so much about license.

This statement is backed up by many examples. The following projects:

  • CiviCRM
  • Zarafa
  • Gitorious
  • Launchpad
  • ProcessMaker

and many more are AGPL based Libre Software projects run by companies that build services around the product, successfully.

We have a new example, announced just today. OwnCloud Inc is born to support OwnCloud, a KDE project based on AGPL. Good luck and happy business!