Remote Design Team

Getting on the same page in an all-remote design team

Although the variety of tools available to fully distributed teams is staggering — everything from virtual stand-ups, sit-downs, async, sync, todo, not-todo, audio plus screen, all video, post-it shares, partial video, full video, AR, VR, and so forth — it’s not an easy to thing to connect 1-to-many. 

However connecting 1:1 is easy because there’s no ambiguity with respect to who’s communicating. That goes for all-remote or all-premise the same way. Direct, unfiltered communication is super powerful.

But when you’re in a group larger than two, then all-remote degrades much quicker than all-premise. I believe it’s because of the following reasons:

  1. Spatial cues vanish and it gets hard to coordinate a shared view of everyone in the same space. The left, right, back, front of a room aren’t usable as orienting devices. You can’t use your eyes to look to someone and they know you’re looking at them — so gaze doesn’t matter. In theory VR- and AR-based systems will help to solve this.
  2. Everyone isn’t comfortable with their video on and/or their audio on. When working remotely there may be a background noise so you need to turn the mike on mute; you or the room your in may not look great, so you turn the camera off. It’s hard to gauge the attention level of the room so misunderstanding forms more easily.
  3. Async is the norm, so being in sync mode feels extra constraining and slow. Over time when you are working all-remote, you come to get used to communicating async and get the benefits of being able to manage multiple streams of communication. So being in sync mode can feel slow and cumbersome.

These detractions aside, sync space can be useful for getting on the same page because it’s a significant investment by everyone in being co-present. It’s the closest thing to a handshake in an all-distributed environment to just show up in the same sector of spacetime.

When working in sync-time, the importance of timezone inclusivity comes to the foreground. This was an early suggestion made by my Automattic colleague Paolo Belcastro — that I’m forever grateful he gave me. I tried running in three timezones a while for my all-hands as an experiment, but over time I realized that two worked fine. So whenever I run an all-hands in design, I run it twice with identical content: one in US/EMEA and another in APAC/US.

Looking back to my early days (a year ago 😉 ) I realize that I overdid my sync time asks in the beginning, and so I scaled them back because it didn’t fit the overall culture. But I’ve kept some regular sync time, and I keep experimenting with how to make async 1-to-many exchanges as impactful as sync exchanges can be. How? I try to keep listening to my constituents, and I am iterating as I blog! —JM

Remote Design Team

Remote work in the 2018 #DesignInTech Report

42% of designers surveyed work most only on premise. The rest work blended (41%) or all-remote (16%).

2018 Design in Tech Report
Remote Design Team

25+ insights from remote design team members

This is a set of tips we’ve gathered at Automattic Design from less than a year ago. Enjoy! —JM

Getting Started for Remote Designers

Design Processes for Remote Designers

Customer and User Research for Remote Designers

Teamwork and Leadership for Remote Designers

Environment and IRL Hacks for Remote Designers

Addressing Isolation Challenges for Remote Designers

Toolkits and Systems for Remote Designers

Remote Design Team

Thoughts on leading a remote design team

I thought I’d take advantage of Gutenberg‘s imminent release to use it as often as I can for what it was designed for: writing. But I’ve been wondering what to write about …

On a recent visit to Silicon Valley, I noted how there are more than a few major technology companies that are wondering how to make a fully distributed (aka “remote”) design team work well. They were all asking me how it’s done at Automattic. The 💡 went off in my head.

I feel so fortunate to have stepped deep into the territory of all-distributed teams by joining the Automattic universe 22 months ago, and I have enjoyed every minute of it. But I haven’t had time to really write about the experience. So let me start!

First of all I’m using a cool “WP LinkedIn Auto Publish” plugin so I can connect to an audience I have over there automatically. I had wanted to connect in my Medium account but unfortunately they haven’t updated the plugin … but I guess I can just copy and paste stuff directly over there.

Secondly, I should start out by finding what folks would like to know about remote design teams. Let me start with a rough framework like: 1/ How does it work? 2/ How it doesn’t work? 3/ How do you make it work better? If I really get going I’ll open a TypeForm to gather more information.

How does it work?

Automattic is a 700-person all-remote company with one key secret to how we work well in an all-distributed fashion: it’s got to work. In other words, it all works well because it’s the only way that we operate. We have no headquarters to rely upon, so we figure out how to make-do without one.

A few years ago our CEO Matt Mullenweg shared this key thought:

“While it’s possible to work remotely, there’s a bonding and a familiarity that develops when you’re in person together that’s irreplaceable.”


And that’s the second secret to Automattic: we get together IRL (In Real Life) throughout the year. We gather in all kinds of places all around the world in small groups and across teams — and what makes it cost effective is that we don’t have a physical infrastructure to pay for or any other large capital outlay. Cool, huh?

Lastly, the third secret to Automattic is the people. We’ve got great people who are passionate about making the Web a better place. The idea of safeguarding the Internet’s global, distributed nature is sacrosanct for us — so our values overlap perfectly with how we operate.

Thanks for visiting, and I’ll try to keep this up so I can get through all three pieces of my rough framework. So next up: How it doesn’t work? —JM