Working Remote: How We Successfully Run Clarity as a Completely Remote Team
For the past year or so, we’ve been building a design system within VMware. Two months ago, we open sourced Project Clarity.
Clarity started with a team of a few engineers and designers and has grown to a total of nine. We worked remote since the very first day. Even though we’re 9 members, we live in 6 different cities. This is the story of how we made it work and work well!
Starting Remote
A few years after I joined VMware, I moved to Seattle and I became the only remote employee on my team at the time. That was challenging. Being the only remote employee means you’re the “inconvenience” to the team especially in meetings. Many of the discussions and sometimes decisions happen in hallways and unplanned discussions. Not being there means not having a voice or at least not an effective one.
As I was experimenting with this for the first few months, I decided to switch teams. This time, most of the team was still centered in Palo Alto (where VMware headquarters are), but a few other engineers were remote. We had an engineer in France, another in Scotland, and many around the US. This did not work very well either. We were launching a new product and that meant operating like a startup. Being the first engineer on that team, I took a leadership role for all of UX and UI and what that meant was spending lots of time in Palo Alto where the rest of the leadership for the product was. We also had engineers all over the world, and the time difference just made it tough to have everyone on the same page all the time.
In 2015, I ended up spending over a 100 nights in Palo Alto. The benefits of hotel and airline premium statuses were not really enough to justify staying away from my home for over a third of the year.
As I transitioned to building Clarity (a story I will tell in another post), I decided to provide the same opportunity that I got, working remote, to all the engineers and designers we hire. Since day one, we decided that we value talent, not location. This was one of the core principles of the team. What this meant, is that from day one, my team was remote. We were a remote team. The only restriction that I learned from my previous team was to minimize time difference. We decided to be remote within the US. All members need to be in one of the 50 states. This has made it easier for us from a timezone and legal/HR perspective.
Building a remote team was actually easy. It meant that engineers were able to become part of Clarity without the requirement to move. Even though it was hard at times considering we were still part of a larger organization, it was one of the best decisions the Clarity team has made.
Today, we’re a total of nine core team members but we’re in six locations: Seattle, Palo Alto, Austin, New York, New Jersey, and Los Angeles.
How do we do it?
One of the most important challenges of a remote team is culture. Being remote means extra focus on keeping the team close. Building relationships while remote is hard; acknowledging that and spending time on it becomes a priority.
Being at the center of UX and UI for VMware means we work with dozens of teams across the company both in Palo Alto and around the world. This means we need to work with hundreds of engineers all over the world. Even though they’re mostly centered in Palo Alto, being remote has served us well in making access equal to all engineers and designers everywhere.
There are few things we do regularly to maintain quality and productive work while being a remote team:
We use Slack
We use Slack as our remote office. We allow for Slack to replace our physical proximity which makes all of us approachable at any time. This helps make sure that every member of the team can reach other members of the team (during work hours) to share work, discuss, ask questions, and even share the not-so occasional joke or commentary.
We use video conferencing, a lot!
We meet using hangouts, appear.in, Webex, Skype, and other methods. Sometimes it is scheduled but most of the time is when a discussion is needed. Starting a video conference from Slack is simple and very quick. We have an agreement that starting a video conference to discuss something is always acceptable as long as the other person is available. It is the equivalent of knocking on someone’s office to ask a question or start a conversation.
We meet (virtually) twice a week
We hold regular standups at 9:30 AM PST on Tuesdays and Thursdays. This serves as a chance for everyone to meet everyone (other meetings during the week might not include all team members). This means we get to share what we’ve been working on, any blockers, any issues, etc.
Pairing
We’re not doing this as much as we’d like, but we leverage pairing designers and developers to share responsibility in what they are working on together. We also pair up designers together as well as developers to share knowledge and ideas. This helps to make sure the work we’re putting out there is always being vetted as it is being created. We don’t like throwing things over the wall between design and development or to our users, so we collaborate.
This is also important to creating a team culture where design is at the core of the team’s responsibility and priority. It also helps designers and developers to learn from each other.
We meet physically every few weeks
We meet physically every 8 weeks or so in Palo Alto (we’re trying to go other places as well). This helps us get together, do our retros, and discuss future work. It also helps create a really strong bond among team members. Since most of us fly over to Palo Alto, we all have time during work hours and most importantly, after work hours. This means getting together and spending every day of the week together. It is like an offsite every 8 weeks or so!
We do understand that not everyone can always make it so most of us make it Monday to Friday of that week. However, many of us choose to come over for a few days only.
One of the most important aspects of the team is having the ability to function well remotely. It has brought us closer and made us a much more productive and connected team.
Challenges
Even though this has been working for us brilliantly and many on the team (including myself) argue that this makes us more productive on daily basis, there are definitely challenges.
Managing time while remote is harder. Because you have to make yourself available more often, it is harder to figure out when to “turn off Slack” and focus for a few hours. Not to say that this does not happen and isn’t encouraged. We call it “going dark” where someone announces they’re “going dark” for a few hours to focus on a task or to finalize something. However, making that call at the right time is harder while remote because it is harder to make an assessment of what everyone is doing at that time without asking.
It is also harder for me personally. Considering the fact I work with many teams within VMware on Clarity, I end up flying over to Palo Alto more often (sometimes, more than once a month). This does not extend to the rest of the team most of the time but it is a difficulty.
One more challenge that remains unsolved is video conferencing. Even though we use many different ways to do this and even though it is really easy to get started, we still haven’t found the best video conferencing solution. They all have pretty big shortcomings (maybe that needs to be another blog post). This continues to be an unresolved problem for us.
What’s next?
We’re happy as a remote team. We’re able to hire the best in the industry, keep them longer, keep them happier, and make sure that we’re being productive. Moving forward, we will continue to try and expand Clarity this way!
If your team works remote and you’d like to share some thoughts please reach out. We’re happy to share more thoughts with you and happy to learn from you if you have experience here!
One final note: it goes without saying but your mileage might vary. This has worked very well for us in our circumstances but it will probably work differently for different teams at different companies in different locations. We’d love to share more of our experience and learn more of yours if you’re thinking about starting a remote team or you’re already working remote.
Make sure to check Project Clarity, follow us on Twitter, and keep your feedback coming on GitHub!
