Today I gave the wrong answer to a customer | Hacker News Reader

Today I gave the wrong answer to a customer

carokopp.com

37 pointsjennita15 comments

The author seems to be missing how disruptive interruptions can be to some developers.

The "on call" idea might have some merit because it allows the developer to adjust their coding schedule around the X hours they will lose every day for a given period of time with customer assistance.

The "all hands" idea sounds terrible. Asking a developer is asked to answer 5 customer emails daily, each one needing a variable length of time to respond to, threatens to poison the well and become a burden. My understanding is that a developer would either try to answer the emails at the very beginning or at the very end of the day to keep distractions at a minimum.

My biggest question is - what is the reason for the author to have this many questions after being with Buffer for over 8 months? This seems like sufficient time to learn all the ins and outs of most products. Moreover, I hope that Buffer dev new-hires are told that they'll be asked to wear many hats, including the responsibility for customer support, as part of the regular duties.

I've seen this sort of setup work very well. It's something I've done myself (while wearing a dev hat) and found it very useful. I'd happily do it again.

Yes - being interrupted at any time would be a pain - but...

1) There are normally enough natural pauses during the day where knocking off a few customer support issues is doable. It can actually be quite a nice change of pace. It uses a separate bit of your head and you come back to that problem that just stumped you fresh after the break.

2) It's can be a mistake to worry about the productivity of individuals and neglect the productivity of the company as a whole. Slowing me down individually can make the company as a whole run faster.

3) It gets you direct contact with actual customers on a regular basis. This is pure fking gold. Lost count of the number of times this has produced insights about how the ongoing development should work. That minor annoyance that three folk mention in a row that's sounds tricky but is a 2m fix.

Re (1): I am a developer. I do several different things a day. It's an ideal moment, do do 1 short thing in between 2 different long tasks. It's a nice distraction, a time to empty your head.

So, unless you're spending your whole day on one single huge feature all day, there are plenty of opportunities for short breaks.

But I agree that having interruptions at random times may be counterproductive.

I've had good experience with a rotating on-duty developer in at least two different companies I've been at.

The developer would be the only person that CS (and others) can come to with questions. He would not be expected to be very productive and would generally deal with small ad-hoc bug fixes when not acting as internal support (Which it really is). He'd also be responsible for various ad-hoc and maintenance tasks. The rest of the team would then be free to work uninterrupted on development tasks.

We'd have some sort of token (a teddy bear or whatever) at the designated developers desk, so everybody would know who to go to.

Of course it does cost a full developer "resource" at all times, so this probably only makes sense once your team reaches a certain size.

Rotating "on call" around sprint cycles, for example, has a lot of potential IMO; as engineers we need to have not only a solid understanding of our product and technology but also of our customers - how can we build the best product for them without having some empathy with them?

One of the greatest joys for me in my day to day job is problem solving for customers and colleagues. The satisfaction I get from helping someone is almost second to none; there's also the added benefit of the customer feeling valued and the company coming off as one with great service. Another part of the interactions is honesty; explaining what an issue is to a customer or colleague makes them feel cared about as well, and builds a lot of trust. That relationship can really help you get through tough times; a happy, helped customer is a loyal one. I've had one or two customers at a past employer who have said that I was the only reason they didn't drop us.

Having said that, it can be a huge time-sink and I wouldn't recommend mixing "support" with "feature" work; inbound communication is highly disruptive to concentration, impossible to estimate and if there's a lot of it it can overwhelm a developer to the point where they don't get feature work done and will, I guarantee, start feeling crap about it.

I would personally advocate a "Business As Usual" team working in a Kanban style to handle piecemeal support and technical issues, with perhaps a small, non-critical feature project bubbling in the background, balanced with feature teams working in sprints, with a healthy team rotation; it will keep your engineers fresh, interested and engaged with customers and the product.

/my 2c

Head of Support in the AdTech space here. Rotating Devs into the Support-Team is exactly what we do. The QuiRe – for QuickResponse – leaves his Feature-Team for the 2-week sprint period and gives helping hands to Support-Staff. As DevOps belongs to this team as well, the QuiRe can hack on small DevOps issues in the spare time. Brings in some nice knowledge distribution as well...

So cool to hear this. We're trying something similar with the entire staff at SEOmoz. Everyone knows the product in different ways and takes turns as part of the "Help" team. It's a new concept but great to hear how others are doing it.

This post seems sincere, but insecure. I'm a bit concerned that someone in support needs to ask so many questions...

This is where a queue of support tickets and a knowledge base would really help out I suspect.

Totally agree. I do think though that right now the Buffer App team is pretty small and slowly growing. Plus when a product is constantly changing or getting upgraded, it can be difficult to know all the answers all the time.

I do feel this post is pretty sincere and I liked the fact that she was honest with her mistake.

So basically, when somebody asks you a question, it's better to answer it truthfully and possibly do some research on the answer, rather than just make up a bad answer?

It sounds like pressure to give an answer very quickly. Just answer it later!

Agreed. I also don't think there's any problem to respond right away saying you will investigate the issue with a developer that day and get back to them. That way you satisfy the need to respond quickly so the customer knows "you're on it" while also being able to give a valuable answer sometime in the very near future.

I manage the Community team at SEOmoz, and part of the team's job is to do customer service via our social channels. We try to respond quickly whether we have the answer or not, to let them know we're working on it. It does help the community member feel like they're being taken care of quickly and that we're listening to them.

Cool, I've found the same when managing my community. There are certain bugs or features I say might not get addressed because we're rebuilding the site and prioritizing that over constant changes to the current site -- people are always appreciative with good communication. If a company makes a mistake, winning them over with customer service often creates an even stronger user/customer.

Thanks so much for the awesome replies, all! I'm looking forward to discussing a few of them more with my team. :)

Reply on news.ycombinator.com