DEV Community

Cover image for Developers: delight your users and support team in just one day per year!
Desi
Desi

Posted on

10

Developers: delight your users and support team in just one day per year!

Non-developers, have you ever felt misunderstood by your developer teammates? (Headline lifted from this excellent post by @kttravers on working with developers as a non-dev!)

When you're not on the developer team or in the engineering department at a company, there are a lot of ways to feel non-existent in tech - and once of those ways is feeling that your dev staff is out of touch with your users and fight back on some suggestions you make as someone who interacts with these people every day.

While there are always plenty of reasons why a user's want may not be feasible or advisable, there are also cases where building a feature or release a little differently could have a big impact on usability or user happiness. In an effort to better understand your users, rather than just the personas that your team might present, spend one day a quarter working with your support team.

In a typical work year of 261 days (not counting vacation or holidays), spending four days in support is less than 2% of your work days interacting directly with customers. Whether it's answering customer tickets or shadowing a support person while they pull a shift in live chat, this exercise can be hugely enlightening.

Our team does this by rotating schedules, so each month, one dev spends a day (or two half-days) answering support inquiries. The next month, someone else does it, so that there's always one person each month from the development team interacting directly with members. That way, no one is pulled away from their important engineering work for too long, and they'll see changes or trends over time.

At my company, every time we do this, there are developers that see things that are bugs and are an easy fix that support has just thought was the way a feature was intended to be built, and they fix it up quickly. Seeing a trend of confusion on a behavior can help shed light on why we might suggest that it be built a different way, or why we're often adding copy improvements. Interacting with user requests first-hand is also a powerful way to see what users want now - which might often be something different than what you had previously thought.

Most of all, when we've done this exercise, something our support team says is that they feel like these sessions not only improve their troubleshooting, confidence, and knowledge of the product, but also makes them feel like it's much easier to talk to developers. Customer support is so often the way that "non-tech" people break into the industry, and I think it's so important for them to feel comfortable interacting and show them that developers aren't intimidating people they should be scared of talking to.

For more on this, James Glazebrook just posted a great article and talk on Signal v. Noise!

Image of AssemblyAI tool

Challenge Submission: SpeechCraft - AI-Powered Speech Analysis for Better Communication

SpeechCraft is an advanced real-time speech analytics platform that transforms spoken words into actionable insights. Using cutting-edge AI technology from AssemblyAI, it provides instant transcription while analyzing multiple dimensions of speech performance.

Read full post

Top comments (1)

Collapse
 
phlash profile image
Phil Ashby

Very good advice :) It applies to everyone, including the architect (me), who spent a half-day this week pouring through a customer's packet trace to ensure we really were doing all the right things and then carefully wording the response email so they understood it was really their issue..

It's even better if you can spend a little time beyond the helpdesk with bid teams or sales engineering (it really is a thing!)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Discover a treasure trove of wisdom within this insightful piece, highly respected in the nurturing DEV Community enviroment. Developers, whether novice or expert, are encouraged to participate and add to our shared knowledge basin.

A simple "thank you" can illuminate someone's day. Express your appreciation in the comments section!

On DEV, sharing ideas smoothens our journey and strengthens our community ties. Learn something useful? Offering a quick thanks to the author is deeply appreciated.

Okay