Get Early Access
Submit the form and we will notify you once the app is launched.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Submit the form and we will notify you once the app is launched.
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:
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.
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.
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.
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.
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:
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.
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 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:
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.
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!”
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.
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.
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:
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.
