How to manage a remote Customer Success team

February 25, 2016
/ By Nils Vinje

When I managed a remote Customer Success team, we developed what I like to call the “stepchild syndrome.”

With ten CSMs in San Francisco, three in London, and only one in Korea, our CSM in Seoul consistently drew the short end of the stick when it came time for video calls. They were at convenient times for the American and UK CSMs, but he had to dial in at 3 am. As you can imagine, he was pretty groggy.

My solution to the stepchild syndrome was to compensate for our bad meetings by making myself available at all times. If he couldn’t make our meetings, I would respond to all of his questions really quickly. If he pinged me with a problem at 10 pm, I dropped what I was doing to answer.

At the time, I considered it part of the job description. I had to support my entire team, and since I couldn’t be there for all of them in person, the least I could do was to be at their beck and call.

I wound up on what felt like a 24 hour cycle, and didn’t have time to check in on higher-level problems with my remote team. We were only focused on the crisis at hand. It was inefficient, and made everyone unhappy. Eventually I learned that “always be available” isn’t a system.

When you have a globally distributed team, CSMs sometimes compensate in really painful ways—ways that can actually hurt them. You wind up, ironically, playing a support role to your support team. But you don’t have to. Here’s how to manage a remote team of CSMs in a way that’s actually more efficient than having them all together.

How to have productive meetings

When we finally did get on team-wide calls, it was usually a jumbled mess. The sound went in and out, someone lost their confirmation code, someone’s kid was crying in the background—you know the drill. It looked a lot like this:

And while this video is funny, when it happens in real life, it’s infuriating. It’s great to get face-to-face with your team, but putting 100% of your communication through video and conference calls is a rookie mistake. Information is lost, it’s not written down, someone’s video goes out at the last second, or someone is distracted by what’s going on in the room they’re actually in.

A CSM’s job is to help. So, naturally you want to always be on. You want to take meetings. You want to hop on a call when someone asks. But this winds up being inefficient. The real solution to this problem is to cut down your number of meetings. Make yourself available less, so when you do meet, it’s about something really important.

As Jason Fried, co-founder of Basecamp and author of Remote: Office Not Required writes:

Meetings should be great—they’re opportunities for a group of people sitting together around a table to directly communicate. That should be a good thing. And it is, but only if treated as a rare delicacy.

Here’s how you can start making meetings feel less like a chore and more like, as Fried says, “a rare delicacy.”

‘Asynch’ your meetings

We have a strong impulse to get on conference or video calls. It’s what co-located teams do, so since the technology is there, a lot of distributed teams want to do it as well. In fact, asynchronous communication—that is, without a set time for everyone to gather together—can be even more effective than in-person meetings.

If you want to get the whole team together to communicate something everyone needs to know, it’s a great idea to do it asynchronously, whether that’s via chat, daily memos, or weekly email updates. Even better, you automatically have documentation of everything that happened in a meeting. This makes your notes searchable, archivable, and really thorough, since they’re not even notes—they’re the actual meeting.

So that one person who’s never paying attention will be able to go back and look not just at the minutes but the meeting itself for clarity.

Hold 1:1s to get face time with individual team members

It can be easy to forget that CSMs in different regions might have totally different problems—ones that you don’t implicitly understand. Customers in Australia might face different issues than customers in Seattle. If your London team doesn’t have Product in their office, they might not understand a new feature. Maybe your New York team leads just plain old don’t get along!

In order to really understand these differences, and address your CSMs’ specific problems, you need to talk to each team member individually. This isn’t the kind of stuff you talk about in team-wide meetings and memos. It’s much more personal, and specific. The best way to do this is by holding weekly 1:1s. Here are some tips we’ve found especially useful:

Keep 1:1’s to at least half an hour. If they’re too short, they won’t have time to talk about general problems or concerns—they’ll want to focus time on more pressing matters. Longer 1:1s also help build rapport, which is critically important (and hard to do) in distributed teams.
Schedule for the same time every week, and never, ever, ever cancel at the last minute. There’s nothing worse than your manager canceling at the last second, especially if you stayed up late (or got up at 3 am like our Korean friend) just for a meeting.

How to handle a process change

Process changes are straight-forward in a co-located office. You send a memo or tap someone on their shoulder, tell them the change, and you can usually assume it’s been made. It’s easy to think that the same thing happens with remote teams.

But in a remote team environment, that’s not enough.

This problem is compounded for Customer Success Managers. A CSM has to know processes inside and out. It’s how we help customers understand and better use a product. If a CSM doesn’t have the right information, they end up not helping, but hurting the customer.

Demand confirmation for changes

In his video on how to run an art studio, artist Tom Sachs offers workers one tip that applies to just about everything in life: always demand confirmation.

Just like you need a receipt for a FedEx package, you need a receipt for that comment you made on someone’s project. You have to get a receipt to confirm that the action happened and was registered. As Sachs writes,

“Without a receipt, your actions can not be proved. Without a receipt, you don’t exist.”

The same applies to process changes. If you don’t get confirmation, you should assume it never happened. We’re bombarded with information all the time. Some of it sticks, some of it doesn’t. This is especially relevant for CSMs—since they’re the ones communicating with customers, any misinformation or confusion on their part trickles directly down to customers, who need the right information at all times.

Your job as a CSM is to make sure the important information sticks.

Trello is our weapon of choice for making information sticky. We make a card with everyone’s name on it and they not only have to read the card but tick off that they’ve read it. That way, we receive visual confirmation that everyone has read the entirety of a change, understands it and is ready to implement it. It also means that people actually adhere to the process changed—they’ve signed on to it, so now they’re beholden to it.

Empower your team to change processes

Remote teams are all about adhering to processes. When there’s a new one in place, it can really shake things up. It can be particularly bad for remote CSMs when new processes don’t make sense. When you’re co-located, you can easily tell when something isn’t working. When you’re distributed, it’s harder to voice that.

That’s why Des Traynor from Intercom has his team treat their internal documents like code that they can all edit. He conceptualizes the company’s processes and internal documents as the software the team runs on. With buggy software, your team will break down.

The best part of this system is that the “code,” or processes, should be open source. Every member of the team can open and edit them if they think something will work better. When done properly, they build a framework for your workflow that’s constantly iterated and improved.

So if something isn’t working out for your team member in Korea, they should be able to say so and provide an alternative.

How to keep everyone in the loop

In a distributed team, it’s dangerously easy to keep people out of the loop.

When I took over as lead for a remote team, I discovered that the London group had been operating largely on their own. We were an analytics company and the London office had offered customers a “services” option—essentially, consulting. It came as a huge surprise, because it simply wasn’t what our company did. It wasn’t in the CSM job description. They were doing what they thought was right, given the needs of their customers and the resources available to them.

But no one had any idea, because we weren’t kept in the loop.

This really bit us in the end, since when the guys running the consulting service left, no one knew how to take over their job. We were at risk of losing all their clients, since we weren’t prepared to fill the roles they’d carved out for themselves.

That’s why you need transparency across the board. Whether it’s a process change, a new hire, or someone in the San Francisco office is going on vacation, everyone should know—the repercussions might be bigger than you think.

How OpenDNS communicates like crazy

As Chris Doell, VP of Customer Success at OpenDNS says, the best way to keep everyone in the loop is to over-communicate. The one potential problem with this system, however, is information overload. When you send a ton of information, the important bits can get lost. It’s hard to find the signal through the noise.

That’s why it’s so important to systematize team communication.

At OpenDNS, that system is a team newsletter—a weekly roundup of the most important information communicated via chats, emails, and meetings. Make sure it’s not a last-minute, throwaway project. Spend a couple hours on it. Theirs includes:

Important changes that have been made to workflow
Feedback from customers
Congratulatory shout-outs

They also send it at the same time every week, so team members can expect and rely on the newsletter system.

If you don’t systematize where information is going to and coming from, people won’t know where to look. Was that new schedule buried in a Slack conversation? Or an email that they accidentally deleted? Whether you choose to communicate in weekly memos, Trello, iDoneThis, Milanote, or Slack responses, consistency is key.

Never rely on tribal knowledge

In addition to keeping everyone in the loop on new office processes, it’s important to document the existing stuff too. Everyone might implicitly know what hours your office keeps, but if it’s not written down somewhere, it quickly becomes tribal knowledge—an oral history that you only know if you’re on the inside.

Tribal knowledge simply doesn’t work in a remote team. Without explicitly stating things like approximately how long your calls with clients are, you should just assume that no one knows it.

Documenting these elements of your workflow and culture are also immensely helpful with the onboarding process. The next time you take on a new CSM, you’ll have a ready-made primer for them on what it’s like to work with this team. In a remote team, onboarding is especially tricky. You can’t lean over the desk of the person next to you and ask them a question. You have to acknowledge that you don’t know something, which can be hard.

Julie Alex remote working

Alex has been working with his amazing remote assistant Julie for a number of years now. She’s worked from Bali, Dubai, and Seattle, but their workflow remains exactly the same, no matter where she is. This is all thanks to Julie, who likes to remind Alex:

“What happens in vagueness stays in vagueness”

If anything, being remote has made working together even easier, since they have so much documentation to go back and search through.

That’s why having a remote team can be more efficient than a co-located one. A lot of the problems that afflict remote teams are just exaggerated versions of the ones you see in an office. Sure, an in-person meeting is better than a virtual one. But you’ll still wind up with a couple of people only paying attention to 10% of what you’re saying.

Being remote forces you to be more explicit. You have to create systems. You have to adhere to processes. You have to over-communicate. Here’s the real kicker: this would actually all benefit co-located teams, too.

Remote teams, when done right, actually have an advantage over co-located teams. Good documentation and communication gives team leads a ton of data and insight into how the team is doing. You can easily tell what’s working, what’s not working, and how you can improve. If you implement these systems, your remote team will rock it from the other side of the world.