Designing with Remote Teams

This article is an excerpt from Jeff Gothelf book Lean UX.

As the author of a book on collaboration—that touts the benefits of collocated teams—the reality of distributed teams is not lost on me. In fact one of the main questions I get asked each time I present on Lean UX is how to make it work with remote teams. While the benefits of in-person collaboration and communication are clear, it doesn’t mean they can’t be achieved with remote colleagues.

There’s been no shortage of coverage lately about the different strategies companies employ when it comes to their distributed work force. Certain companies, like Automattic—makers of WordPress, have an entirely remote workforce and swear it’s the only way to work. Other companies, like Yahoo!, have made headlines recently when CEO Marissa Mayer demanded all remote employees come back to the office. LivingSocial has promoted a distributed team environment under the leadership of now-departed SVP of Technology Chad Fowler. The poster children for distributed teams, 37 Signals, swear by this approach to the point that they’ve written a book on the topic. What has been missing from the conversation to date is context—the context of the work these companies are doing and the context of their current environments.

Let’s Look a Little Deeper

In Yahoo!’s case, Mayer asked roughly 500 people (out of a workforce of over 11,000 employees) to stop working from home. This is indicative of a subset of the workforce that has split from the hive and clearly wasn’t providing the same quality of work as their office-bound counterparts. What was happening here was what Jason Fried warns about—the creation of a “here” culture and a “there” culture. In an interview in Quartz magazine, Fried says:

A big part of it in my opinion it comes down to culture. If you have one remote worker and 35 local workers, that’s a problem because there’s a real disconnect between people at the office and that one lone person. The culture splinters into the “here” culture and the “there” culture. It becomes almost like there are two companies, and that’s what you have to avoid.

Yahoo!’s culture, as it currently stands, is clearly a “here” culture and needs to stay that way in order to right their lilting ship (according to their CEO).

In the case of companies like Automattic, there has never been a “here” culture. From their inception they’ve built a “there” culture and assimilated new hires into that context. They do this through an initial trial on-boarding project with a new employee and, if that works well, they transition into a full-time role. That is their normal context and clearly it’s been working for them.

What’s interesting, even the most ardent promoter of remote working—the aforementioned Mr. Fried—speaks to the demands of context when it comes to working face to face or not. When a new employee joins 37 Signals, they bring her into the office for a month to gain a sense of how this new person works, what their strengths and weaknesses are and, perhaps most importantly, to establish a familiar bond with the new hire. It’s this bond that translates into a more successful remote relationship, they’ve found.

In another context, there may be a project that requires an intensive dose of collaborative thinking. In these situations, the 37 Signals team gets together in person to generate this creative spark for a period of time (a few days or a week) before departing with the output of that session to their remote offices.

It seems that, as with most things design and UX, the answer to the question, “Does remote working work for software development teams?” is, it depends. Context and culture seem to be the determining factors but there’s another sub-element of culture that can’t be ignored: trust—specifically the trust between managers and their employees.

Fried continues, “A big part of it comes down to trust?we’ve found that companies that work remotely trust their employees more. And what’s interesting about that is that when you’re trusted more as an employee, you work better.”

In February 2013, I ran a brief and informal (read: unscientific) online survey to gain a sense of how prevalent remote working was in my tech circles. 108 people responded. Here are some of the results of the survey:

43% of respondents were designers

32% of respondents were engineers

12% of respondents were product managers

The rest were distributed between C-level executives, other managers, coaches, QA, project managers and copywriters.

Amongst all the respondents there was an average tenure, in the tech industry, of about 11 years.

Here’s the interesting fact: 100% (yes, everyone) of respondents were currently working with or had recently worked with a distributed team. In other words, this is a reality for all of us today.

There were at least 5 remote team members for every respondent on average. This means that on an average, 2-pizza team (i.e., a team you can feed with two pizzas), at least half the team is split from the other.

The most fascinating insight for me was the distribution of respondents who said they’d be happy to continue working with distributed teams. Only 55% said they’d want to do it again. The other 45% said they’d much rather collaborate with their colleagues in person on a regular basis.

Let’s take a look at some of the biggest challenges the respondents listed for remote collaboration. Then we’ll dive into specific ways to solve some of these challenges.

1. Poor Communication—this was, by far, the biggest complaint for distributed teams. Colleagues felt like they were not included in decision-making activities and were unclear why those decisions were even being considered. They didn’t know their colleagues that well and felt awkward interrupting them during the day and providing critique on their work.
2. Slow progress—many respondents complained that their teams felt like they were moving slower. At the very least it was clear that the perception was one of slower progress.
3. No team-building or camaraderie—some team members never meet in real life. Without some level of shared experience outside the realm of “the project” there was a distinct lack of camaraderie amongst remote teammates. We spend the majority of our awake time working. For many folks, this is their only social outlet. When the office component is removed, all that’s left is the work. Jason Fried touts this as a benefit as it leaves nothing but the work to judge the merits of an employee’s contribution. However, for many folks this is starkly missing from their work experience.
4. Lack of collaboration—different time zones, languages, priorities and obligations leave many distributed teams working on their own. Productivity may soar in these situations but many survey respondents seem to miss collaborating with their colleagues.
5. Language and culture barriers with team members in other countries—while this can certainly fall into the poor communication bucket, the challenges with foreign colleagues are unique enough to warrant their own category. Building rapport with colleagues from your own country can be difficult enough. When you need to build that rapport with colleagues who speak a different language, follow different customs and have culturally-different approaches to work it becomes exponentially more difficult.

These are only five of the big issues teams have when working in distributed situations. It’s in no way a complete list but, from my survey, these are the biggest challenges.