Research by Global Workplace Analytics found that the number of full-time US employees who regularly work at home has grown by 115% since 2005. Given this trend and my experience building a fully distributed customer success team at Geckoboard, I thought it’d be useful to share what I’ve learnt about hiring and managing a distributed customer success team.
Identifying if a distributed team is right for you
Building a distributed customer success team isn’t right for everybody but when I joined Geckoboard, the data told me the following:
- The majority of tickets were created outside working hours (in our case, UK business hours).
- Over 60% of our customer base was in the US.
- Our first response time was over 30 hours.
- Our ticket backlog was out of control.
Evaluating shift work vs distributed teams
There were two solutions: Implement shifts in our London HQ or build a distributed team. We chose the latter because working non-business hours leads to lower productivity. Most people aren’t at their best when working non-business hours as part of shift work, despite being great at what they do. A study by ACAS advises that shift work “can upset employees’ body rhythms and affect an employee’s performance and health.”
Another reason: Shift work contradicts Geckoboard’s culture. A key cultural value is to “Prioritise health and family over work ALWAYS.” The above research suggested shifts would contradict this.
Shifts may work better when customer timezones aren’t as diverse from headquarters or the company culture differs. For us, building a distributed customer success team was definitely the best option.
Hiring a distributed team
Ticket volume data based on time zones, business goals, and budgets will define when and where to hire. My biggest lesson was not to restrict the search to certain locations. Instead, leave it open and just mention ideal parts of the world in job specifications.
For example, I thought we would hire in the PST time zone first. It would give us 15 hours of consecutive coverage when 70% of our tickets were created. However, we hired someone in New Zealand, because the candidate was too good to ignore and gave us additional time zone coverage. The more specific you are, the more likely you are to trade talent for location and it’s best to get a balance of both.
The traits I look for in distributed hires
Beyond location and general customer service skills, I look for three key traits in distributed team members. Our hiring process consists of interviews as well as a task to test for these traits:
- Independence: During the task we look for people who answer questions and connect dots for themselves without handholding. If they can happily work independently and remove blockers themselves, they’re able to make progress when no one else is online.
- Value remote flexibility: If someone is fed up of the daily commute or has good personal reasons for working remotely, the positives of distributed work will far outweigh the negatives making them a good long-term hire.
- Communication: When you aren’t able to have watercooler conversations or tap someone on the shoulder to fill them in on communication gaps, strong communication is essential. If anything, they need to over-communicate.
Managing a distributed team
It’s definitely more difficult to manage a distributed team vs a centralised one. However, some elements of management are more important when managing a distributed team:
- Weekly 1:1s: Having the entire team together might be tricky (or impossible), but you have to meet with everyone individually at least once per week. Remember, you are their eyes and ears if you’re in HQ. If not, you’ll still have more insight about things they care about and need to know to do their job.
- Be Transparent: The more knowledge you have, the more included you feel despite the distance. Transparency and being straightforward ensure distributed team members are constantly informed. If anything, over-inform them.
- Empower them: A culture of micromanagement will make building a distributed team tough. Hire people you trust and don’t punish the inevitable mistakes we all make. On the contrary, empower them! There might not be anyone else online when they make an essential decision. You want them, when needed, to make that decision. Otherwise customers are waiting for a resolution, which makes out of hours coverage meaningless. If they were wrong, explain why and what should have happened then document it so anyone facing that situation again can do it right.
- Document processes: It is important to have all processes well documented with tools that support collaborative work.
There are many tools available tools to help you manage a distributed team:
- Real-time messaging is essential for any distributed team. We favour Slack as we can create bots that do things like connect to the calendar so we know when distributed team members are offline for a customer call, an errand etc.
- An internal documentation tool avoids reinventing the wheel when questions come up internally and reduces delays for distributed team members when they have a question, because they can self-identify an answer.
- A support ticketing software is essential to keep track of performance, reassign conversations, write internal comments and in general work as a team despite the time differences. I like using Zendesk for this because of their collaboration functionality.
- A project tracking tool makes reporting and working on bugs and other projects across teams simple. We use Clubhouse as that’s what our Engineering team are using for bugs.
- Video conferencing software is generally the enemy of distributed teams, but Zoom has proved to be the most effective tool for the job after trying many solutions.
Measuring the success of distributed hires
The visibility of metrics is key when managing a distributed team as you can’t physically see what someone is doing on a daily basis. Early on, I kept a close eye on the number of tickets distributed team members worked on to ensure working remotely wasn’t hampering them. The Agent Activity dashboard in Zendesk Insights was helpful to track performance for distributed team members. We also use our own integration with Zendesk to ensure everyone has visibility on performance against goals across the team to keep them motivated.
Given first response times and full resolution time were the two metrics we wanted to improve with a distributed team, I tracked these very closely and we now keep first response time below 60 minutes.
Don’t be afraid of building a distributed team once a need is identified. Avoid being too specific with time zones during the search. Hire people you trust who are resourceful and value the flexibility and perks of working remotely. Empower them whilst giving them documented processes and as much visibility into what’s going on in the business as you can. Good luck if you’re about to start the journey, and I’d love to hear about any additional lessons you learn/have learned when building a distributed Customer Success team.
From Guadalajara in his native Mexico to Bangalore in India, over 9 years Luis Hernandez built up experience working as part of a distributed Customer Support team at HP, Fon, and Argon Telecom. In 2014 he ventured to London in the UK to join Geckoboard, the SaaS tool for building live TV dashboards, to scale their customer success team from their HQ.