Drift, a company that creates marketing software centered around real-time conversations, has a tradition of putting all employees on customer support duty.
The practice was born out of necessity. Back in its early days, the company ran on thin margins, and having employees pitch in to handle support made more sense than hiring specialized customer support agents. But the practice stuck around, even after the company brought on a dedicated customer support team, and it’s still a key aspect of Drift’s company culture.
For developers new to the company and facing support duty for the first time, it can be a little nerve wracking.
“There’s definitely fear and anxiety going into it,” said Tim O’Brien, director of product design at Drift. “But I think it’s the good kind of fear.... Everyone comes around to the fact that it is a rewarding experience.”
It helps that developers now only perform support duty once or twice a quarter, compared to as much as twice a week during Drift’s early days. Whoever’s on duty can also rely on the professional support agents, who assign incoming help requests and are available to assist with tricky cases.
“They are doing their best to give you interesting [requests] that you’d be helpful on, and they also understand that you’re not a professional support rep, so it’s probably best if you’re handling one chat at a time,” O’Brien said, adding that support agents typically juggle a much higher workload even while helping others on support duty.
Continued O’Brien: “They’re expert multitaskers. They’re following four conversations, plus answering my questions, plus triaging new chats that come in. It’s pretty brilliant.”
Developers Are Better at Customer Support Than You Might Think
Customer support at Drift is handled mostly over online text messages on Drift’s own platform, although sometimes communication gets escalated to video chat to facilitate screen sharing. O’Brien said using chat is easier because it is more forgiving, especially when employees need time to look up answers.
“That eases people’s anxiety, because you can look up help docs or ask someone else for help if you have no clue what someone is talking about,” O’Brien said. “We have an internal notes feature so you can talk to the other people who are doing support and say, ‘Can you help me with this?’ and the customer will only see a little bit of lag time in your response.”
“They’re excellent at knowing the problem that the customer is experiencing.”
Developers also get training prior to their first shift and a general script to follow, which teaches customer support best practices such as asking clarifying questions, restating the problem back to the customer and setting expectations for solutions. Each support duty lasts one hour — enough time to handle two or three customers.
Being a developer can be an advantage on support duty, because developers work on the product customers are using on a daily basis.
“They intimately know the system,” O’Brien said. “They’re excellent at knowing the problem that the customer is experiencing.... [After] that hurdle of the actual interaction, they find out that they’re actually really good at it.”
Helping People Directly Can Be Motivating
Support duty is also an opportunity to directly help customers.
“Some of the best moments I’ve experienced at Drift have been because we’ve talked to our customer and then fixed something in a ‘surprise and delight’ way,” O’Brien said. “If you’re a developer on a bigger project that’s taking months or quarters to ship, it can be fun to just fix a little thing and see the effect right away.”
That being said, the company is careful to avoid putting pressure on developers to take on additional work as a result of their support duty, such as promising to personally work on changes. Employees on duty follow a triage process, where issues from customers are filed as tickets in a resolution process that identifies and fixes bugs. Being a developer can help with that process as well.
“Where you’re not sure if it’s a bug or the way it was built, those are the ones that take a little bit longer to diagnose,” O’Brien said. “One of the unfair advantages that developers have is they know the other developers, so they can message them on Slack and ask, ‘Did you intend it to be built this way?’”
Supporting Customers Can Help Devs See the Bigger Picture
Doing support duty can also open developers’ eyes to the business side of the company. Developers spend most of their time thinking about a product from a functional point of view, rather than thinking about the work that goes into selling the product. Working support duty forces developers to manage a different type of interaction with customers, and it requires engaging with sales and marketing concepts.
This broader perspective is also helpful for the company, O’Brien said, because it improves understanding and communication between departments.
“One of the pitfalls as a team scales, is that, by nature, it becomes more siloed,” he said. “[If] you’re a developer and you work on the mobile app, that’s the only lens that you see the application through. Forcing yourself to diagnose a problem on behalf of the user makes you use the application the way the user does.... You can develop these weird perspectives if you don’t break out of that shell.”
Supporting Customers Creates Opportunities to Build Relationships
Having a variety of employees do support can also help build the company brand, because customers don’t expect it, and they feel their concerns are taken seriously. Employees on support duty don’t have to identify their regular role at the company to customers, but many choose to do so, and it can surprise customers to hear that, for instance, a software developer is handling their support request.
“When you say, ‘Hey, I’m the head of product design, and I’m here to help you today,’ that’s a moment for the customer, where they’re like — wow, this is different,” O’Brien said. “I hope that it feels like we’re paying more attention.”
Employees are able to see the customer’s job title when an issue is reported, which can open up interesting conversations. O’Brien is sometimes matched with customers also working in the product design space, and they end up chatting about design.
“I’m the head of product design, and I’m here to help you today.”
“Developers do that as well, if they recognize that the other person is a software developer,” he said, explaining that in those situations, developers can talk about the issue in a technical way. “It can be a really delightful moment for the customer.”
Especially in the company’s early days, employees sometimes developed one-on-one relationships with customers, and people would trade stories about their “favorite” customers, like the one in Seattle who ran his own ballooning company.
“He wanted to use Drift in really interesting ways, which pushed us to build really cool features,” O’Brien said.
Familiar customers sometimes even served as sounding boards for ideas employees had about new features, and whether certain ideas fit customers’ use cases. Talking to customers could often be a source of inspiration for innovation.
“I wouldn’t say that we have to do support duty,” O’Brien said. “I’d say we get to do it.”
