Last Friday I spoke at UserConf about how we run distributed support teams at Automattic. The talk was about 30 minutes and I’ve written it up, with slides included, as a blog post below. You can also download the full slide deck. The video is now online, too.
Howdy everyone. I’m going to talk a bit today about how fantastic distributed support teams are for you as the people providing customer service and for your customers.
You can find me on Twitter or follow me on this blog. I tend to use both for sharing and posting links to interesting bits I read elsewhere.
I’ve worked in customer service for about 11 years now. My first job was at 14 years old where I worked in a taco stand at Yosemite National Park. In many ways working with tourists in a National Park is a crash course in customer service. The manager had me work the cash register because he was convinced a 14-year-old would bring in more tips. It actually worked!
From there I’ve worked in tourism, helped start, and close, a small tech company, and now work at Automattic.
At Automattic we make various tools for democratizing publishing. Blogs, security and backups, videos, and more. The centerpiece of what we do is WordPress.com and that’s primarily what my team provides support for.
That’s most of the team I work with. The photo’s from our meetup in May and since then we’ve grown by 16 more Happiness Engineers. We span from Budapest all the way to Japan and everywhere in between. Across Automattic there are about 50 Happiness Engineers and 8 of them are here at UserConf.
One of the first things I want to point out is that small, distributed teams can have a huge impact. Those are some stats from a regular day over the summer for us. In our primary support queue for WordPress.com we see about 35 tickets created every hour in addition to about 35 replies sent.
So while we might all be individuals working from home offices and co-working spaces we can still have a huge collective impact on a platform that helps to power 20% of the web.
Anyway, so on to the core of the talk. I realize UserConf is in San Francisco but I wanted to not assume too much tech knowledge for this talk. So, with that, what do I mean when I say Automattic runs a distributed support team?
What I don’t mean is that you have a central team working in the office with a subcontractor working remotely. That’s not distributed. I also don’t mean where the team works in an office and there’s that one guy who works from home 3 days a week because he’s been at the company for 25 years and that’s the arrangement he has. That’s also not distributed.
What being a distributed team means for us at Automattic looks like this:
Those are the rough locations of the team we work with spread out on a map. From Japan to Sri Lanka to Hungary, Los Angeles, and more. At its core being distributed means being location-agnostic.
When we hire people we don’t look at where they live. We don’t require them to move. We just look for the best people and trust that they’re happy wherever they’re living. We believe that the best customer support people in the world aren’t found in any one location, except for maybe this room, right now. The best people are found all over.
How does it save us?
So how does this set up save us? After all, we’re the ones who work in this environment every day, it wouldn’t be much good to stand up here and give a talk knowing we all secretly hate this distributed thing. Spoiler: We love it. 🙂
Having a distributed support teams saves us in a few ways. I’m going to focus on couple particulars here.
Distributed support optimizes for personal happiness.
That notion rests on 2 key values that I believe to be true. They help guide some of how we build the team.
The first is that autonomy improves self-discipline.
I think that the more control you have over your own work environment the more likely you are to excel. When you’re trusted to determine your schedule and find the solutions to customer problems you’re going to build the right habits. Working when you’re happy and productive, living wherever is best for you, researching solutions instead of memorizing scripts, these are all things that lead to a healthy work environment and happy customers. In support our goal is to help solve customer problems and create knowledge that allows them to be more self-sufficient and successful. There’s no reason we shouldn’t take the same approach internally as a team.
The second principle I hold to be true is that happy people are most inclined to share and spread that happiness.
We’re Happiness Engineers, right? We don’t want to create a culture of sadness. That’s not going to help our users. If we can orient decisions toward increasing our happiness then it will also inevitably increase our users’ happiness.
A new type of team
This foundation means that, in many senses, we can build a new type of team. We can build a world-class support team that doesn’t limit ourselves to any single geographic location. Instead we can build a team based from a view that looks more worldwide. So that we can end up with a team spread out like:
We can step back from the pressure, trends, and isolation of any particular geographic area. There isn’t a central, geographic ideology that’s predominant. The languages, values, ideas, and lifestyles of our team are distributed around the world, just like our users.
That built-in geographic distribution, what I earlier called being location-agnostic, means we can say No to a lot of things. A lot of things people assume to be required of a customer support gig we don’t need to worry about. In our day-to-day work we have:
We have no set shifts. We prescribe no particular schedule. And we ensure that no one pulls a graveyard shift.
I mean, seriously, would you rather get help from someone working at 9:00 in the morning from the farm he lives on in Sweden or from a guy chugging Red Bulls to stay awake through the 4am closing time of his shift? Pretty sure one of those situations is going to provide for a lot better customer experience.
By saying No to these things, though, we had to build tools and habits that help us optimize for the personal happiness I mentioned earlier. When we’re spread around the world we can’t rely upon the same office habits that get things done in person. I’m going to talk about 3 aspects of these habits that we built.
First, we aim to document everything.
How many people would love it if their company had better internal tools and documentation? How many times are you stuck walking down the hall to find Jack because he’s the guy who built this tool 4 years ago that no one else really knows how to use but you know it fixes this one bug that happens every six months?
The way we’ve fixed that in a distributed team is that we document everything. The goal is to remove silos. No one person should be the gatekeeper to knowledge about how to help our customers and help each other.
Second, we don’t use email.
It’s not that we all have inboxes totaling in the thousands because we choose never to look at it. It’s that we actually don’t use it. Something like 3% of our entire company communication happens through email and much of that is to external sources.
On a support team, email can create a complete stumbling block for finding information. How much of your own work relies upon instructions, information, or references that were sent to you via email? What happens when someone new joins the team? How can they access that institutional knowledge?
To solve some of those questions and to replace how most teams use email we built this internal WordPress theme codenamed O2. Communication is oxygen, after all.
This theme updates in real-time, is oriented to conversations, and is public to everyone in the company. We have about 150 internal blogs like this. Each team, project, or interest has one.
There’s nothing about this tool that is limited to being used by distributed teams. However, when you’re in an office together it becomes much more difficult to build habits beyond the convenience of walking over to someone’s desk and asking them a question verbally. Remove that option and you suddenly have much more scalable default habits.
Here’s the part that really saves our sanity about them: they’re public to everyone. From the moment you join Automattic you can access every site in the entire company and find the archives going back years before you joined. So it’s not that every person will solve every question. It’s that every one of us should have the tools and information we need to do so. Sometimes we’ll still use IRC or Skype to ping and ask for help. More often than not, though, the answer lies on an O2.
There’s a theory called Jevon’s Paradox. When loosely applied to communication it means that as we acquire more efficient means of communicating we spend more, not less, time communicating. That’s how O2s work for us. They are so oriented toward conversation and information retrieval that we pour so much of our internal data in to them. So while we aren’t all in a central office together we end up spending more time, not less, communicating with each other.
It’s not all work and documentation, though. Something I didn’t appreciate when I joined 4 years ago was that these internal blogs also give everyone access to the company’s in-jokes. There’s very little of that “Oh, you should have been there…” sentiment.
You want to know why we own youreffortstodaydisappoint.me? Well, it’s there. Complete with the meme-based thread from the day the support team went a bit loopy.
Maybe someone references the giant fuck off bear that distracts you from your creative moments? Well that joke and video is right there too. Any time you want you can get a crash course in company culture, jokes, history, and personalities.
So a distributed support team allows us to build habits of documentation and avoid the walled gardens of an email inbox.
Both things that save us. The final thing I want to mention about how distributed support saves us is about our work environments.
Someone on the team phrased it this way, “It’s easier to relate to users as individuals when you’re a single person surrounded by your own environment than when you’re stuck in an office.” That’s what it’s all about right? We all chase that ideal of personal, caring support that flows from human to human. We’re not a script, a company, or a ticket number. We’re people.
We can all have great desk setups but there’s something about your home environment that’s difficult to replicate. The food’s what you love, the temperature is how you like it, the lighting’s what you want. Everything is set in a way that’s meaningful and personal to you. With that background it’s exponentially easier to let personality, happiness, and warmth flow in to your replies.
Since we don’t have schedules, shifts, or prescribed locations we can work anywhere. And our work setups mirror that. This is someone’s temporary desk at her sister’s place. She’s always on road trips with their family and surround themselves with just what they need while driving around the US. I’m pretty sure she never actually works from home.
Or, maybe you’re a former librarian who appreciates the use a good set of encyclopedias can be put to…as a monitor stand.
Or, maybe you’re me and all you want is a clean, electrically-adjustable desk that has a single screen on it. Either way it’s my set up for work, not the typical one.
And, what tech presentation would be complete without a cat picture. I mean, seriously, how could you not want to make users happy when you have those two guys hanging out with you all day? I don’t know what their typing skills are like but I’ll give them the benefit of the doubt.
So that’s how distributed support saves us.
It saves our time in that we can work when we feel most able to work productively and happily.
It saves our sanity by creating habits of documentation and removing the burden of a clogged email inbox.
And it saves our happiness by keeping our work environments personal and meaningful.
How does it save our users?
Now, how does this team set up save our users? After all, they’re the ones that we do this for. There are three things I’ll highlight here
First, it saves our users by allowing for faster response times.
The team’s all over the world. So that means that if you’re living in Budapest and notice something breaks or if you need an urgent fix you’re not waiting for the US to wake up. You have a Happiness Engineer living in Budapest who’s just finishing his morning coffee and starting the day. He’ll help you fast!
There aren’t really silver bullets in support, but I think faster response times is as close as we’ll get to one. The same answer delivered 6 hours faster is inherently better.
In our primary ticket queue here’s what our incoming volume looks like:
That’s our incoming ticket volume over the course of a fairly typical day. The timestamps are UTC so the big swell you see is basically the United States waking up and wanting to blog. It’s a 10x difference between the lowest hour on the graph and the highest.
While WordPress.com is used all over the world our users are still predominantly based in the United States. Since part of what we look for in hiring is community involvement our team distribution also generally mirrors that.
And that’s what our response times look like. It’s a nice mirror image. The one spike, at 14:00 UTC, is from the US-based crew signing on and clearing out a handful of older threads.
No hour is higher than 12-hour average response times and most are much, much lower. So when our ticket queues are the busiest our response times are the shortest. To users that’s a pretty clear win. How often do you get to say, “Oh, hey, we’re really busy right now so we’ll get back to you faster?”
Those response times also mean that users get really happy when we spot their problem quickly. And since users are nice people they sometimes want to send us a thank you in return.
This was from a lady in Australia who was so aghast that we didn’t know what a TimTam was that she shipped like 12 boxes of them. Pretty cool.
The second way being distributed saves our users is in terms of language. Having our team spread around the world means we get the built-in benefit of being able to help our users in any number of languages.
The team speaks Japanese, Spanish, French, Hebrew, Farsi, and more. It’s something that’s useful for our users not just in how it can impact their support interactions but also how it impacts their broader local community.
When a blogging service in the Netherlands was shutting down there were a few thousand Dutch bloggers who were looking at losing their sites. Someone on the team was living in Amsterdam, though, and was able to reach out to the company, get an export process in place, and ultimately help those bloggers transition their sites over to WordPress.com.
That’s an entire opportunity that we would have missed had we not had a close connection to that language community.
And that brings me to the third way our distributed team helps save our users. That’s through community. Ultimately our distributed team means we can help people from our own locales.
We have Happiness Engineers spread across 48 cities in 11 countries. It gives us a great base from which we can help people locally, as well as globally.
As part of that community we get to help put on events all over the world. Our users benefit by having true community events. Not just having conferences and events that the company sponsors, flies in to attend, and leaves.
Having someone local puts a consistent face to your product. It becomes not just about your customers building a relationship with a Community Manager; it becomes about your customers building a relationship with Naoko. Our staff are invested in local communities right alongside our customers. Our customers end up getting help and organizing events that are meaningful to them. They get to share their love of WordPress with others and help others learn. Ultimately, there’s nothing more empowering than teaching somehow how to use a product that you love.
Path to employment
Finally, a bonus benefit for our users is that our distributed team gives power users a path to be something more than just a power user if they want. That’s something that helps us and helps our users. It means that some of our most consistent contributors can start doing the same work as work rather than squeezing it in as volunteers. Additionally it brings faces which are familiar to the community in to the team, further cementing the connection.
So that’s what I call distributed happiness. It saves us as a support team and it saves our users.
A lot of what I touched on can be done in an office setting too, the question is how hard is it going to be and how many built-in habits are you going to have to fight against? For a distributed team things like local community connections, multilingual staff members, flexible schedules, and hordes of documentation come as defaults. There are no habits to break because without those things your team flat out won’t be successful.
And while I don’t get to see my co-workers every day, a true upside to working in a central office, I feel incredibly lucky to work on a team that has the habits and tools we do. A distributed setup is not for every team nor every company but I’d argue you should give it a shot. For support in particular I think it’s a natural fit. It allows people to be people. It makes it easy for your customers to realize they’re talking with a person, not a script.
If you work on a distributed team and want to share tips or are looking to build a distributed team, let’s talk. And if you’d like to join us at Automattic, we’re hiring.