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!)
Article No Longer Available
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!
Oldest comments (1)
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!)