Everyone should read support emails • Hacker News Board

Re: Everyone should read support emails

#171

Post by arendtio » Mon, Mar 04, 2019, 8:08 PM UTC

superice wrote: post #43

This is why we regularly take developers to customers. It is eye-opening to see on-site that your mobile app with tiny but well-designed buttons doesn't work for registering container positions when the user is in a shaky 90 metric tons weighing machine, handling 30 metric ton containers. We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incre…

Once I got two developers to use their software on the live system. As a result, they fixed a few bugs which didn't appear on the dev systems as those were being run with much smaller data sets.

When normal users had to wait 20 seconds for a page, they didn't like it, but it was completely possible that the system just was that slow. But when the developers had to wait 20 seconds they used the time to look up what took so long and found minor bugs which caused the slowdown and fixed them right away.

As a result, the developers asked to be given more opportunities to work with the live system.

Re: Everyone should read support emails

#172

Post by stevekemp » Mon, Mar 04, 2019, 8:13 PM UTC

bonestamp2 wrote: post #170

We have a policy that if a bug generates more than 20 support calls in a day, the developer who introduced the bug has to spend the next day in the call center answering support calls. It's not designed as a punishment. It's designed as an eye opener to the effect it has when we don't write proper tests or don't take proper care in making changes.

Does it "work"?, because it really does sound like punishment.

I'm an advocate for developers reading/handling support things, but at the same time the skills that make a good developer are not necessarily the same as those that make a good support person. Having some rota/schedule makes sense, but it seems like a full day of doing support isn't going to make a developer happy, primarily because they want to be a developer - not a support-person.

Re: Everyone should read support emails

#173

Post by smush » Mon, Mar 04, 2019, 8:13 PM UTC

AdmiralAsshat wrote: post #115

jacquesm wrote: post #113

Take it one further: everyone should do support, not just read the emails. 1 day per month or so should do the job, it puts everybody in a good position to appreciate that if they don't do their work properly the support people end up taking the heat. So do not just read the emails, answer them, make it work for the end-user and spot the dysfunctional bits in your organization first hand.

> Take it one further: everyone should do support, not just read the emails. That's a really fast way to burn out your entire team. Devs don't necessarily have good communication or people skills. They haven't been trained to respond politely when someone sends them a screaming, all-caps e-mail that their product is garbage. That's my job as the Support Engineer.

The gp comment mentioned once a month doing support to provide empathy for Support Engineers. If doing an activity once a month is so bad as to cause burn-out, perhaps us Support Engineers are the real suckers?

I would argue a once a month support engineer stint / shadowing would have more benefits than drawbacks.

Re: Everyone should read support emails

#174

Post by mjfisher » Mon, Mar 04, 2019, 8:24 PM UTC

gist wrote: post #119

Nimitz14 wrote: post #107

Earlier quoted context omitted.

It's called being polite.

In a certain context it can also be considered patronizing. Let's imagine someone is doing heavy labor and digging ditches. More appropriate to just say 'let me do that for you'. Rather than 'mind if I do that for you'. Bill must know it's not a great job to take support calls constantly and deal with the aggravation. No doubt that there are people (like with any job) that like the job and are fine with it. But those…

Or it's showing genuine respect for your employee's job, autonomy and skillset, and implicitly acknowledging that you probably aren't going to do as good a job as they would.

"Mind if I take this call?" could easily be met with "would you mind taking the one afterwards? I know who's dialling in and we're just wrapping up a long-running issue"

Re: Everyone should read support emails

#175

Post by tracker1 » Mon, Mar 04, 2019, 8:37 PM UTC

superice wrote: post #43

This is why we regularly take developers to customers. It is eye-opening to see on-site that your mobile app with tiny but well-designed buttons doesn't work for registering container positions when the user is in a shaky 90 metric tons weighing machine, handling 30 metric ton containers. We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incre…

Agreed, as a developer, I'm often asking to see the production environment for the users I'm building for. Even if it's a new application it's usually replacing something existing and understanding that is huge.

Re: Everyone should read support emails

#176

Post by Swenrekcah » Mon, Mar 04, 2019, 8:47 PM UTC

a1369209993 wrote: post #162

SpicyLemonZest wrote: post #141

Earlier quoted context omitted.

An organization with 5 customers can babysit each one to make sure they’re happy in 10-15% of their time. An organization with 1000 customers couldn’t do that even with 100% of their time. The only way to maintain a fixed allocation of customer support funding is to make it less high-touch as you grow.

If you have 200 times as much revenue, why don't you have 200 times as many employee-hours?

I think most companies want economics of scale, but even if they don’t:

Finding 10 good engineers that care about your customers is difficult but doable. Finding 2000 is much much more difficult.

Trusting 10 engineers to communicate with customers without promising things they shouldn’t, mentioning upcoming features that hurt current sales, have generally good communication skills, is again difficult but doable. Asking that of 2000 people....

Re: Everyone should read support emails

#177

Post by behringer » Mon, Mar 04, 2019, 8:48 PM UTC

hw wrote: post #155

At Re:amaze, we don't hire for customer support personnel. Our culture is that everyone that we currently have on staff, be it engineers, co-founders, marketing - all work on customer support. Granted, we're a small team right now that makes it quite possible to do so, but it really keeps things super lean. We're also a chat and helpdesk platform, so it helps to have everyone use and understand the product. There's a…

That doesn't work at scale. Imagine your marketing team fielding password reset failures all day.

For a small company though, sounds like a fine way of doing things as long as people don't get bitter about the ones who actively avoid doing the support.

Re: Everyone should read support emails

#178

Post by ljm » Mon, Mar 04, 2019, 8:56 PM UTC

One of my proudest moments in my career was when I took this to the next level and set myself up as the go-between between support and dev. We were building internal productivity tools so we could help the support folks clear things up more quickly, and give them the administrative resources they needed to do so. It was all about empathy with the user: the end user, and the support user on the admin side.

It was not a glamorous job at all but it had a meaningful impact, one that many people gloss over, and I feel the same when reading this. The best thing you can do is care about your users and the people who deal with your users.

Re: Everyone should read support emails

#179

Post by the8472 » Mon, Mar 04, 2019, 9:05 PM UTC

> Unless you are a soulless robot, the above statement will probably trigger more emotions and requirements for actions than:

Is that not an appeal to emotion and thus incentivizes customers to embellish their issues with emotional stories to get expedited treatment?

Re: Everyone should read support emails

#180

Post by pinko » Mon, Mar 04, 2019, 9:09 PM UTC

t3rabytes wrote: post #106

At Basecamp, everyone in the company does a workday in support every month or two. It's a fascinating experience to take part in: https://github.com/basecamp/handbook/blob/master/our-rituals...

I worked on a software project for 10 years where we did this, with 5-25 developers in the rotation over time (we grew). It was unpopular with many of them, but I loved it, and found it incredibly valuable. Even the people who thought it was useful learned valuable context they didn't realize they learned (e.g., how helpful our own documentation was when they needed it).