|
|
|
|
|
this issue is all about a topic that's near and dear to my heart: working on a distributed team. Enjoy!
|
|
|
|
|
Mentor Monologue
|
Every week, I read about another company that issued an RTO (Return-to-Office) policy. In many cases, it's fair to assume that this is a thinly veiled tactic to reduce expensive headcount. In other cases, I'm sure it's the effect of a leadership that had to jump into the deep end of remote work, and never learned how to run distributed teams properly. The latter is a tragedy, because there are plenty of success stories from which these leaders could have learned a lot. And some of the greatest examples grew out of open source projects.
|
What comes to mind first are the poster children of remote work such as Automattic, Buffer and GitLab. But we can draw from many more examples. For every successful distributed business, there are probably a hundred open source projects that function just as successfully.
|
That's not a coincidence. Well-known remote-first or remote-only companies such as Automattic, GitLab and Elastic were initially open-source projects that later formalized into businesses. When a company has its origins in a decentralized and distributed community, it makes sense that they would also bring its tools and principles to building a remote, or distributed company. And they’ve succeeded as distributed companies in large part because of these tools and principles.
|
Tools
Successful open source teams use tools that are easy to set up and use, but most importantly lower the barrier to contribution. Their collaboration platforms, e.g. GitHub and GitLab, support asynchronous communication, which also includes making notifications opt-in. This gives participants autonomy where and when they switch their focus from individual work to interaction with the team. Asynchronous communication means writing, and for the resulting documents, open formats like Markdown are the default. They enable each contributor to choose the writing tool that meets their individual needs best. Open formats also allow cross-application data exchange. By connecting the APIs (Application Programming Interfaces) of their platforms and tools, maintainers and contributors build systems that makes their day-to-day work on the project efficient and, in the best case, fun.
|
Processes
But if it was just down to tools, companies wouldn't fail at distributed teamwork despite all their expensive Jira and Slack instances. Tools and services have to be embedded in well-designed processes to be effective. And looking at open source projects, we can identify a whole bunch of practices that benefit any distributed team, be it in a loose hobby project or in a company. The starting point is to define a common goal. The more clarity there is about the destination, the easier it is for the team to get there. That's a management job, just like it is to foster good working relationships among collaborators. This task also includes dealing with unwanted behaviour. Sharing resources within the team is another core practice, and there is a wide variety of resources: expertise, equipment, materials, data, code, and work hours, just to name a few. A responsibility that all participants share is communicating regularly about process and progress. It's an essential practice to ensure that everyone is on the same page at any time. (I heard that this can benefit in-person teams as well.) And a bonus practice that we can find in well-rounded open-source projects but wouldn't mind in company teams as well is to give clear and fair credit to all contributions.
|
If you want to gain detailed insight into the processes and tools of one of the biggest remote companies in the world, check out the GitLab Handbook. It's an amazing resource shared in true open source spirit.
|
|
In summary, what distributed teams can learn from open source projects is to put in place processes that enable teams to communicate and collaborate effectively towards clearly defined goals, and to provide them with tools that make executing these processes efficient and fun.
|
|
|
In The Server Room
|
These are the community events coming up in the next few weeks:
|
- BRONZE events:
- Office Hour – Every Friday
- Community Hangout – Tuesday, May 14th
- SILVER events:
- Deep Dive: My Linux workstation setup – Wednesday, May 2nd
- GOLD events:
- I'm working on our first community workshop, "Setting up a static website using Jekyll, Apache and Certbot". I'll schedule a date once the materials are ready.
|
For all the details, please check the related forums on The Server Room.
|
|
Recommended reading
|
As an online teacher, I always recommend additional material to my students with which they can expand their horizon. Here's a list of reading tips I've curated for you.
|
|
In my monologue above, I mentioned keeping project members in the loop. Bryce Williams coined the term of "Working out loud" as a practical approach, and John Stepper expands on it in his article.
|
Pardon me for plugging my own content, but I think it fits really well with this newsletter's topic.
|
|
We're rounding off this issue with the story of how Zilog lost the 16-bit microprocessor market. It's one of these "what could have been" tales. There's a parallel universe in which CP/M on Z8000 became the dominant system in the 1980s.
|
|
|
Thanks for reading!
|
I hope you found my News from The Server Room enjoyable and helpful. If you have any feedback or questions, simply reply to this email!
|
|
Jochen, the Monospace Mentor
|
|
|
|
|