Distributed UX Teams: Early Lessons Learned
I’m currently managing a small team of just under ten people. However, that team is distributed among three sites spanning Seattle, San Francisco, and Warsaw. Our greater UX team is even more fragmented, with additional folks in Munich, Cambridge, New York, Irvine, and Ann Arbor.
It’s reasonable to ask why this is so. A stock answer might be, “We work at a big global company and that’s just how it is at big global companies.” Though I don’t really think this is a sufficient answer. I think it comes down to a few things that are more specific to Google:
First, we sometimes meet talent where they are, rather than relocating them to the mothership. As a result, we have engineering offices that have coalesced like crystals wherever talent seems to concentrate. Teams will often take a talented designer, engineer, etc. in a faraway location because she has a proven track record and requires little ramp-up on working within the company.
Second, we have a high degree of internal mobility, meaning that a person’s average tenure on a particular team can be considerably shorter than that experienced at other companies. You are generally considered free to explore other teams after as little as 18–24 months on your current team. Throw in the fact that not all projects last forever, and you have a recipe for fragmentation not just for project teams, but for individual roles within those teams.
For me, this is neither a good nor bad thing, but it is frequently the way of things, and we do the best we can for our situation. For the rest of the article, I want to sum up some of the lessons and processes our team has developed for working more effectively across time and space. I also want to mention some of the tools that the company has built up over time to accommodate the aforementioned tendencies for teams to fragment.
First, the tools.
Solid VC infrastructure. Interviewees frequently present before panels that include several remote members, and depending on their prior experience, frequently marvel at how quickly a presentation can be started using our tools. Similarly great tools exist in the marketplace (yes, including ours). If you can’t have a globally distributed meeting up and running within a minute or two, you should consider another platform. The moment the setup process becomes reliably onerous, the more quickly distributed teams will avoid it and meet less frequently than they need to. Informal design critiques, user study debriefs, and ad hoc brainstorming sessions across distance are dependent on this kind of push-button ease.
Robust project-tracking and bug-tracking. Particularly for distributed teams spanning many time zones, the number of potential hours available for realtime meetings can be limited or nil. Unless you and your family enjoy it when you frequently skip dinner to meet with Shanghai, you may have to plan on conducting a fair amount of work asynchronously.
Enter bug-tracking. Typically used for tracking software issues, we’ve found the process to be quite useful for tracking UX deliverables as they dovetail into implementation. We have our own internal system at Google that works well, but external tools (Asana, Trello, JIRA, etc.) will also do the job. The key is to have total agreement to work through these tools, as well as agreement on how quickly items will be prioritized, triaged and addressed.
Solid tools for sharing and commenting on designs. While bug- and issue-tracking tools are useful for keeping on top of commitments and supporting the teams building your designs, tools for disseminating design artifacts in the earlier stages of the process are equally critical. At a basic level, Google Drive, Dropbox, and shared folders help, but far better is the ability to comment in the artifacts themselves, bringing other teammates into the discussion as needed.
We have some great internal tools for doing this sort of thing, and when used properly, they can facilitate rapid iteration—even if they still sometimes fall short of in-person sessions. Designers can control the extent to which artifacts are shared, writers can suggest appropriate labels and help text, and stakeholders can always find the latest (or implementation-ready) versions. As large organizations continue building up their in-house design organizations, this area seems ripe for further innovation.
Now, some additional things I’m learning along the way.
Have multi-lateral commitment to specific meeting times. For degrees of distribution that result in little to no overlap in working hours, teams in each time zone should commit to certain days where they can get up early or stay late to accommodate people in other locations. This prevents scattershot scheduling that prohibits people from being able to coordinate with their families and partners, or fatigues them from having too many meetings outside of normal working hours.
Singletons might not stay long if there are local opportunities.
Sometimes it’s necessary to build up a new team where the stakeholders are. Other times, there’s someone so talented, you can’t pass her up, even if she is nowhere near you. It’s my feeling that without some additional support in the form of another UX role, it will only be a matter of time before that person finds a local team where design feedback, mentorship, camaraderie, and advocacy can more readily be found.
The exception to this would be cases where there really aren’t other local options available. This is a somewhat different situation that requires close attention to that person’s visibility, project choices, and travel requirements to ensure that he or she can achieve career goals without being hamstrung by distance.
Build on good relationships. I’ve seen cases where all of the critical roles on a team (Eng, PM, UX) have been in different places. Obviously collocating them is ideal, but if you were to pair UX with only one other team member, who would it be? Whether right or wrong, I’ve started to choose or select by the best relationships. Seating my teammates with stakeholders who either don’t understand our process or want to circumvent it has been a disaster for me, particularly if you combine it with the singleton issue mentioned earlier.
All things being equal, my ideal setup is to have the team collocated with our engineers. In the best cases, the engineering team participates in our sprints, observes our studies, and assesses the feasibility of our designs early and often. Moreover, they can be our strongest advocates for UX-driven efforts that will not be seen to completion without agreement from every function (product management, engineering, UX, etc.).
Over-communicate. Particularly when time zones are an issue, it’s very easy for a teammate to start feeling out of the loop. Nothing wakes you up to how much work happens informally and synchronously like having distributed teammates. Group chat, and Slack are great solutions for having conversations across locations, but if some of your teammates are asleep for the majority of your working day, it’s worth considering other measures to make sure everyone is in sync.
At Google, we have an internal “snippets” tool for posting regular updates on our work, typically at a weekly cadence. Snippets serve to share the latest mock versions, research reports, study plans, hiring updates, and anything else that feels noteworthy.
To be fair, snippets are a diligence task; I’ve been on teams where these updates were neglected for months at a time. However, my far-flung teammates have been instrumental in encouraging the rest of us to share updates, as they benefit greatly from seeing them. We’ve come up with several ways of reminding ourselves to do them, through calendar appointments, shared compilations, and as a last resort, the tried-and-true email nag.
Distributed team members shouldn’t feel left out of fun. On occasion, our local team in Seattle will do something fun, whether it’s a dinner, a holiday gift exchange, or sharing treats brought back from a recent vacation. Distributed teammates not there to enjoy these things might tend to laugh them off individually, but over time this can foster a sense of remoteness that only adds to the difficulty of working with your team from afar.
I try to do whatever I can to make these fun events feel inclusive. Our holiday gift exchanges happen across sites, even if it means the gifts get shipped or delivered upon the next office visit. Some treats brought back from vacation are set aside to be mailed to distributed team members. If our local team gets together, non-Seattle teammates get funds to do their own outing as well. Obviously, distance will always exist, but the team appreciates the effort, and I believe in some small way it keeps our other sites from feeling less desirable, connected, or vital.
Be up-front about travel requirements, and stick to them. Distributed teams will require more travel. Even the best-functioning distributed teams I’ve worked on cited how invaluable it was to hop on a plane and work for a week in the same building. It’s important, however, to make sure anyone joining your team knows this up front. If you’ve agreed in advance to fly your teammates to Asia twice a year to work with a distributed design team, new hires need to know that.
Moreover, changing the requirements afterward will feel like a bait-and-switch to your teammates, so any efforts to increase the travel burden should be handled very carefully. Stay respectful of your teammates’ work-life balance, and make every effort to give people choices about what projects they take and the amount of travel they require.
It can be tough to strike a balance between trying to keep everyone under one roof and acknowledging that a company with a global footprint needs to accommodate talent where it lives. I hope some of the points in this article are helpful, and I’d also love to hear your thoughts about supporting your own distributed teams.
The opinions expressed here are my own and do not express those of Google.
