Remote Design at Trello

Justin Gallagher is VP of Product at Trello, now part of Atlassian. Justin joined Design Driven NYC in June of 2017 to share the tools, process, and workflow they use to effectively manage a remote design and product team. To become a part of Design Driven NYC, visit http://designdrivennyc.com.

Below is an unofficial transcript of Justin’s full talk:

I’m Justin I oversee Product and Design at Trello. Today I’m gonna talk a little bit about our hybrid remote and co-located culture that we have, and specifically how that impacts our design team. This talk is based on a longer talk that I gave recently at Design Week, which is an Atlassian Internal conference in Sydney a couple months back. I co- presented there with some of my colleagues Chris Kimball, who’s our Design Team lead, and Courtney Drake, a Product Designer on our Core and User Experience Team. They did a ton of the work on this so if there’s anything interesting or smart that I say they probably deserve the credit.

Before I get started, anybody work on a remote team or do you work on a partially remote team? About half the people, so let’s go so hopefully some of this is relevant. I think — spoiler alert! — I think some of the takeaways from how a remote design team works applies to co-located teams too.

Quick history at Trello. I started working at Fog Creek Software about seven years ago, and six months later I was lucky enough to be one of the first couple of people that started on the project that eventually turned into Trello. After a couple of weeks there was four of us. There were two designers and two developers all located in New York. As we sort of picked up speed, and got some traction we grew the team, we got up about 20 people, and still we were all located in New York. About that time, we decided to spin Trello out to Fog Creek, make it its own company, we raised some money, and decided to grow the team even faster, and about that time we made the conscious decision that we were going to hire the best people we could find no matter where they were. Even if they weren’t in New York.

This is what the Trello team looked like earlier in January-ish when at the time we joined Atlassian. Everybody here who is represented is represented as a Trello card. Today, our team is a bit over 100 people. The whole Trello team is a bit over 100 people, about 110. Close to two thirds are remote, and the other one third-ish are in New York. Other than me, none of our designers are in New York, and only two of our designers are in the same location as each other, so the team is totally remote.

Overall, we found remote work to be really great. There’s been two main benefits for us. The first has been that we were able to just hire really great, amazing, talented, smart, creative people who we wouldn’t have otherwise been able to hire because they either aren’t willing to, or aren’t able to move to New York for some reason. And second, having a remote team has helped us on this question that we set out for ourselves to build a product that’s used by 100 million people.

That was our internal goal way back in the beginning. We’re not quite there yet, but we’re at 22 million or so. But when you’re building a product for an audience that abroad, necessarily that’s going to be a massively diverse group of people that speak different language, and have different use cases, and all that kind of stuff. Having people on our team from different countries, who speak different languages, different backgrounds, different experiences, all of that has been really great, and has helped us a lot, and I think that’s easier to achieve when you support remote type working. That’s where we started and where we are today, but along the way the question because for us “Can you really do great design and get great design outcomes with a remote team?” That’s what I’m going to focus on tonight.

Unlike a factory worker, or a chef, or anybody who’s making something physical, if you make software experiences for a living, you really don’t have to be anywhere particular. Probably all you need is an internet connection, a computer, some electricity, maybe food, and you can make it work. I kind of posit that actually the more of your work that’s happening through screens, the less your location matters. Whether you’re a co-located worker, or you’re a distributed worker, when you start to think about how much of your work happens through screens it tends to be a large percentage, and that might happen via chat tools like Slack or HipChat, it might happen through collaboration tools like hopefully Trello, or Google Docs, or InVision, or Figma, or those kind of things. At various times you might be on a laptop, or a phone, or a tablet, but all these are screens, and you’re collaborating through screens.

Anytime you’re collaborating through a screen, you can probably be just about anywhere to do that. It’s kind of funny because when I talk to people about that kind of thing they usually say something like this. The non-screen part is really essential, that face to face time, that meeting time is actually the only time I’ve ever had people advocate for meetings when I talk to them. But that is really important, and I do agree with that. That communication aspect, and that face to face time is super important. What I tend to believe now is that it doesn’t actually have to be physically in the same space to be really high quality, and to work really well. It’s more about the quality of the communication than it is the proximity to each other.

For modern day software makers it’s still kind of interesting because it’s about this relatively dated convention of going to work in a physical office, and that time is mostly centered around this face to face time, which hopefully is a limited proportion of your day. Because of our structure, our hybrid, remote, in office culture, this is something that we’ve been experimenting a lot. For us, it’s really critical that we figure out how to do this as well so that we can produce great outcomes, and we’ve been learning a lot along the way. We tried a bunch of things that didn’t work, we’ve tried some things that did work, and I’ll try to share some of those with you today.

Our first really big insight has been around empathy. If you were to imagine two teams, a co-located team, and a distributed team, which one of those teams do you think would be more effective? The product manager side of me tells me we should probably agree on what it is that makes a team successful in the first place. Before we answer that question ourselves… lucky for us that Google asked that same question. They did a study called Project Aristotle where the investigated that, and they determined the number one predictor of team success, and it was actually a surprise to me.

First, a bunch of things that is not … It’s not about an individual like you. It’s not about having a genius, or rock star, or ninja, whatever on your team. It’s not about aggregate IQ either, and this actually surprised me a little bit, but it’s not about the average level of intelligence across the team. It’s not about proximity, so it’s not how close you are if you’re sitting in the same room or whatever. It’s not about experience either, and this one to me was a little more obvious because if you think about some startup, somebody drops out of school, and creates a startup that unseats this income, and obviously it’s not a bad experience. It’s also not about leadership. What they figured out was that the empathy score the team members was the single thing that mattered most.

When Google shared the results, courts wrote an article and summed it up with this headline “After years of intensive analysis, Google discovers the key to good team work is being nice,” which I like. That was a really big insight for us. The empathy amongst team members is key. This is something that when you have a co-located team you kind of get it for free. It’s not a guarantee, but you do kind of get it for free. When you’re sitting next to people, you’re chatting about whatever. Maybe you get coffee, you go get lunch, you see what they’re doing on the white board, you overhear conversations, you’re learning about their day, you’re learning about them, you’re hopefully becoming interested in them, and you’re building a certain amount of empathy for those people.

It’s not a guarantee though. It doesn’t necessarily become true, and if you don’t connect with, or care with your team members, I would said that whether you’re three feet apart, or 3000 miles apart you’re probably not going to be a successful team. Knowing this, and thinking about this the question became for us on a remote design team, how do we build empathy? Like I just talked about with the co-located team we don’t get all that stuff for free. The answer is that what we found is we need to just be really intentional about it, and you need to purposefully and proactively put things into your products as that will help you develop empathy with people because the default on a remote team is often to talk to people only when there’s a thing to talk about, and I find myself falling for this trap too. It’s like, “Hey, I have a question, I’m going to get that person I slack, or I’m going to get in a video chat, and I’ll ask them that question, and I’ll be out of there.

That’s like a very transactional relationship, and that doesn’t lead to building that empathy among the teams. We’ve come up with a couple of things that have helped us that I’ll show you with. We have this concept called Mr. Rogers, and this is a Trello board that we use to manage Mr. Rogers. What it is it started out as just a one on one thing where two people who would across the company would just get paired up to hang out for 15 minutes, and do whatever… just talk about something. It sounded kind of cheesy, but it ended up being pretty fun, and people learned a lot about each other. People got really into it. Sometimes if both people are in New York they go out and do something cool, and take a picture, and bring it back, or people would make up little games to do in a video chat. We ultimately decided that one on one wasn’t the ideal format because if one of those people was on vacation, or sick, or busy, then the whole meeting falls apart.

Also, one on one is a little tricky. Some people aren’t super comfortable with that meeting a new person, or someone they don’t know that well, and it can be a little awkward. We have now, especially as we’ve grown settled into a place where we do about four to six people, and that’s nice because if one person can’t make it you can still have the meeting. They’re sort of like just the more lively conversation that happens, and people really get into it still. You can see some of the pictures of video chats that people put up, and they do little things, they learn about each other, they post little write ups of the cool, funny things that they learned, and that has worked really well to help us build empathy across all of our people, all of our teams, and that comes in super handy when you work with one of those people later. It’s so much easier to work with somebody on a project when you know a little bit about them.

The other thing that we do that’s specific to our design team is that we’ve started running remote design sprints. We used to do in person design sprints, which I’m sure many of you all do, and we would fly people to New York, or sometimes we would fly everybody somewhere else, and we do the typical design sprint, and that was great. That worked really well, but it was a lot of logistics, a lot of travel and planning, it got pretty expensive, so we started saying, “Maybe we can do this remotely too.” I can do a whole talk about this. There was a lot of interesting things that we learned, the things that we tried that worked and didn’t work, but I wanted to focus on one thing … One takeaway that we had after we ran a few of these is that we need to do those same empathy building activities in the design sprint, and the actual sprint activities go a lot better.

We’ve done some of those things. We eat lunch together, which we thought was going to be awful, and was going to be weird to be in a video chat, and hear everybody chewing. But it turns out to be pretty good actually. It’s pretty easy to mute, and unmute yourself, and it’s a nice time to just hang out, and eating a meal with somebody is a lot nicer than eating a meal along at your house, so that really helped on the team. Somebody in our team also came up with this exercise called “Take a walk, take a photo”, where people take a break, they go out, walk around their neighborhood or whatever, take a photo, and bring it back, and just share it with the team, and tell a little story about it.

This was actually super cool because we have people from Canada, Texas, California, New York of course, people in Europe, South America, and it’s amazing how different it is. When you see somebody’s outside of their house, or their neighborhood, or whatever. Some people live in super urban areas. Some people live way out in the woods, people in Canada it’s snowing all the time, people in Texas it’s hot, and it’s just gives you this different perspective on the people on your team when you think about what’s happening outside the walls that you’re seeing in the video chat, and it really … I think it leads to a much better team collaboration.

The next thing we learned a lot about is how to communicate. Everybody knows that communication is super critical. The thing that we think about is how communication starts with presence, and what does it actually mean to be present? You don’t actually have more presence just because you’re physically in the same room. There’s lots of different kinds of presence, and that’s certainly one that embodied presence where you’re physically together, and people are doing things with this for remote teams with these kind of weird devices where you can kind of remote into a place, and drive around, and talk to people. They seem kind of cool and pretty weird. We’ve never tried them to be honest. If you have I’d be curious to hear how that goes. But there’s other kinds of presence too luckily, and those kinds of presence you can actually replicate very well in a remote system.

Things like active and willful presence where you’re in there participating, maybe you’re voting on things, or leaving a comment, or reacting to somebody else’s comment. There’s mental presence, and emotional presence, and all of these things again that can happen remotely focus on them. If any of you are like me, you might have worked places where you have meetings where you are all physically present in the same place, but all of those kinds of other presence aren’t happening at all. People have their laptops open, and they’re doing emails, or whatever. They’re checked out, they’re not even thinking, and … I don’t know. What’s the point of that? It seems like a waste of time to me.

I try a lot. We try to even though we’re not physically present with each other we try to set the expectation that people are present when they’re interacting with each other. Another big aspect of communication is about listening, and supportiveness, and that’s a big part of our design culture as well. Our designers are makers. They sit down, and they attack hard problems, and they need time, and quiet to focus on that, and come up with good solutions. If we’re gonna interrupt those people, and ask them to come to a meeting, and break up that time, we want to make the most of that time, and so we try to again set the precedent that everybody is present, and attentive, and paying attention, and putting effort into really listening actively. If you’re listening carefully you’re really giving the gift of your attention to people, and you’re hopefully developing better ideas as a group.

You’re probing to understand things better, and I find when people poke me, and I have to keep re-explaining myself I start to understand my own ideas even better. Hopefully you’re building on each other, and kind of like collectively coming out with better ideas as a team than any individual was, and that’s really how the whole can become greater than the sum of its parts. Finally, we’re big believers that design is a team sport, and because we’re remote it’s even more critical that we have these natural collaborators who are going to come in and really want to collaborate, and work together. We’ve added this to our interview process where we actually test for this in the process, and we try to evaluate if a candidate has those soft skills, and that emotional intelligence to participate in this kind of a remote culture, and what we do there is we try to create … We do the typical kind of interview stuff where we talked about some work they’ve done, and ask them questions, and that kind of stuff.

But there’s also a segment where we try to make it as non-interview-y as possible. It’s just a group of people that get into a video chat, and they might talk about a problem together, and try to solve that design problem. They might critique something, they might just kind of think about a discussion or a topic to talk about, maybe there’s a new product that came out, or a new tool, or something like that, and what we’re trying to do is just get a sense for what that person is like when we’re interacting in a remote environment, and in a very unstructured kind of conversation. How to listen to other people, how do they contribute, how do they share their opinions, how do they challenge people, and things like that, and how do they handle some of the awkwardness, and ambiguity that comes with just a unstructured, weird, remote conversation.

We’ve done some things around this to try and incorporate this concept of listening, and communication more into our company as well. As another company wide thing we do, we host our meetings fully remotely now, and we use to do this thing that I see a lot of people do where if we had a meeting of five people, and four of them are in New York, and one was remove, the four people would pile into a conference room, and put the remote person up on the TV, and have the meeting. What we realized was inevitably happening there. It was the remote person kind of can’t hear so well. If you put a drawing on paper, or writing on a white board they can’t see it so well. Often there’s lag when they’re talking, they’re talking over somebody who’s trying to talk, and they just have a second class experience to that meeting.

If you’re spending so much time and effort to find these amazing people, to add them to your team regardless of where they are, if you’re putting that kind of a barrier in front of them, and preventing them from contributing fully to the meeting, that seems like a big loss. What we started doing is if anybody in the meeting is remote, even one person, everybody does the meeting remote. We all sit at our desks. It’s kind of funny sometimes. You see people all next to each other, and they’re all talking to each other through the computer, but that’s because they’re talking to one other person who’s not there in the office, and it gives this leveled, even playing field for everybody in the meeting. It lets everybody contribute equally, and it contributes to this concept of having a single, unified culture. Not these separate, remote, and in person cultures.

We also do this design studios exercise for our design team. We used to do sorta a typical kind of stand up meeting for the design team where they get in and say what they’re working on, and problems they’re facing, and that kina stuff, and we started doing these kind of ice breaker warm up things in front of that, and that sort of took on a life of its own, and this whole half-hour segment at the beginning of each meeting now, and people do different games, and warm ups, and stuff like that, and usually by the end people are laughing, and joking around. What it does is it really serves to kind of get people relaxed, and let their guard down. What we found was then when you go into kind of the stand up context sharing stuff, it’s just a lot more comfortable, and a lot more collegial, and it just goes a lot smoother.

We find that listening stuff where we try to structure those meetings so there’s not a critique in there. It’s really about listening, and all of this is a setup for follow up conversations. People are paying attention for … Are there pattern inconsistencies that they’re seeing in people’s work? Are there … Is there a place just to optimize for experience unities? Or overlaps with other work that we’re doing? Or maybe we should sync up on that, and what we’re trying to do is build relationships there, and spread context with all the work that’s happening, so that there could be follow on conversations later, that then produce even better work.

Okay, this last one is huge for us. As we’ve done this, we have come to think of the collaboration tools as our new work place. When we’re using Trello, and dog food in Trello, we aren’t just dog-fooding Trello, as any team we’re dog-fooding as a remote team, and in that sense we’re already kind of living this future work kind of aspect that kind of a lot of people have been talking about, where we’re all working remotely. The effects have really been pretty amazing. When you work remotely you sort of experience the social aspects of these tools, and how they connect you to your team members, and they become much more than just a means to an end. It’s not such a transaction or relationship with your tool anymore, it becomes really a conduit to your team members. It’s sort of … I likened it to the way you kind of have to work exclusively on mobile devices for a while to really get mobile, and be able to design great stuff for mobile.

Working exclusively remotely, and using these tools in that way has really changed how we perceive building the tools themselves. We found that we just care a lot more about the tools that we use because they are a primary experience about the work, and our primary experience about each other. The tools that we found that work best for us are Zoom for video chat that we use Trello a lot, we us InVision a bunch on the design team to share designs, and mock ups, and prototypes, we use Mural a whole bunch for kind of real time collaborations, or free form collaboration, Figma is a recent addition that people are using a lot, and DropBox we use a lot for specs, and kind of written collaboration. You might like other tools, and that’s find too.

The thing that I obviously have realized is that once there’s these functional needs met, once you have the right features to do the thing that you want to do, what it comes down to is that the choice of tools is really about the warmth and humanity of that tool, the way it fosters those emotional connections with you and the tool itself, and you, and the other people on the other side of the tool, and the amount of social value it provides for your team. Again, that’s been a big insight for us that the collaboration tools are social places. When I think of, for example, the way Slack has emoji reactions now, and people can leave a message, and that a bunch of reactions pop up there, and I’ve talked to people about that, and people kind of develop their own language within their team, like these emojis mean different things.

We have this whole thing where it’s like you say the same thing as somebody you have to use the gun like jinx, but then people didn’t really like the gun, so they changed it to finger pointing, and then whoever wins you can give them a cake emoji as their prize. It’s weird. It doesn’t make any sense, but it’s this culture that you’re building up, and it’s this way of communicating, and it’s this language that you have, and I think we’re just kind of at the forefront of where as an industry we’re building tools that incorporate that kind of stuff, and replicate that sort of empathy, and connection that you would have in person, because if you’re in person you’re doing that stuff, you would like make faces at each other, and maybe do hand gestures, and you’re communicating there in ways that are not comparable.

I think there’s a ton of space in building collaboration tools to think more in this way, and to build those kind of things. I think we’re just getting started, and it’s going to be really exciting to see what people build there. To loop back on the question I asked in the beginning: Can I get great outcomes with remote design? For us, the answer has been yes. I do think it works, and I’m a little bias, but I think we’ve gotten great results. There are caveats though. You need the right people. You need people who are going to work well in that environment, and that’s not everybody. Some people will like that, some people really will not like that kind of environment, so you need the right people to do it. They need to be self-motivating, proactive, great communicators, super strong soft skills, natural tendency for empathy.

We found that we can’t escape timezones. We’ve tried it with people who are like 12 or 14 different than New York, and that really hasn’t worked well because there’s not enough overlap, and you can’t get to know people as well. What we’ve said we try to base our team around New York afternoons. We say from 12 to 4 in New York time. That’s when everybody is working, and that might be the beginning of your day, or the end of your day, or the middle of your day, it’s really up to you, but that’s the time when everybody is working, and we can do whole company things, or whole team things. That has really helped us a lot to give this sense of this community where you don’t feel like you’re working, and nobody else is.

Most importantly is something you need to embrace as a company, or at least the whole group because there is this danger of falling into … Especially if it’s a hybrid team, this concept of two cultures remote, and in person culture, and that’s not a great experience. I think it’s really important that there’s one singular culture across the company. It’s something that has to be really embraced from the top. A couple quick insights that we thought about from product design that came out of all this for us. Our remote point of view has helped us to make our own product better. It’s helped us to understand the details that matter, build things in. We think a lot about the experience that people are going to be having, the way what they’re expecting the app to do, and how we can sort of surprise them.

Sometimes in just goofy, funny ways, but also other times in “Oh, that was super helpful. I didn’t even know it was going to be there.” In ways that you can kind of let your product connect more with other people. It’s really emphasized how important it is to focus on that kind of stuff to us more so than just adding, and building features. Lastly, this idea of being a cool landlord. If you’re going to think about your product as a workplace that people are going to, and physically being in, it’s probably a good idea to be a cool landlord, and let them paint the place, put stuff on the walls, and really ultimately feel like they really belong there. In Trello, when we think about your board background, stickers, card covers, that kind of stuff, what we’re trying to do there is make it so you can make a home for your project, where your team feels like your team’s personality, and culture is part of that, unless there’s just this transactional tool that you’re using, and putting data in, and running reports, and that kind of stuff.

We’re really kind of building something where you feel comfortable, in a way that if u are a co-located team you might make a design den, or has stuff all over the wall, and cool, inspiring things. That’s how we want your project to be in Trello too. That’s it. If you’re part of our remote team, I hope maybe I shared some ideas that might help you operate in a way that emphasizes that empathy component of being remote. Even if you’re not, but if you build something collaborative, hopefully I gave you some food for thought on how software can foster those human connects, and help build empathy among team members. Again, I really think the collaboration tools that do this super well are going to be the collaboration tools that win over the next few years because while it’s critical for remote teams, it’s stuff that matters, and makes a big difference for co-located teams too. It’s just something that results in better products overall, and I think the ones that focus on this and do this well are going to be the ones that win out. Thank you.