Three problems with remote teams

Jun 04, 2015

I’ve been working in a remote position for almost two years now. For the most part, I really like the dynamic, but I still have a few reservations about working in a distributed or remote team for a large company. Although these types of concern have already been well enumerated by others (the Remotive mailing list is a boon for those interested), I thought I’d share some of mine anyway – not just for the benefit of others, but also for my own peace of mind.

Most of the challenges which prevent a remote team from being successful are derived from a mismatch between local team policies and the internal culture of the parent company itself. If a remote-friendly culture is not adopted systematically, it will either be doomed to failure, or cause those on the periphery to feel excluded, isolated, and inefficient. It’s worth covering some of the ways an existent culture – either implicitly or explicitly – can scupper new attempts to welcome remote working.

The first is ineffective communication, namely the inability or refusal of other teams to respond effectively to remoters over electronic media. If somebody has a question, query, issue or problem, the only way they can communicate that is through a cable; they can’t stroll over and get an instant answer. They can’t rely on chumminess, body language, or tone. This immediately puts them at a disadvantage to on-site workers, and the problem is compounded when the recipient team’s response is neither helpful or prompt. There are many reasons why this might happen: they might be busy, they might not understand the question, they might not know the answer, they may not consider it a big enough priority. But regardless of how you spin it, the question from a colleague should always be answered because the net result is mutually beneficial.

The second problem I usually face in a remote team is the prevalence of opaque knowledge and hidden networks. For example, the other day a customer reached out with a problem they were having with SSL and an API. I had no idea about the cause, so pinged the (what I thought) relevant team who could help. Upon doing this, I was told it was not their problem, and to “open a ticket” for another team with an email address I had never heard of. That was the proposed solution. But there was absolutely no attempt to answer the implicit questions: Who should open the ticket: coworker or customer? How does one open a ticket? What is the necessary URL? Who is the team that will answer? What is their remit? What extra information is required from the customer? How can I keep up to date with this issue once the ticket is logged? Why is this issue not relevant to your team? The problem I have with this kind of interaction is that exemplifies how you assume people know the same things you do, which is almost never the case. Don’t ever assume that something is obvious or easy to grasp; take the time to explain and make it transparent – especially to newcomers or remote workers. If you don’t know whether they know, ask them!

It’s also worthwhile documenting knowledge so it is retained because it enables people to easily query and retrieve the relevant details about a particular process or workflow, rather than chasing ephemeral tips. For me, the ease of knowledge sharing and the ease of knowledge assimilation is directly related to how successful a team operates. If you want a company to be remote-friendly, actually make an effort to document and make the documentation assumption-free. Nobody wants to be walled off from a closed silo. Instead, we need an open proliferation of knowledge that empowers us to get things done.

The final problem I usually find with remote teams is the amount of closed-door decisions and timezone-insensitive conferences that percolate through a company. One of the lines I always remember from the West Wing is “Decisions are made by those that show up”, but the more I work remotely, the more I struggle with that idea. It’s so easy to hold discussions and forge decisions out of a central office or HQ, and oftentimes many people don’t batter an eyelid about doing so. But not everybody has the privilege of being in that room. With the onset of video conferencing technologies, there really is no excuse anymore to not bring in a wider audience and share those critical decisions with them. If you want to create a remote-friendly workplace, you need to be prepared to democratize your decision making by making it available and transparent to those not there. And for geographically distributed teams, you need to make an effort to schedule meetings that are sensitive to timezone differences. If you schedule a team meeting (or any kind of meeting which touches or affects another coworker) after 6PM their time, it’s inherently disrespectful: it shows that their situation either wasn’t important enough to be remembered, or important enough to be factored in.

It’s often said that for remote working to work, it needs to be adopted by the entire parent company, and I completely agree with this. I’m tired of seeing companies profess to support distributed and remote teams, but making no effort to adjust their culture. In fact, I’d go so far as to accuse them of being negligent towards their employees. We don’t need inertia, reluctance and excuses; we want proactive change and flexibility.