Teams working remotely is more common then ever. The combination of flexibility, high speed Internet, and the right tools make working remotely a viable option for may teams. It has given rise to a whole generation of people that not only can work remotely, they expect it.

What do I know about working remotely? I’ve worked successfully in a remote capacity for almost 3 years. In that time, I traveled around the world with a program called Remote Year while working remotely. I am passionate about fostering a culture that allows remote teams not only work together, but thrive.

Here are the 4 traits that are absolutely essential to fostering a healthy (remote) work culture.

1. Open communication

By far the most important part of a successful remote work culture is open communication. What do I mean by this? Think about how a traditional office operates. There are conversations that happen in the hallway, at the water cooler, in meetings, in the cafeteria. Sometimes the conversation is casual but other times its important work stuff that should be shared with your co-workers.

I can’t tell you how many times in the past I’ve made some big technical decisions by bumping into a senior engineer in the hallway and asking his advice. Sometimes bouncing ideas off other people helps you solve a problem.

In fact, this is the #1 reason companies like to co-locate and put everyone in a single space. This is good for fostering ideas and innovation, but very bad for solving hard problems that require Deep Work.

Making important decisions without review among your peers is often a bad idea. Ideally the whole core engineering staff would also be involved at some level to validate ideas. In a traditional office, this usually means meetings. However, it’s pretty well understood that meetings are a colossal waste of time and resources.

The solution in a remote work environment is open communication using asynchronous tools. For software development, this often includes tools such as:

  • Slack (asynchronous chat)
  • Github (asynchronous software review)
  • JIRA (asynchronous planning)
  • Google Hangouts (synchronous meetings)

You can swap any of these out for your tool set of choice. By far the most import part of this whole section is this:

Using public forums and for most conversations

I’ll stress this again, have conversations in a public place! Avoid direct messages like the plague. DM’s should not be used unless absolutely necessary, and the information needs to be private with that individual.

When a new employee comes on board, it can be tempting to use DM’s because he or she might be intimidated by asking “stupid questions” in a public forum. But, it needs to be stressed to them that having discussions in public is essential.

There are several advantages of using public channels vs. private channels or direct messages:

Avoiding redundancy

There is nothing more annoying or inefficient than repeating the same question or relaying the exact information to 3, 4, 5, or 50 people over and over again. Why not just say it once in a public channel?

Open accountability

Is the boss wondering what you are working on or why a project is taking so long? Instead of harassing you on a regular interval, all they have to do is catch up on the public channels. At that point they can see what is going and if they want to step in to help.

Knowledge sharing

I once worked with a senior engineer that refused to share any of his knowledge with anyone. Something broken? He’ll fix it for you, but won’t tell you how he did. This is a horrible engineering culture, and its actually really bad for the company. What if he leaves the company? It puts the company is a bad position.

People like to learn new things. Found out a better way to deploy your code? Share it with the team.

2. Accountability

Something that holds bigger or more traditional companies back from allowing their employees to work part or full time remote is accountability. The belief goes that if employees are being “watched” in the office they will slack off.

The truth is, if you have hired the right people, the opposite will be true. In fact, there are a lot of studies that show that people are actually more productive when they are free from the distractions of the office.

So how do you stay accountable as an employee? Here are some ideas to build an accountable culture.

  • Daily standups. A 15 minute synchronous meeting serves as face time for the team to talk about what they are working on today and if there are any blockers. You can also have a #daily-standup channel to provide more detail on Slack.
  • Daily announcements. This channel is to let people know when you aren’t working. Have to run some errands or want to do some laundry? No problem, let the team know in this channel, and when you are back working let them know again. No need to bother people, but if they want to know where you are, it should be in this channel.
  • Task tracking. I won’t get into the whole Agile methodology here, but I want to emphasize that your team should break tasks out into small, manageable chunks. This should improve velocity and allow for quick wins. Also, surveys show that engineers are happier when they are deploying code often. As a general rule of thumb, try to make tasks that take no longer than 3 days to complete.
  • Schedule push. If something is going to take longer than expected, report this early on. Make it known in a public slack channel so there are no surprises and get someone to help.

3. Batching Tasks

Schedule meetings in chunks to allow for proper Deep Work time. Ever wonder why Hackathons exist? Its because of the simple fact that people are more productive with uninterrupted time to focus on their work. .

There is a great article I read I while back that talks about the two types of people in a company: the managers and the makers. The Managers have their whole day booked up, meeting after meeting, jumping from one thing to the next. Their work often requires scheduling, high level oversight, meeting with clients or other managers. If the work they are doing doesn’t require Deep Work, this is a fine thing.

The Makers on the other hand require time for Deep Work to truly be productive. Jumping from one task to the next is counter productive as an engineer. This is part of the reason why many software developers report doing their best work late at night. The Managers should keep this in mind and try to batch weekly meetings all on one day, and keep other meetings during the week to a specific chunk of time, such as 9 - 12am, and leave the afternoon for engineering work.

In my last job, I often railed back at the constant stream of meetings. I like to use the analogy of comparing software development to driving a manual transmission car.

My best work is done when I’m in 6th gear. But to get to 6th gear I have to go through all of the gears: 1st, 2nd, 3rd, 4th, 5th, and then 6th. When I’m in 6th gear I am “in the zone” or “in flow”. If I get interrupted while I’m in any of the gears and have to switch tasks, I have to restart in 1st gear and work my way up again, similar to having to stop a car at a stop sign.

4. Innovative and Open Culture

The best ideas can come from anywhere. They can come from the CEO, or from the Jr. Engineer that was just hired. Different people in the company have different perspectives on how things work, and may have an idea to improve or help grow the company. It’s important to encourage an environment of innovation, and one that allows everyone to put their ideas in a public space, without fear. Even if the idea will never be implemented, its important to hear ideas from all sides.

Some of my best work has come from this kind of innovative culture. Most companies have some sort of road map that is broken up into tasks, with some schedule on how to get there. The thing is, once engineering starts gaining a deeper understanding of how to solve the problem, there may be alternative approaches that drastically improve the product. This applies particularly in the technology industry which is changing constantly.

I remember when I first discovered Kibana for Elastic Search. At the time the company had a lot of data that was sitting around in raw files, S3, or a SQL database. While doing some data analysis for the CEO, I stumbled upon the out-of-the-box visualization capabilities of Kibana. I read up on it, started indexing the data to Elastic Search, and created some basic visualizations with Kibana.

When I first told my boss about this, he was frustrated that I wasn’t working on my assigned tasks and that I was “wasting” my time playing with this new technology. However, as soon as I demonstrated this to my boss and relevant stakeholders they were blown away with the capabilities. This side project alone opened up an entire new capability to the company and our customers, and helped to propel the company’s technology in to the future.

Call to Action

If you work in a remote culture, or even an office culture, pick one of these traits and see how your company culture stacks up. If the company is lacking in one of these areas, lead by example. Start sharing things in public, share your ideas, and encourage others to do the same. Another idea is to get the buy in of the leadership team, point them to this article and convince them to give it a try for a quarter.