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 she 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 it doesn’t get 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.

The basics I’ll cover in greater depth below:

1. Designing intentional interactions, including best practices for meetings
2. Building culture & collaboration into a variety of team touch points
3. Experimenting to find what works for your particular team

What do I know?

First, my remote credentials & 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 owner of my own business where 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. My first six months in the org were non-remote where I was onsite at the Toronto headquarters, which I do 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.

Shifting to working remotely as a manager helped put everyone on the team on equal ground.

Shortly after returning to work post-maternity leave I was promoted into management. Being a new manager remotely allowed me to continue with Real Life™, breastfeeding my babe well past the bare minimum recommended time.

I didn’t feel encumbered by a lack of physical proximity to my team whatsoever. In fact it helped; many of my colleagues were already in 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 or a glance over the shoulder or a passing comment, or any interaction equally insignificant in the context of an office, must transform to 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 & 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, 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.

But 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 & 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 allows another regular touch point where you can see 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, adapt design feedback to individual preferences, e.g., 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 at 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 followups where there are more probing questions or issues of work overlap.

Open invitations

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 other 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, it 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 cross-org 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 be:

“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, 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 mediums that require extra work on top of already difficult work in order to share and get feedback remotely, and they are more settled in their individual communication styles and preferences. Adaptation is not always a designer’s strong suit.

Distributed designers have a more difficult time than distributed leadership.

Designers, especially less experienced designers, 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.

The unusual challenges of working remotely often require unusual solutions.

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.

Launches, cakes, holidays & 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 member’s 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 to this day!).

You gotta do what you gotta do to make everyone feel a 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 Five or Six), travel is tolerable, exciting even, 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:

1. Gelling a team that has never met before IRL or who has a bunch of new people.
2. 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.
3. 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 continues to happen 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 that are real humans like me.

I am 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.