Context is Key for Your Distributed Team’s Success
I’ll start by sharing a very public secret. Highly successful distributed teams and co-located teams are successful for the exact same reasons. They have great leadership, solid communication, and work effectively as a team. When corners get cut, the team begins to lose its edge.
Does this type of project kickoff with engineering sound familiar to any of you?
“We’re going to restructure our registration flow. These changes are expected to improve conversion by 5%. We’ve completed the design and already created all the stories. Now let’s start planning who will do what tasks to finish this on-time.”
I’d venture that those of you working in waterfall environments (especially downstream) would agree that it is a plausible story. However, those who work as a highly collaborative and cohesive team with close involvement from the beginning would find fault in it, as the many of the most important parts of the kickoff were omitted.
In this example, the resulting task list would likely be very clear because the stories were already created. Even the deliverables would be clearly defined. However, the kickoff has failed to communicate a key element which could prevent the team from delivering the best possible outcome: the context of the project.
When we don’t include the context, we create more questions than answers. What problem are we solving? Where are the customers struggling? How did we learn about these problems? How did we validate the solution so far? Why will this result in a 5% increase? Could this be a systems design problem and not a visual design problem? The questions can go on-and-on.
To exacerbate the issue, there is often a delivery timeline and deadline for the team. This can immediately shift the team into a delivery mindset, instead of a design mindset, reducing the likelihood that these questions would even ever be asked. It is important for the entire team to know the answers to these and similar questions throughout the life of the project.
Effective leaders know that properly communicating context with their team early is more likely to result in successful outcomes. A team that’s been given a high degree of context can thoroughly empathize with the customer, understanding why the proposed changes are likely to be successful. With this context, they not only share the vision but can help to shape it further. This helps improve the final product beyond what would be possible if the context is never shared. Because the team is more deeply involved from the start, they may also bring increased levels of passion to their work.
Ineffective context communication will cripple a distributed team. Unfortunately, it’s also a very easy corner to cut. When some team members are co-located and the remainder of the team is distributed, the old proverb, “out of sight, out of mind,” succinctly captures a majority of what tends to happen. People forget to communicate and bad habits begin to form. Consider a few other variables that add to the challenge:
- Multiple time zones can complicate the ability for a team to work together in real-time.
- National culture differences can create confusion. When expectations are implied, this can often result in misinterpretation.
- Hybrid meetings, with some members in one room and everyone else in a video call, can create mixed levels of engagement and unequal opportunities to interject into a conversation.
Having disciplined communication habits is key for a team to operate inclusively while also minimizing the negative impacts of things like time zones, cultural differences, and mixed-location teams. Let’s look at how techniques to strengthen context communication on your team.
Setting rich context to create a virtuous cycle
At the beginning of initiatives and projects, you’re seeking to motivate and excite the team to move mountains. In order for this to happen, the entire team needs to go on the same journey. When done correctly, the team will be highly engaged and aligned throughout the project. They’ll ask questions, take ownership, and push through tough times to bring the team’s vision to life.
Where does this journey begin? For Upwork, this starts by empathizing with the needs and motivations of our members (i.e., freelancers, agencies, and clients). We do this by hosting focus groups, collecting feedback, a/b testing, and directly observing how our community uses Upwork. This process creates a wealth of knowledge about how to best serve our members, identifying key problems to prioritize and solve. Additionally, it helps reveal strategic opportunities to improve our service offering.
High context communication
A high-context environment from end-to-end better enables a team to make highly effective decisions at every step. Information from multiple sources that’s continuously fed into the team can help adjust the outcome; often the final design is different than what was envisioned at the start. Here’s a look at how this can work effectively and some of the poor behaviors that can break it.
During my time at Netflix, we did extensive research with our members. We would invite them to our offices to learn about how they used the service. We had a traditional usability lab with one-way glass that gave our product, development, and design teams an opportunity to watch how our members interacted with the Netflix website. They often missed subtle moments in the interface that frustrated them. We were there to learn from their experiences. My colleague, Dr. Joel Mier, recently reminded me of a quote taped inside the viewing room: “Seek to be informed, not validated.” I didn’t care how good the design was, or how confident we were that a particular design was “getting it right.” We always made mistakes.
These sessions became so popular that the observation room needed to be doubled in size. More folks came, we learned more. You could argue that this was beyond high-context and approaching full-context in that the team saw, in real-time, the successes and frustrations of our members. Ultimately, this experience was a key contributor to the success of our team. It helped create a virtuous cycle that further informed and further engaged our team. When combined with other inputs, any individual on our team was capable of making solid decisions.
Upwork has different challenges and a different organizational structure than Netflix. For example, it isn’t easy to invite clients or freelancers who use our marketplace to a lab to watch them work as they would in their own home or office. Even if we could, it wouldn’t be straightforward to have our distributed team members observe these types of events. We can’t easily replicate the full-context viewing environment that I experienced at Netflix.
What can be done, however, is that we can communicate within the team in a high-context manner. This helps ensure that everyone has the same information.
When our research teams spend time with our customers to learn about their motivations and struggles, they gain an extremely strong insight into how we are succeeding and failing in the eyes of our customers. Since it isn’t practical for participation outside the research team, they need to prepare and communicate their findings. That means being mindful of how they operate and how their work informs our distributed teams.
Establishing context with a distributed team
Sharing context with a distributed team takes planning and discipline. It is not practical to have every person attend every session where the results of research and design are taking place. This could keep people awake for hours at potentially very inconvenient times of day. Instead, here are three tips to consider.
- Kickoff meetings should include the entire team, including researchers, product managers, engineers, designers, and QA members. The goal should be to align the team by clearly communicating the problem and why it needs to be solved.
- Supporting evidence as to why each problem is worth solving should also be shared. In the design-thinking world, this is where the customer’s empathy is established with the team.
- For meetings following the kickoff, the team leadership should capture important insights that are considered wins and failures and tie them back to the initial assumptions. Access to the raw information should also be made available when possible.
Armed with this information, the entire team may be better able to align their actions, questions, and designs to solve the problem. During working hours where communication is hampered, such as those times of day when time zones are incompatible, the team has an improved ability to make strong decisions without consultation.
It is not feasible to have everyone on the team work through every problem. Individuals, and even small groups, often need time to think through tough problems separately. As new solutions are designed, it is important for the details to be shared with the team in-depth to keep everyone aligned.
And there may be key points during the design and development process when bringing the team together at once does make sense. For example, different perspectives during the ideation phase of a project often bring about successful, non-obvious solutions.
Throughout the design and development process, prototypes will get created—some will succeed and some will fail. a/b tests will be conducted to show how customers interact in a production environment. Further data will come from customer feedback, key metrics, NPS scores, site performance reports, etc. Each of these data points creates a shared set of insights.
Sharing the insights gained during a project with the distributed team is vital to its long-term success. Repeated sharing builds deeper context, creating a virtuous cycle that empowers the team to better debate, design, build, and refine future projects.
An expert at leading globally distributed teams, Sean Kane is the VP of engineering at Upwork, where he previously led the marketplace product and design teams. Before joining Upwork, Sean was director of UI engineering at Netflix and held leadership roles at AltaVista and Bigvine. He co-founded the startup GetListed. Sean holds a BS in computer information systems from California State University, Chico.View Sean Kane’s other articles