By Nimrod Vered, CTO, Uplevel
With their heads in the code, it’s easy for software developers to lose sight of the customer — what they need, how they use the tool, what they like, what they don’t like. As engineering leaders, it’s our job to help developers bridge this empathy gap. Doing so can improve team effectiveness, deliver greater customer value, and increase employee engagement.
You may not notice a drop in empathy at first, especially at a smaller company. With a single line of communication between your customers and devs, early stage teams are more likely to seek and act on feedback. There may be someone in the middle to receive the message and pass it along to the devs, but there is generally less static to cut through.
As your organization scales, however, a lack of customer empathy will become more apparent. For example, you may see that your teams are allocating more time to KTLO activity or bugs. This could indicate quality issues that may — especially when reported by customers — be a result of devs not putting themselves in the customer’s shoes.
In some ways, this disconnect happens by design as organizations grow more complex and new communication flows are established. Like a game of telephone, messages can become diluted by the time they reach your devs — if they reach them at all. Your teams may eventually read what’s been synthesized in a requirement doc, but they could be missing important context behind the original feedback.
Or worse, your devs could forget that customers are real people trying to be successful at their own jobs. Even little things such as error messages can make a difference in the effectiveness and even wellbeing of the customer. Developers are often too far removed from that pain and emotion to do anything about it, but it doesn’t have to be that way. In this article, I’ll discuss:
The very nature of development work can pull your teams away from customer interactions. Without that direct connection, your devs can forget who they’re actually building for. They may need a reminder of the power they have to delight or annoy the customer (i.e., help the customer increase their effectiveness or hurt the customer by negatively impacting their effectiveness).
When there’s access to customer feedback around the work they’re doing, your devs will better understand the impact of their efforts. If that feedback is positive, they’ll put in the work to feel that sense of accomplishment again. If it’s negative, they’ll be in a better position to address the customer’s pain. In this way, the effects of customer empathy flow both ways, benefitting your customers and devs.
While your devs won’t always like what they hear, this feedback provides an opportunity to ask questions and make improvements. I want my teams to be proud of the software they’ve built and the value they deliver. That starts with being empathetic to the customer journey.
Closing the gap between your devs and customers is how you generate empathy. But how do you actually achieve that? Your devs aren’t part of the customer success or support teams, and you don’t want to take them away from their jobs for too long by sending them on customer visits.
In my experience, the best way for developers to practice customer empathy is to spend at least one week a year shadowing a support agent, listening to incoming customer calls, emails, or messages. It’s something I’ve done throughout my career, and I walk away with “Aha” moments every time. Why once a year? Muscle memory dwindles over time, so it helps to get a yearly reminder that there is a paying customer on the other side.
Hearing feedback firsthand goes a long way in helping your devs put themselves in the customer’s shoes. In most cases, customers reach out for support because they’re frustrated about something. So when a dev sits down with a customer and listens to them complain about software they built, it can leave a lasting impression.
I remember the first time I shadowed a support agent and heard a customer using profanity, slurring the product. That made me feel terrible, because I take pride in what I build and ship. At the same time, they must have really been extremely frustrated to use profanity. Going through that experience opened my eyes to the impact my work can have on the customer. People rely on our software to do their jobs. If we build something that doesn’t help them, we aren’t achieving our objective.
If shadowing isn’t an option, there are other ways to make sure customer feedback makes its way to your devs. For one, you can have your customer success/support teams present customer stories to your devs, rather than just to your product team. Try holding customer empathy sessions to walk through the product as a customer, seeing it through their eyes. Even better, expose your devs to recordings of customer calls if they can’t listen live. That way they’ll still hear the feedback firsthand instead of seeing notes on the roadmap or in a support ticket.
Just exposing your devs to customer problems isn’t enough. You should also empower them to use what they learn to address low-hanging fruit.
I’ve seen so many instances where devs don’t realize a customer is having trouble with a feature or bug. As a result, a problem that would take only 10 minutes to resolve instead becomes a major customer pain point. Take my call with the cursing customer, for example. I had no idea they were having such a negative experience. But once I understood their pain point, I realized it was an easy fix for the group. I prioritized the item, and we took care of it quickly.
I’ve seen the pride in my devs’ eyes when they take that time to fix a problem and make a customer happy. That feeling carries into their daily jobs, influencing future assumptions about how customers use and perceive the product. So the next time a customer complains that an error message isn’t self-explanatory or actionable, my devs can ask themselves how they would feel in that situation.
When you bridge the empathy gap and bring that pain to light, your devs are more likely to walk away thinking about the customer — and how to improve their experience. And they’ll feel a sense of pride in their work, which will increase their engagement.
This post is by Nimrod Vered, Uplevel CTO. See how Uplevel is using data to help engineering organizations align priorities, avoid burnout, and work more effectively. Or schedule a demo today.