The Ultimate Guide to Leading a Remote Design Team
Best practices for keeping your remote team happy and productive
Earlier this week Alexis Lloyd, Head of Design Innovation at Automattic (she’s moving on to Medium, congrats!), shared on Twitter some insightful best practices for leading design teams remotely and asked others to chime in. As in, a community sharing ideas—not just complaining! Be still, my heart. I don’t know Alexis personally but her receptiveness inspires me.
I started to reply in unrolled, unthreaded, Twitter-novel form, but I realized I have had this topic in my brain for years now, and if I don’t get it out today it will be trapped inside forever with only cobwebs and dusty memories for company, and no one will know the wonderful things I learned (mostly) while working at Mozilla.
Here are the basics I’ll cover in greater depth below:
- Designing intentional interactions, including best practices for meetings
- Building culture and collaboration into a variety of team touch points
- Experimenting to find what works for your particular team
What do I know?
First, my remote credentials and why I’m passionate about remote work culture.
I have spent about six years working remotely as a team lead, an embedded designer, a design contractor, and the owner of my own business in which clients and team members were not local. Remote is the best thing that ever happened to my work life; as a self-driven extroverted introvert, it suits me so completely. I also have a busy life with two young kids and a mother with some chronic health issues, so working remotely helps me balance it all.
I started at the Mozilla Foundation as a UX/UI designer in 2013 and became Design Director a couple years later leading a team of designers. During my first six months in the organization I was on-site at the Toronto headquarters, which I recognize was crucial to figuring out the cultural and logistical landscape of the organization. It was only after having my first baby that I fully embraced the org’s remote-first policies.
Working remotely as a manager put everyone on the team on equal ground
Shortly after returning to work post-maternity leave, I was promoted into management. Working remotely as a new manager allowed me to continue with Real Life™, breastfeeding my babe well past the bare minimum recommended time.
I didn’t feel at all encumbered by a lack of physical proximity to my team. In fact, it helped: Many of my colleagues were already distributed — working from Vancouver, San Francisco, Germany, and London — and I finally had firsthand experience of what it felt like to be “remotey.” It put us all on equal ground.
I have loved the flexibility and balance of family, work, and side projects ever since. I currently work remotely with a team at Adobe who are in Vancouver, San Francisco, San Jose, India, and elsewhere.
Across the years in different contexts, my remote working strategies have shifted depending on the project and team, but here are the tips I’ve picked up that have worked across the board—in addition to the great points in Alexis’ original thread and replies since.
1. Design intentional interactions
Working remotely, one spends a lot of time in “meetings.” I use the word loosely because what might’ve been a walk-by, a glance over the shoulder, a passing comment, or any equally insignificant interaction in the context of an office, must become a more intentional interaction online. An intentional interaction that is, to everyone’s chagrin, usually scheduled.
But scheduled doesn’t have to mean bad. It’s like blocking off a day in your calendar so you can write and think or take vacation. It’s a way of ensuring there is still space for magic to happen in your work.
That said, it’s best to keep the annoying minutia of meetings to a minimum as much as possible. Here are ways I try to do that.
Standing meeting best practices
Weekly or bi-weekly 1:1s with reports or managers are key. These spots are sacred in my calendar. I don’t reschedule them unless I absolutely have to because I want my team members to know that these check-ins are a priority for me.
1:1s are sacred. Team members need to know their needs are a priority.
For each 1:1 we usually have a running document where we both note questions or concerns, take notes on our discussion, and regularly revisit commitments from our last meeting. At Mozilla these notes were also useful as summary docs during review periods.
Encourage 1:1s across verticals to develop trust and empower a connected team.
But as a manager I also encouraged team members to find allies across teams and form regular 1:1s with them too. This helped with culture, connection, and trust, stabilizing the team and helping everyone feel empowered.
Furthermore it helps prevent a design silo, exposing design thinking and practice to many corners of the organization.
Better meeting efficiency
There was (is?) nothing more annoying to me than a meeting that has been scheduled for weeks but when the time actually comes, it drags on, is disorganized, or doesn’t accomplish its goal.
Here’s my wish list for a good meeting:
- Relevant links are included in the meeting invitation. These include links to background documentation, meeting rooms and call-in info, and a solid agenda. It’s terribly annoying having to search or ask for links at the beginning of a meeting. It’s disorienting and interrupts the positive start energy.
- Have an agenda! Worth repeating. Even if the only thing on the agenda is to find out what people are doing that weekend. It establishes expectations and accountability and also probably dictates the person who will keep the meeting on track.
- Every shared note document should be topped by a list of to-dos and commitments that come up in a meeting. By keeping the same running doc, everyone is forced to reckon with past commitments. See the pattern?
- Encourage punctuality. If someone is late, start without them. It’s not a big deal. People always catch up.
- Be okay with technical difficulties. If someone’s internet is hiccuping, a little pause is okay but don’t wait eons for it to resolve itself. Move on. Again, not a big deal, people will catch up. I often switch to voice only or call in by voice so if the video fails the audio doesn’t.
Bigger than the technical solutions is how we treat a lagging, robotic video or faulty audio as humans and as managers.
I had a manager who lived in Victoria and sometimes, for whatever reason, his Internet was crappy. When he laughed it off or took a little while to get things up and running again, I didn’t feel so bad about it happening to me during a rain storm or while I was traveling. It became part and parcel of the remote working life.
My manager’s easygoing reaction helped build trust amongst the team and gave me confidence to not freak out when I was having issues myself. It happens to everyone.
2. Building culture and collaboration
Culture and trust are the trickiest things to build in a remote team. I believe it is done through collaboration, period. Opening the door to collaboration is often, surprisingly, the trickiest part of the trickiest part. Luckily a few standard industry practices make it possible with some very small tweaks.
Design review best practices
Design reviews (or critiques) are a thing in design teams. There is often a review cadence established by individual projects, but reviews can also be hosted by design teams as a whole, helping to build trust and communication channels. We did it weekly. This allows for sharing of best practices, learning, and recognizing overlaps in work. It provides another regular touch point where you can assess people’s moods and generally whether or not they’re having a good week.
Who in this video call is likely not having a good week? Who would you follow up with?
It’s not a science, of course, but seeing faces and body language certainly helps.
At the same time, you should adapt design feedback to individual preferences. For example, some people like to talk through feedback by voice, others like it written in a bulleted list, yet others prefer high-level feedback so they can tinker with the pixels themselves. All these are valid.
A good design review:
- Very briefly allows the designer to introduce their work. One or two minutes tops, honestly.
- Establishes boundaries for the desired type of feedback. Where are they in the process? What kind of feedback is most helpful — high-level or more granular? Is this production-ready, or early conceptual thinking?
- Lets the reviewers do most of the talking. The presenter does not get a rebuttal unless it’s in the form of a question.
- Allows for more in-depth follow ups where there are more probing questions or issues of work overlap.
It also helps to let team members take turns running your regular meetings, like design reviews. This is a chance for managers to listen. Have others help set the agenda too, but do all this before the meeting starts — don’t screw up meetings by doing the logistics work inside the meeting.
It is particularly awesome to invite non-design team members to experience a design review—research, engineering, community leads, customers. Not only does it give other teams access to the projects you’re working on, but it also develops empathy for the difficulty of expressing and receiving actionable, constructive feedback. It levels everyone up.
Communicate out; listen in
It’s important that people across the organization understand design efforts and have access to the design process. This can and probably should happen asynchronously, though. Short, regular, frequent updates work best — a one-paragraph weekly update by email or Slack with images, for example. This should be done with some regularity and a tone of openness and collaboration.
This is not to say that sharing out is always an invitation for feedback. Feedback has its own time and place.
A sample email might look like this:
“Here’s what we’re working on, we’re about halfway complete, and we’ll be collecting feedback in a week or two. I’ll schedule meetings with folks who are interested in talking it through, let me know!”
Or more simply: Introduction + Current status + Next steps.
One trick up my sleeve: When I was working in Open Source, because we were free and encouraged to share our works-in-progress regularly, I found it particularly effective to publish public blog posts. The mere idea of the outside world reading what we were up to internally put a bit of pressure on the team to actually read my posts. As my 5- and 3-year-olds would say, “Tricked ya!”
3. Experiment to find what works
A distributed design team is more difficult to manage than a distributed leadership team.
Managers talk and make decisions, and are usually adept at changing their communication style depending on the situation; that is to say, they work well in many different contexts, including remotely.
Designers, on the other hand, make stuff in a variety of media, and it requires extra work on top of that already difficult work to share and get feedback remotely. Plus, they tend to be more settled in their individual communication styles and preferences. Adaptation is not always a designer’s strong suit. Thus, distributed designers have a more difficult time than distributed leadership
Designers, especially those who are less experienced, also have that additional burden of having their identity tied up in their work. Intentionally publishing something for review not knowing when they will get a response, not being able to read between the lines of a Slack chat, potentially facing criticism in front of their peers, or not being able to look into someone’s eyes when they’re providing feedback on their work — the struggle is real. I understand it and remember the feeling well.
To combat this difficulty, at Mozilla we tried to find ways to build trust and excitement, to experiment creatively and collaboratively. One example was when we launched our new team Dribbble page. We each took a segment of the vintage Mozilla dino logo and sliced it into individual sections we could then “quilt” together.
Here’s what the plan looked like:
Here’s us at go-time:
And here’s the result:
This exercise took far longer than it should have. There was a lot of work on my part to ensure it turned out to be the culture-building exercise we’d intended. It also probably wasn’t terribly fair, because some people had to create their piece outside of work hours.
But in the end it stands out as a fun and memorable artifact of our silly design team. The point was that we were willing to throw spaghetti at the wall to see what stuck. The unusual challenges of working remotely often require unusual solutions.
Launches, cakes, holidays, and swag
As with any work culture it’s important to pause and appreciate special occasions, but with remote culture it takes that much more effort. It might mean organizing Ugly Sweater Holiday demos. It might mean sending ten different swag orders with custom sizing to remote corners of the world. It might mean thinking a little harder about what might be helpful to your colleague out on sick leave.
I remember when Webmaker launched there were cakes in every office to celebrate. I made a special effort to deliver cupcakes to remote team members’ homes as well. Our engineering lead, Simon, lives in Revelstoke, Nowhere, and I had to enlist the help of a colleague to contact Simon’s spouse to pick up a cupcake for him, as their local bakery didn’t deliver (thank you, Karilyn!).
You gotta do what you gotta do to make everyone feel like they’re part of the team. No teammate left behind. No teammate without cake.
On work-related travel
Here’s a personal pet peeve: Don’t force travel for the sake of travel or because you think I’ll find it fun.
The first couple of years as a member of a remote-first team (I would say trips One through trips Five or Six), travel is tolerable, even exciting, but by the time you’re old and haggard like me, folks have kids or parents or houses or health issues or other responsibilities that need their time too. If arranging travel, I consider it a matter of respect for teammates to have a crystal clear reason for bringing people together in the flesh. Work travel is exhausting, and its impact on the human psyche shouldn’t be taken for granted.
Good reasons to travel in my book are:
- Gelling a team that has never met before IRL or who has a bunch of new people.
- Aiming to complete a huge amount of work in a short period of time, particularly across teams who are all able to coalesce in one place at one time to make quick decisions.
- Sharing a new strategy or direction that requires significant buy-in and input from the team.
Interviews and hiring can happen asynchronously. Good onboarding can happen asynchronously. Launches can be celebrated asynchronously. Cadence can be established asynchronously.
Feel free to fight me on this, but the number of colleagues who’ve come to the same conclusion give me confidence that I’m hitting a nerve. After a couple years of it, we ask ourselves, “Is the travel worth it?” and frankly, the answer is usually “No.” We can do what we need to do without it.
Sometimes I wonder if managers organize travel because they themselves are feeling paranoid, vulnerable, or out of control. In that case, you fly to your team. Don’t make them come to you.
Be the human we know you are
Lastly, a celebration. My absolute favorite remote moments are when my kids or other people’s kids “interrupt” a meeting, and the person on the other end of the line just rolls with it. This happens nearly weekly, and I am always grateful to have other people’s kids at demos, not just my own. I am grateful to have colleagues who are real humans like me. I am also grateful to have a flexible working life that doesn’t ignore the rest of my life.
I always think of this when someone’s roof leaks, the doorbell rings, a pet steps on the keyboard, the audio fails. In light of what we are able to accomplish as a distributed team around the world, these things are trivial. But they are also the moments we get to practice being generous, and I will be forever grateful for that. ❤
Do you have more remote collaboration advice you’d like to share? I’d love to hear it! Leave a comment or find me on twitter. We’re in this together.