High-Fidelity Collaboration and Design Philosophy at Intercom
Emmet Connolly, Director of Product Design
Within the design world, Intercom is known not only for the quality of their customer communication products, but also for the articles on design philosophy and product strategy they publish on their blog. (The infamous The Dribbblisation of Design made its debut there before ricocheting around the Designer Web and prompting numerous discussions, among others.)
We spoke to Emmet Connolly, who leads Intercom’s Product Design team and previously created Android Wear, Google’s smartwatch platform. Emmet shared his insights on integrating software with face-to-face collaboration, the importance of having a strong design philosophy, and the rewards of designing teams as well as products.
How did you get connected with Intercom?
I worked in a number of different Google offices on different projects. I had been working on search in their Zurich office, where I designed Google Flight Search, and then I started a 20% project that was to design and build a smartwatch, which I thought would be a fun thing to try. That grew legs and gained some momentum inside of Google and eventually turned into Android Wear, which is Google’s smartwatch platform. So I moved to SF and I worked on that for a couple of years, and then after that launched I was looking for new opportunities.
I had known the guys from Intercom socially for a long time past. I’m Irish, and the cofounders are Irish, and I had known them from many years ago. I was aware that they were really smart people and really good product thinkers, and so I was always observing from afar what they were up to.
When we actually got talking, it was really the people that attracted me to Intercom. The more I talked to them and understood the mission and vision of the company, the more the product also became a big draw for me. I saw a lot of parallels between what was possible via Intercom and what I had been trying to do myself in previous projects. And so it seemed like a great fit.
Having worked on numerous products as a designer, I realized that a great design challenge would be to try and design a team. When you’re designing products, you’re interacting directly with the object that you’re trying to bring into being. But when you’re trying to put together a team, it’s a really different design challenge. You’re trying to design not the product, but the entity that can design the product. It’s a much broader problem, and there’s a lot of messiness involved in that process. Things like culture, a really important part of any team, can’t really be designed — can’t be imposed. The conditions for them can be created, and I thought that would be an interesting and new thing for me to learn. And so that was what attracted me to Intercom.
How long have you been there?
I joined Intercom about a year-and-a-half ago.
Are you enjoying the experience of designing a team?
Absolutely. One of the things that’s always motivated me as a designer is to learn as I go and solve problems that I don’t know how to solve. That’s why I decided to design a smartwatch in a period where I didn’t know anything about hardware or physical products. Designing an entire operating system is a big deal in itself, and it was just a whole other set of challenges. Designing the team was one layer of it, and we were designing a set of products that had to complement each other and work together in a really coherent way but solve a totally different set of problems as well.
It’s been a blast. I’ve learned a ton. The pace has been totally different and refreshing compared to what I was used to at a bigger company, so yeah, I’m having a ball.
How does design fit in with Intercom’s culture?
It’s pretty much baked in. Many of the leaders in the company have design backgrounds, actually. Our CEO and our chief strategy officer, two of the cofounders, were designers. (That’s Eoghan McCabe and Des Traynor, respectively.) Our head of product, Paul Adams, was a designer at Google and at Facebook after that. There’s been this exceptionally strong and clear-minded approach to product thinking from the very beginning at Intercom.
That was another thing that attracted me. I figured that I had a ton to learn by working closely with designers whose work and whose thinking I really respected.
Another thing that attracted me — you can probably detect this in some of Intercom’s writing on our blog, there’s a very strong product philosophy. A very clear-minded approach to how to build product. And Intercom-the-product encapsulates a lot of those philosophies and a lot of those ways of thinking, so that was very attractive to me as well. To get involved with something where the product direction, the product strategy, and the type of usage that it suggests is all self-reinforcing.
How large is the design team there?
We were at four designers when I joined, and in the past year we’ve gone from four designers to eleven.
How does the team collaborate?
That’s a good question. As I said, so much of the product thinking, or at least the germ of the product thinking, comes from our founders and our strong philosophy. And a lot of that philosophy is around how great product teams should operate. Again, referring to some of our writing, we’ve written about starting with a cupcake versus trying to make a cake from the very beginning, and about how and when you should say no to features and to product directions. That has really influenced how we build things. Many of those ideas exist in our team design principles.
To answer your question about how we collaborate, another thing that we’re relatively strongly in favor of is optimizing for face-to-face collaboration. Things like how we’re talking now [via Skype] is incredible. The fact that this even fucking exists is mind-blowing in some sense. But it’s still extremely low bandwidth compared to face-to-face collaboration, like if you and I were in the same room together for this chat. When you add multiple people to that scenario, the bandwidth goes down even further.
A challenge that a lot of product teams have, especially as they grow and you add more people to the conversation, is how to move quickly. And a big part of the reason why they struggle to move quickly is because a lot of process — heavy, encumbered process — starts to get piled on, and so you realize, “Oh, we have to write stuff, and we have to write docs, and then I’ll have to write a spec and do a handover.” Some of this stuff is possibly outdated thinking anyway, and we do our very best to be allergic to that. Whenever possible we highly optimize for face-to-face, in-person collaboration. And the big benefit there is that we can move quickly, we can make decisions quickly, since in-person communication is extremely high-bandwidth.
The challenge, then, becomes keeping everyone in the loop. We are growing extremely fast, and face-to-face collaboration is hard to scale. When we were a team of four designers a year ago, we all used to fit around a really small table. We don’t anymore. We still fit around a really big table, but we’re growing fast and we won’t fit around a big board table for much longer. And so we’ve had to introduce a little bit of process, but we try to keep it very lightweight.
We use Slack. We use Google Docs if we need to collaborate on documents and things like that. We definitely have a principle of using less software whenever possible. We try hard not to spread our work across lots of different apps, lots of different pieces of software, lots of different channels of communication.
And then, whenever we can, we defer back to face-to-face collaboration. And, you know, that’s in the software that we use — for sending some stuff back and forth on Slack, we’ll often ping back and forth a few questions, and then someone will say “f2f?” and initiate a face-to-face conversation. There’s a threshold beyond which we should just walk across the office and meet each other, because you can get into these crazy scenarios if you’re not very careful where two people are sitting at their desks on opposite sides of the office chatting back and forth, super low-bandwidth.
We build our teams around this, so the ways our teams are structured are product-oriented, so a designer will sit with their PM and the engineers on their team, and so that’s setting them up to collaborate really closely together whenever possible. And even our entire product and engineering team is based here in Dublin — we have a San Francisco office as well, but the team that builds the product is all based here. That’s also been a conscious decision because it means that we, so far, haven’t had to deal with a huge amount of collaborating across time zones and different countries and so on. I’ve done that in the past and it’s just a world of pain, so if you can avoid it, that really helps.
In short, all the way from the types of software that we use up to how we’ve set up our teams to how we’ve set up our organization, is optimized for face-to-face collaboration.
Have you guys tried Wake?
Yeah! Yeah, we use Wake. Again, we got to the point in terms of scaling… face-to-face optimization is great, but you’ve got to look out for bottlenecks. You’ve got to look out for places where one person may be waiting on another person to become available, and so we’ve recently trialled — somewhat cautiously — a number of different ways of sharing our designs in this way, and settled on Wake.
One of the real advantages of it is that critique, which is central to how design operates for us, became asynchronous. Before, 100% face-to-face requires two people to be in the room at the same time, and so that’s a synchronous critique scenario. Moving to something like Wake opened us up to a broader group collaboration, and so all the designers on a team get to give each other more feedback and get to receive feedback from each other. One thing I’ve observed is that, in doing so, the designers get much better at giving each other feedback. There’s certainly an art to design critique, and that applies in-person as well as mediated by a tool like Wake.
“The ability to dispassionately assess your own work, to step outside of it and look at it and assess it yourself, gets better with practice.”
I’ve noticed that the more feedback designers give to each other, the better they get at giving feedback, which in turn makes them better at critiquing their own work. The ability to dispassionately assess your own work, to step outside of it and look at it and assess it yourself, gets better with practice. It’s kind of like a muscle — the more you exercise it, the better you get at being able to assess work, whether it’s someone else’s or even your own. It’s been a really nice bonus of using something like Wake for us.
What does the team do differently now than you did a year ago?
We have more than doubled in size. Adding new people has actually been great. In some sense there’s this fine balance between onboarding people and assimilating them into “our way of doing things.” It’s also been really nice to bring in new ideas and new approaches. That diversity of opinion and approach has been awesome.
We’ve tried to strike the right balance in keeping the same DNA, design philosophy, and thinking that underpins a lot of what we’ve done in the past — which runs all the way to the very origins of Intercom as a product and as a company, because a lot of that comes from the cofounders. Our task is to absorb and assimilate the underpinnings and the history of where we’re coming from, but also try and push it in new ways that still feel coherent.
“There are no real right answers in design. There are many right answers.”
I think you’ve got to try and make sure that you don’t lose what was special in the first place as you grow and change, and that’s everything from design philosophy to your approaches to problem-solving — there are no real right answers in design. There are many right answers, I guess you could say. But if there isn’t a coherency to those answers then I think the product starts to fall apart a bit.
It’s a balancing act between that on the one hand, and taking us in interesting new directions and making the most out of the people that come onboard and bring their new insights into the fold as well.
What do you think is the biggest challenge facing the design world today?
My first reaction, and this is a politician’s answer, is: I see more opportunity than challenge today. Just look at the Lego pieces that we’ve got, all that we’ve got available to use. We’ve got the internet, we’ve got these amazing tools for building things on the internet, we’ve got cheap infrastructure which makes it relatively accessible for anyone to build using those tools on that internet, we’ve got incredible access (broadly speaking) to education, which means that a lot of people can figure out how to use those things to build stuff on the internet. We now have these communication platforms which allow us to build teams from anywhere in the world. Today, where we are now, it’s so much easier to build things and make change happen than it was ever before.
“Today, where we are now, it’s so much easier to build things and make change happen than it was ever before.”
I started making websites in 1995, and in some sense I’ve been doing it ever sense. But what does that actually mean? The context has changed so much in those 20 years, and in some sense yes I’m still making websites, but what that means today versus what it meant in 1995 is a totally different thing. The scope is totally different. And not just for websites, but digital products.
It blows my mind the progress that I’ve been lucky enough to witness over the last 20 years — the ease with which we can build things, the complexity and power of the things we build. And, because the internet isn’t this niche thing anymore — everyone has the internet in their pocket now — the addressable audience is the entire fucking world, right? If I take a high-level view and step back and assess where we are today, it’s just way more wide-open than it’s ever been before.
I think there are loads of interesting questions around how platforms work, what platforms we decide to build on, whether that’s the open web or mobile operating systems or the increasing number of platforms that are actually other businesses that all of these things can be built on. I think it’ll be interesting to see how that plays out. I don’t think that some change in how things work today would be a bad thing. We’re in a kind of weird, crazy scenario in that if you have a product and you want it to be accessible to a broad range of people at any level, you actually have to build that product three times.
For Wake — they’re a small team that wanted to build a relatively simple product. They had to build that product for both the web and for iOS. Companies that have both an Android and iOS app have to go and build their products three times. That’s crazy! Imagine if they had gotten to put three times the amount of effort to building the app once. I think there’s an opportunity cost there that everyone is subject to because of the way the landscape is sitting at the moment.
Thanks to Emmet Connolly for sharing his insights about design and collaboration. You can follow him on Twitter, and see what he and the Intercom team have been building at intercom.io.
To change the way your team collaborates, check out Wake — a private space to share and discuss design work with your team.
