Over the past eight years, I’ve had the privilege to be part of Upwork—a company that, from its inception, has embraced distributed teams and distributed work. What’s more, our mission is to remove the barriers of offices and borders for those seeking and providing skilled work. We live this culture. Currently, we collaborate with highly skilled independent professionals from 45 countries. They work on projects that that help design, build, promote, and operate Upwork. We have only three major offices, in San Francisco, CA; Mountain View, CA (our headquarters); and Chicago, IL. Everyone else works from their locations around the world.
Before Upwork, I was Director of User Interface Engineering at Netflix, where I lead a team that crafted a world-class and well-loved website. The policy at Netflix was we were an on-site engineering team, with the exception of Tuesdays.
Flash forward to 2009 when I joined oDesk, now Upwork, after cofounding a startup which sought to change how people found work and sourced talent. Upwork was an entirely different scenario as the company was founded on the idea of working with distributed teams. And I was thrown into the deep end with no experience or training in how to successfully lead distributed teams. Since then, I’ve been building and leading a distributed set of engineering teams, working from over 100 cities. I’ve had successes and failures as I try to continually improve our team. I’m going to share some of these experiences with you and show how they impacted our broadly distributed team.
Leading distributed teams effectively has many facets that need detailed consideration. A single article can’t address this breadth in a meaningful way. Instead, I’ll address the components in a series, looking at one or two specific elements in each article. Today I’ll start at the beginning, with terminology.
Distributed teams are superior to remote teams
Entrepreneurs, executives, and managers often have the same problem: They need a strong team to bring a compelling vision to life. The best teams I’ve worked with are extremely creative and collaborative throughout their processes. They keep order-taking to a minimum. This type of behavior comes naturally when everyone is in the same building. But what about a distributed team? As it turns out, a team that is separated by distance and time zones can collaborate equally effectively. In fact, a practiced distributed team can be more effective than a co-located team because the need for physical presence becomes insignificant.
Referring to part of a team as remote and part as local creates a cognitive bias against the remote team members.
Until now, you’ll notice I’ve used the term distributed. The majority of articles you’ll read and people you’ll hear speak about this subject refer to the act of working with talent outside of your office as remote talent and building remote teams. While technically correct, these terms often have negative connotations. That’s why I favor distributed teams. I certainly don’t like to use remote to describe our culture here at Upwork. When referring to part of a team as remote and part as local, you’re creating a cognitive bias against the remote team members. You subtly imply an us-and-them arrangement that centralizes decision-making powers with the local team.
Our cofounder Stratis Karamanlakis works from his home in Athens, Greece. He’s a strong voice in both strategic and tactical decisions. He’s our chief architect and CTO. This means that the ownership of several facets of Upwork doesn’t come out of headquarters. Instead, it comes from a small home office 11,000 km away. Yet one would never consider Stratis a remote worker. To consider him and other members of distributed teams as remote does a disservice to them, their incredible commitment, and their contribution to Upwork’s success.
You might think that something as seemingly minor as terminology cannot have that much of an effect on a team’s ability to collaborate successfully. But despite the initial intent to have the entire team improve the company’s potential, terminology can lead to small, seemingly inconsequential, efficiency-based decisions that ultimately undermine true collaboration in favor of the local team.
For instance, I regularly hear comments such as “It’s easier to solve this problem in the office and give it to the remote team to build” and “The remote team is busy. I don’t want them distracted” and “I don’t have time to involve the remote team.” There are many more examples that follow the theme of avoiding distraction and gaining efficiency. When the team optimizes for efficiency, however, these nuances won’t be shared. The collaboration then evolves into one with a hand-off nature. Specifications will then have to be extremely detailed to communicate information that should have been shared initially with the relevant team members regardless of their location. Information gaps develop, and the ability to anticipate diminishes.
This creates a slow, vicious cycle that erodes context, communication, and trust. Over time, it creates a disconnect between the local and remote team. Increasingly, this limits the so-called remote team to the role of task-taker and creates a knowledge gap that will cripple the team. The team’s effectiveness is then tarnished in the eye of the business.
A distributed team doesn’t evoke the same cognitive biases. Instead it places everyone on the team on equal footing. With a distributed team, you won’t find hierarchy in the label or a power center engrained in the descriptor. When using remote team and local team, the emphasis is on the key differentiator, the location. That is not the case when referring to a distributed team. Instead, the implication is that everyone has their place, and it’s important to the team to solve its problems as a single unit. Another perspective is that working as part of a distributed team enables everyone to act as if nobody on the team shares a location with other members. This forces positive, inclusive behaviors.
To revisit the examples above, distributed teams don’t optimize for micro-efficiencies. Instead, they identify problems and solutions inclusively. The outcome is a far more capable team that has a comprehensive understanding of a problem’s nuances. The team leverages this to create more-effective solutions, which in turn bolster the strength of development, delivery, and future iteration. The strong outcome isn’t just present in the project at hand. It builds a basis that helps everyone on the team anticipate future challenges.
How we walk the talk
At Upwork, we have engineering teams that exist as fully distributed entities. This means that no members work in the same location as any other members. Leadership, developers, and QA are all distributed. We do have product managers and designers who are located in the same geographic market, but they might or might not be physically in the same office during the course of a week. Our distributed engineering teams own significant chunks of our architecture and user-facing pages. The teams are responsible for the system architecture, delivery of our features, performance, maintainability, bugs, and responding to site incidents. It is critically important that these distributed teams are effective so that we can meet our goals.
Our teams need to be continually mindful of how they are operating. Regardless of location, operating efficiency is always a topic of conversation. After all, there’s continuous business pressure to move fast. At the same time, it’s dangerous when decisions are made that optimize for efficiency at the expense of inclusion. As I mentioned above, this begins to fracture the team. An engineer’s perspective provides a ton of value in early research and design conversations. Additionally, involving QA in these same conversations from the beginning expands the team’s capability beyond functional testing. Keeping the entire team involved is a huge aspect of developing and maintaining a successful team.
Obviously terminology is just a first step in framing how a distributed team is perceived. Perception—internal and external—can be critical to a strong distributed-team culture and contribute to successful collaboration and team results. Going a step further, we’ll look at the strategies which further cultivate healthy behaviors and improve a team’s effectiveness in the next article, part 2 in this series.
I want to acknowledge and say thank you to my colleagues, Han-Shen Yuan and Barry Enderwick, for their perspectives and support in kickstarting this series.
The post Why Effective Distributed Teams Are Not Remote Teams appeared first on Upwork Blog.
from Upwork Blog http://ift.tt/2DMqIFU
No comments:
Post a Comment