Hidden danger for remote-first development teams
The SARS-CoV-2 outbreak forces many companies to jump into the new reality when many (if not all) employees are working from home. The remote work movement was not invented just today. But this is the first time in the history of mankind, when such a new and radical concept would be adopted by thousands of companies around the globe in a matter of months, if not weeks. When everybody works from home and your office is empty, you have no other option, but to adapt quickly. Conventionally, software development companies are more agile than traditional ones. They can react faster in a constantly changing environment. But still, for many tech businesses that would be groundbreaking changes.

But it’s a blessing in disguise.

In these new conditions, it’s not enough to close the office, let employees go home, and pretend that nothing happened. To survive and thrive companies left with no option but to accept the remote-first culture. Remote-first means that you build your entire company life around the fact, that your team consists of remote workers, regardless of whether or not they are actually remote. Here’s a nice write up by Zach Holman on the difference between remote-first and remote-friendly terms.

Transitioning to remote-first introduce an opportunity to review the present (sometimes “legacy”) processes, accumulated over many years, and start getting rid of outdated things, like overcrowded unnecessary meetings. When your company is fully distributed, when communication starts to be boundary-less, when there are employees from different time zones working together, then old rusty rules fall apart.

Obviously, remote-first culture is not a panacea. There are a lot of drawbacks and challenges for the company and its employees.

At the same time, there are many more benefits. Kudos to GitLab — the truly remote-first startup since the day one. They have written an excellent guide to all-remote work. Or read one more from Zapier.

To make the transition smoother and still be productive, there are dozens of tools created with remote work in mind, like zoom, slack, trello, etc. Folks from close.com made a pretty comprehensive list of tools and apps which are perfectly fit for tech companies. It’s natural, that most of the apps in the list relate to collaboration and documentation. For remote teams, knowledge management and cooperation becomes a necessity. But there’s a hidden danger.

 

Your internal knowledge is at risk to be spread across multiple places

When the engineering team works in the office, the internal, what is called “tribal”, knowledge propagates freely via verbal communication. Either around the watercooler, on hallways, at meetings or on 1-on-1s. In fact, this is a big concern. Software development industry even have a term for that — the Bus Factor. But it’s somewhat tolerable when all teammates work in the office, are in sight and easily reachable right away.

For remote developers, and especially for remote-first engineering teams with the flexible schedule, different timezones, the technical project knowledge oftentimes is chopped up in little pieces and distributed across many tools:

  • For projects that require heavy communication, videoconferencing is a natural choice. Now you need to find a way to disseminate information from video meetings. The rule of thumb here is to record all the meetings and publish it internally to later viewing for those, who missed or is in another timezone. Now you have lots of video files to deal with.
  • For brainstorms, planning meetings, retrospectives, daily’s, the summary is usually stored in knowledge bases (like Confluence), online editors (like Google Docs) or note-taking apps (like Notion).
  • Issues, an important source of knowledge in the development lifecycle, are gathered in issue trackers (like Jira) or project management tools (like Asana).
  • Ad-hoc chats and general discussions in Slack, conversations in email. There are lots of small dialogues here and there.

At the end of the day, It seems that everything is documented, since every piece of information is stored and accessible online. But to gather the whole picture it’s now necessary to assemble every piece of information from dozens of places.

 

Not every engineer is an archeologist

It is important not to overlook the moment when all your documentation turns into a mess. Generally, it’s a good idea to put some effort to keep a central index or table of contents of every type and piece of documentation you have. This could be the wiki, simple MD file, company-wide Notion, Dropbox, whatever. Gather and link your files, Google Drive documents, GitHub pull requests descriptions and discussions directly with the code with Nots.io — the tool that we made for engineering teams to find answers directly from the code. You have plenty of options!

The key ingredient here is to make all your docs and information you have available for developers and everybody in the team in a few clicks from one place. Having company knowledge at the fingertips boosts productivity and gets every remote person on the same page. For newcomers joining in, this would make onboarding as smooth as possible. Easy accessible company’s knowledge and documentation help orient them faster without distracting colleagues. In Nots we are firm believers that for the knowledge you need to do your job should be easily explorable, trustworthy, reachable with few hops, helpful and suggest a collaboration.