On working remotely

This article was originally published on hennessen.net on November 15th, 2019

A topic I keep coming back to, is remote collaboration in software development. Why?
Well, I had the opportunity to work in multiple project setups with different setups with regards to the team members locations. Basically it spanned from single location office, over multiple locations in one time zone up to offices and remote colleagues across three time zones. The main reason is, that I myself like working from home quite a lot and will be doing so more in the future. Hence, I started looking around for material on the topic and best-practices for remote teams quite a while back.

This blog sums up, what I've experienced and found in several sources.

ℹ️ For those of you understanding German and being more interested in listening than reading, I've discussed this topic with my friend Michael in the first episode our Podcast Entropisches Duett. However, there might be more in here, since @mi_schm recommended some more material on the topic after the show. Thanks for that!

Which Re-Mode?

Collaboration in software project can have many flavors, spanning from all in one office (not remote) to all somewhere, no shared location (full remote). The usual model I've seen so far in the corporate area, was a larger part of the team being on the same location (obviously). This gets more complex from a team setup perspective when one or more locations are added, which I will keep referring to as a mixed setup.

Looking around for software companies actively, publicly talking about their remote collaboration models, I found multiple examples, like Zapier, InnoQ, Doist, and more which all add their personal experience to the topic. One finding up-front: Atlassian was the only example I found, actively talking about their mixed setup with feature teams on one location.

For me, the topic breaks down in these areas:

Working Mode

Besides the setup of teams from a geographical perspective, the working mode in which the team operates plays a role to the success of a remote team as well. Basically, in this area many of the articles emphasized the importance of the agile best practices many know for years, but probably not so many teams execute.

Examples are Ship things once they are done, not when a deadline tells you or Everybody does support on a rotation basis to keep workload and knowledge distributed across the team.

While doing so, the organizational structure in the teams can have different formats peculiarities: Developers working on features by them selves with reviews by others, compared to pair programming are mentioned.

A while back, I came across an approach entirely new to me: Remote Mob Programming, which is based on a team of four members and non-stop rotation of one member typing and the other three discussing what is to type. The company behind it InnoQ also as a podcast with an episode dedicated to this topic which I can highly recommend, while unfortunately having no experience in this area.

Team Member Profile

Zapier talks extensively about the profile people should fulfill to work in a remote environment. They should be of time management and self-organizing of course. But they also have to be what they call tech-savvy and good writers, as their only direct interaction partner throughout their workday will be a computer, where they communicate in written form. Potential team members need to be ok with working in a non-social workplace, like their home office most of the time.

Manager's should judge employee's on the outcome of their work and not the hours they are online; they should hire trustworthy people and then (and I like that) also trust them.

Communication

Communication is the area, where in my experience things can get complicated easily and hence I deem it to be the most important area.

In remote teams, most commination will happen in text form, usually in a collaboration tool. This requires all participants to change their behavior compared to an office environment:

Such communication is happening asynchronously (and it should). This can be difficult, as GrooveHQ, X-Team and Doist point out, but it is the basis for team members being able to plan their day in advance and be focused when working on a task without interrupts. The planning is getting more important and hence a necessity. Immediate answers to questions just raised, can no longer be the expectation. Synchronous communication can (and as well should) happen in certain rare occasions, for instance for emergencies or team-alignment (like your daily standup). However, async should be the default.

For asynchronous communication, multiple tools are already available and frequently used out there, the most famous example probably being Slack. And yes, email can be used asynchronously, however the usual expectation in projects is synchronous feedback and email has a major other flaw: No transparency to whom is not on the recipients list. Hence whatever the tool, it has to ensure, that all communication is visible to all others and can be found again later. The last point is something that I haven't read consciously in any of the posts I am linking. Thinking of new team members boarding on once a project is one year down the road, tells me that this is highly important.

Synchronous communication can be easily achieved face-to-face, using Zoom, Google Hangout or other video conferencing solutions.

Besides the planning part for your day or the project becoming more important, asynchronous communication adds other aspects of pro-activeness required by all team members. Without transparency across the team, misunderstandings can happen and hence work even not done, or done twice. Transparency means, that all team members communicate transparently on the status of their work, problems, future plans, etc. Some examples I'd like to point out, are:

• Meeting Notes, per default, visible to any-one (including management meetings)
• Clear, joint priorities for the entire team
• Developers stating their plan for the day each morning in Slack
• Developers sharing their most important lesson for the day at the end of it ("Today I learned")
• All team members following up on the information (i.e. "reading") relevant for their work

Social Interaction

Apart from communication on work itself, the social aspect cannot be disregarded, even in full-remote teams. This starts with everyone's attitude towards communicating with others in text form. Sometimes, chat messages, questions or even decisions might catch us on the wrong foot. There is a known phenomenon, where people would assume other’s unexpected behavior as an display of bad or at least confrontational attitude instead of simply not being up to date or not knowing: Hanlon’s Razor.

Synchronous communication, as mentioned before, still has its place in even entirely remote working teams. There are work-driven reasons, like the daily standup, which simply works better as a direct discussion. Bonding between team-members, building team spirit and getting to know each other beyond work are important goals, which direct conversation and face-to-face meetings help to achieve. Formats like regular 1-on-1's between manager and employee, monthly team-meetings (in person or via video conference) or yearly gatherings in-person are only some of the formats used. Zapier for instance creates pairs of employees randomly every couple of weeks and encourages them to have a discussion and get to know each other.

I've briefly touched the social impact, a completely remote working environment can have on people. At Doist, they are aware of the potential issues, which can arise in an isolated space like your own four walls and hence promote actively awareness and measures against it, to counter these effects on their employees.

Side effects

Random work has its challenges (as seen above), however there are certain advantages mentioned by almost all articles I've read. Less commuting means more time throughout the day and being home earlier. Seeing remote work as the default compared to onsite workshops spares everybody airplane flights. For company owners, remote teams mean no cost for office space and furniture.

In 2019, I cannot finish on the topic without mentioning, that the time and resources reduced, directly result in a reduction of the the carbon footprint and hence helps our planet.

Conclusion

I like working remotely and I like it more than working in an office. I am writing this, while never working longer remotely than two or three weeks in a row. However, reading on the matter makes me think that I will enjoy it much longer, while knowing that frustration can arise when stuff like proactive communication is not lived throughout the team or company.

In case you have any feedback, I would be happy to hear it @svenhennessen on Twitter.

Have fun working remotely, cheers!

Sources

• Atlassian: Remote Teams
• Zapier: Remote Work
• X-Team: Communication
• GrooveHQ: Being a remote team
• InnoQ: Remote Mob Programming
• InnoQ Podcast: Remote Mob Programming
• Doist: Asynchronous Communication
• GitLab: The Remote Manifesto
• Doist: Mental Health and Remote Work
• Wikipedia: Conway's law
• Wikipedia: Asynchronous Communication
• Wikipedia: Hanlon's Razor
• Zapier: Buddies