Say no to Zoom | How does Linux and the OpenSource community do it?

It might seem odd to derive lessons for formal organisations from a self-organising volunteer activity, yet, the practices and skills found in Linux and open source workflows are invaluable when it comes to remote work, especially in times like these.

The open source system advocates trust, compassion and empathy as means for motivation and improved productivity. In its case, people have always been motivated, due to the system’s careful attention to initiative and incentive structures. What lessons can we take from these structures for use in our formal organisations today? 

Work/Life

“As much as we want to retain work/life balance, we have to acknowledge that our work and home lives are being forced together in sometimes uncomfortable ways. The current situation isn't normal, and expecting normal productivity and complete focus isn't reasonable.” Stefanie Chiras, VP of the Business Unit at Red Hat Linux.

For many people, it's hard to separate work and personal life when their home is also the office. In these abnormal times, it’s important to consider employees holistically, not just in their work roles. They may be dealing with a great deal of stress that they can't just put down during work hours - this should be respected and understood. For example, avoid sending communications outside “official business hours”. If your new working time happens to be later, consider scheduling your emails to send during normal business hours to remove the expectation of working all the time. Go further, and encourage the team to take breaks during the day, not to eat lunch sitting at their desk, and, if possible, to go outside and get some fresh air.

Trust/ Tracking

“The very essence of open source teams is built upon trust.”

Everyone is accountable for what they need to deliver. Teams need to trust each other to get things done instead of dictating what the next task will be. Through trust, people are empowered, motivated to produce high-quality work.

This snaps the phenomenon of the “all-day Zoom meeting” into sharp focus; feeling secure over monitoring employees’ actions over the last 8 hours, opposed to their level of output over unmonitored hours of the day should raise some concerns.

Allow employees to work flexible hours so they have the chance to perform at their optimal moments. Early risers and night owls should each get their personal opportunities to operate when they work best. This flexibility on how, when, and where employees work, would likely improve their productivity and their loyalty to the company. Forcing everyone into all-day meetings would greatly inhibit this. 

Output/Time

“The best architectures, requirements, and designs emerge from self-organising teams.” 11th principle of the Agile Manifesto

Focusing on results. Output over time. Something we hear a lot, but hardly internalize. An entire day spent at a desk, in an office, or on a Zoom call, would not - by any means - reflect the amount of expected output. Rather, employees must know and understand what they are responsible for (as opposed to how many hours they should work) and know when they've done enough. A system like this, where priorities are communicated and clarified, and employees have the freedom to work through those priorities over a sensibly set time period, would eradicate issues of trust and lack of productivity. 

This is how the open source community operates. Developers are not spoon-fed tasks, but simply communicate amongst each other what must be done, and what can be done. Their work is then left in their control, to refocus and prioritize.

So, What?

“The point of all this is to learn from those companies who have been working in a distributed modality for decades, and have not simply ported the pre-COVID method using online tools.”

Ultimately, the rules of remote work discussed in the previous two articles aren’t solely advocated by Basecamp and Automattic, respectively - they are widely accepted in the distributed world. We have all been forced to become distributed companies. The point of all this is to learn from those companies who have been working in a distributed modality for decades, and have not simply ported the pre-COVID method using online tools.

Further Reading

https://www.welcometothejungle.com/en/articles/btc-remote-open-source

https://opensource.com/article/18/9/connected-on-distributed-team

https://www.synopsys.com/blogs/software-security/tips-working-remotely-open-source-community/

https://www.redhat.com/en/blog/remote-leadership-how-provide-support-distributed-teams

linux.jpg
The Linux and open source community are, arguably, the oldest examples of distributed workflows in existence - they can be traced back almost 30 years. Linux runs every Android phone and tablet on the planet. It is working behind the scenes on almost every device, and across the Internet. Over 30% of all web servers run Linux - Facebook, Google, Pinterest and Wikipedia all run on Linux. Yet, in most cases, developers haven’t met, and are likely in different parts of the country, or more commonly, in different parts of the world - often not even speaking the same language. Despite this, they collaborate with incredible efficiency, and produce with exceptional quality. They don’t do all-day Zoom meetings.