Distributed, Not Remote
This post was originally published on CIO.com on December 23rd, 2019.
Times they are a’ changing…
Ok, not in the sense of the Bob Dylan song necessarily, but the availability of working outside of a traditional “everyone in one office” environment has changed radically over the past few years. There are companies who have been doing this for a long time. I first started managing a remote team in 2001. I had folks in Europe, Hawaii, and up and down the west coast of the United States. A lot has changed since those days.
My team started out with IRC and then moved to Jabber because it had support for SSL so we could exchange secrets. We made heavy use of Skype. Now there is Slack, Zoom, and Microsoft Teams, but many of the same ideas apply, some are even better.
Today having the ability to work with teams and people around the world is becoming more and more popular. Maybe your company wants access to talent in places they don’t have a traditional office. Maybe your company operates in many different geographies. Maybe your company was founded to be 100% distributed!
Regardless of the reason, there is no question that distributed teams are far more commonplace than they were in 2001. There are many challenges to working in this manner, and there are many things that we can do to make such teams successful.
As the expression goes, nothing good is easy. There are huge advantages but there are also a number of challenges to being successful with this style of work.
If you’re a company which has a very heavy headquarters culture, it may be difficult for those not located at HQ to advance effectively in the company. So many of the key things that happen take place there, the executives are there, most decisions are made there. It can be a challenge for those in other offices or locations to make their contributions and ideas known. Often, many more promotions happen for those located at HQ than in other places. It’s important that we are conscious of this situation if we want our high performers, wherever they may be, to be recognized for their excellent work. Similarly, we need to make sure that those who are struggling, get the support they need so they can continue to be valuable members of our organizations.
Ultimately the success of our organizations falls heavily on the performance of our teams. There can be a number of challenges for teams, especially if the majority of a team is located in an office, and there are a few team members in other locations. This is why the title of this article is Distributed, Not Remote. We want to think about the team as being distributed. If we think about having “regular” employees and “remote” employees, this creates bad dynamics for the team. It establishes a hierarchy of those who communicate freely where others cannot participate, and those who are struggling to be part of the same conversation.
But working on distributed teams can be difficult even if we make the effort to communicate openly as language can be a difficult form of communication. We’ve all seen emails that seemed innocuous enough, and then witnessed someone respond horribly offended because they interpreted a phrase much differently than everyone else. Sarcasm ALWAYS comes through perfectly in text form and is ALWAYS read and appreciated as intended.
I remember a comic strip when I was a child where the two characters were sitting back to back and one looking down at an injury on their leg said “I gotta scratch” to which the other responded “So go ahead!”.
Distributed teams can also be hard for junior staff. Before any team takes on junior members, they should be well aware of the amount of (worthwhile) work required to bring those members up to speed. When someone is located at home, or in an office overseas, this can be a big challenge. Additionally, a big part of being junior staff is learning how to work, not just the work itself. If you are just getting started with your career, and you’re trying to work from your kitchen, and you have roommates, and the dishes are piled up in the sink, and you have a lot of laundry to do, it can be a challenge to get the long blocks of sustained time required to be truly effective.
There can be many challenges working on a distributed team. But there are many ways to make those teams more effective.
One remote, all remote
The first rule most successful remote teams follow is, one remote, all remote. That is, the entire team needs to adopt the mentality of a distributed team no matter where they happen to be working. If you’re fortunate enough to work for a company that is flexible about whether or not you need to be in the office every day, you already have an advantage in this thinking.
If you’re having a conversation with the person in the next cubicle, which is probably relevant to the team at large, one needs to be cognizant of this fact and take it into a forum that is visible to the entire team, wherever they are. If you are in a private office talking to one of your managers about who should be promoted, obviously those conversations don’t belong out in the open. But if people are making an architecture decision that the team will have to support for the next few years, that can’t be something relayed at a later time.
Making Work Visible
It is not only being cognizant of having all team members participate that allows distributed teams to be successful. One of the easiest ways to be transparent with information is to make it a normal part of how teams work, by making work visible.
There are many ways to make this information visible. I’ve used Slack, Teams, etc. to involve everyone in the conversation. For US employees with team members in Europe or Asia, they at least have a chance to see the topic being discussed and can contribute their thoughts and ideas when they are awake and at their computer (or if they so choose to contribute on their mobile devices, as long as that is not expected).
When working at Salesforce, we used a tool called Chatter that was a bit like business Facebook. We would start a conversation on a topic and over the course of the next 24 hours, teams from all over the world would contribute their ideas in a threaded conversation. People could “like” posts to express their support, or they could link to documentation, etc. to give others in the thread more information about the solution that was being proposed.
Of course, all these tools have great search capabilities so that if one wanted to go back and see what the reasons were behind a decision made or an action taken, it was self-documented.
Successful engineering and operations teams take this concept a step further! They practice ChatOps in which not only the discussions and decisions happen in Slack and Teams but the actual work itself.
They set up chat bots like Lita, Errbot, and Hubot, which allow them to take actions directly in chat. This can be things like silencing alerts, or asking for a graph of CPU utilization, but it can also be things like deployments. This is a great way to give a unified interface for doing deployments as the commands used for the deploy can be different in the backend code depending on what kind of deployment we are performing (container, JAR, schema change, etc.)
These teams will also put a lot of effort into custom emoji that reflect the culture of the team and the company. This can often make communicating much simpler and easier. A well placed emoji or meme in response to an event or statement can quickly communicate a long history of common understanding.
Our Agile tools are also excellent ways to make our work visible. A sprint or kanban board allows anyone to see work in progress and anything that has been stalled or blocked. There is no need for worthless “status report” meetings to find out what has been accomplished on some component of a project. Anyone, anywhere, can find out the status of a component by bringing up the board. The better teams who take advantage of integrations between tools like Jira and Github even have the ability to drill down into individual commits related to a work item, and see the exact code that has been developed to meet a business need.
Nothing about these tools or this kind of integration requires people to be colocated in the same office, or even the same country.
Another property of remote work is presence. The ability to meaningfully connect on a human level with other team members over distance.
As we learned from Google’s re:Work project, psychological safety is the most important indicator of high performing teams. Gene Kim even highlights this in his most recent novel The Unicorn Project as the 4th of the Five Ideals. But how to foster psychological safety on a distributed team?
One method I’ve found effective for such teams is to use the Agile daily standup to foster friendships and familiarity between team members. We all know that the cardinal rule of standup is to make it as quick and effective as possible. Then the meeting ends. With distributed teams, there can be other goals as well. For my distributed SRE teams, I always let standup include a good amount of banter and chatter before the meeting got started. Instead of standup starting at the top of the hour, maybe it actually got started at 10 after the hour. During those ten minutes, we heard about pregnancy announcements, or the neighbor who set their house on fire by using a circular saw improperly, or how close someone was to graduation from their night courses. The point of this time was to create personal connections on the team. Knowing the other members of the team on a personal level was critical for those times where there were differences of opinion on technical topics and each team member had to understand that everyone was participating with their best intentions.
But even the physical environment can help to foster these feelings.
It was just another day in the office until we saw the UX design team moving furniture around. No, this was not a common occurrence. They had taken some chairs from one of the small meeting rooms that had been setup with a nice mic, an HD webcam, and a TV. They were replacing it with a couch and some plants from another part of the office. “Oh, it’s just those crazy artist types doing their thing” thought all the engineers. However, what we came to discover, was that that small meeting room now felt like a living room. People felt very comfortable in there and it was reflected during meetings. Many who follow the “one remote, all remote” philosophy will eschew meetings where those in the office will sit in the big, antiseptic, conference room. Instead, everyone will do the meeting from their desk so that everyone will be on equal footing.
But the people who work from home are not in an antiseptic environment. They have specifically constructed an environment where they are comfortable. By interacting with co-located team members who are in more of a living room setting, everyone is put at ease and the conversation flows freely. Those in the room still need to be mindful to watch or listen for clues that those who are not in the office want to contribute, sometimes they even need to consciously ask for input. But, by creating a relaxed dynamic for discussion, we can allow for the benefits of psychological safety to benefit the whole team.
That does not mean that all meetings need to take place in a living room setting, as desirable as that may be, but when working as a distributed team, members should feel free to have one on one meetings whenever the need arises. Just as you would feel comfortable turning to the person in the next cubicle as asking “What do you think about the proposed caching strategy?”, that bar should be equally low with distributed team members. Sending direct message in Slack asking “Got a few minutes to talk about the proposed caching strategy?” should be neither weird nor unwelcome.
I wrote that the “living room” was set up with a nice HD webcam. I also wrote on Twitter a few weeks ago that I thought all business meetings should be video meetings. Why is this so important? As I’ve spoken about at a number of conferences, human beings have specialized neurons called mirror neurons. When we witness someone else experience something, the neurons in our own brains that would respond to that same experience also fire. It is almost as if we are experiencing that same thing ourselves. I believe that this activation is crucial to developing empathy with, and understanding of, other people. If that is the case, then adding a webcam to our conversations instead of simply using audio, allows us to build deeper connections with others, which also contributes to psychological safety.
The ability to see the expression on another’s face, or their body language during a conversation, allows us to collect so much more information than we would with simple audio or even text. This is not the same as sitting down for a team lunch together or anything like that, but it is an effective way to use non-verbal communication.
One non-verbal technique I learned from a brilliant software engineer was the “thumbs up” sign. In chat, you can often see folks react to a statement with a thumbs up emoji to express agreement. During group discussions over video conference, this can be effective as well. Instead of interrupting the speaker to say that you agree or disagree with an idea expressed, one can nod or give a thumbs up or thumbs down sign to the camera, to express to all participating, agreement or disagreement with that idea. This is something that is simply not possible with audio only communication.
Some companies have taken the idea of remote presence to a new level with the use of robots! I remember the strange feeling of seeing one of these robots roll down the hall to a conference room and saying hello to the person on the screen as I opened the door for them to roll to their place at the table for the discussion. That is really being welcoming to distributed team members!
While encouraging distributed teams and team members to participate over many different mediums, there is still often a need to share time together in a common space to build those strong interpersonal relationships that are difficult to forge any other way. For this reason, many high performing distributed teams will gather once or a few times a year, in the same location.
Whether it’s happy hour, cooking classes, or going to the gun range, being able to spend time in person, with people with whom you spend so much time online, can have a great effect on team cohesiveness. While hack events (hack days, hack weeks) can be great collaboration builders in a distributed manner, there is also something special about friendly competition among engineers, accompanied by lots of cheering, encouragement, and laughs when the demo at the end of the hackday doesn’t work quite right for a team.
We’ve talked about how thinking of our team as distributed and not remote is important, but how does this apply to DevOps? We already know that when we build bridges between our Operations and Engineering teams, we get better results. This is proven every year in the State of DevOps report. What we also know from neuroscience is that people behave differently in the presence of those that they consider in an “out group”, that is, someone they do not consider to be in the same group as themselves. If we were to draw a distinction that there are employees who are in a specific office, and there are employees who are “remote”, we are drawing a line that divides “in groups” and “out groups” within our own teams. There is a lot of scientific literature that supports this. If instead, we think about our team as being distributed, then we are essentially creating one group, of which we all are a part.
When we are talking about diversity and inclusion in the workplace, we discuss this problem as “othering”. When we see people as the other, that is, not a part of our same group, and we are not accepting of others, then various undesirable results can occur. Instead, if we want to build and maintain high performing distributed teams, we need to think about how to expand our “in group” so that all team members can participate equally, regardless of their physical location.
It has been a great almost 20 years watching the rise of distributed teams, especially in the technology space. What started out as an exercise for the bold that arose out of the pure necessity of operating around the globe, has turned into a major advantage for companies who are willing to make the investment in enabling distributed work to be done properly.
Companies that embrace this strategic advantage are able to find, develop, and maintain talent wherever they happen to be located, instead of being restricted to a few geographies where the competition for talent can be fierce and expensive. By taking advantage of the great tools and learnings about the culture of distributed teams, we can give our businesses a leg up on the competition, and set ourselves up for the win.