[jeffclark]

Seriously. If you're not dealing with another engineer/developer/tech-y, you should reconsider having your engineers interact with the public.

Actual entire response from one of our (very smart, social and senior) engineers recently to a customer who couldn't login:

"Hi (customer): I can't recognize the web browser you are using! Can you possibly try to login with one of our supported browsers and let me know if you still have a problem? -(engineer)"

Sure, it's exactly what he needs to know to start fixing the issue, but there's no chance the customer (a florist) is going to know how to respond to that. We're just wired differently.

[mjpizz]

great illustrative story. But couldn't this be more a matter of learning good customer service skills, not a matter of intrinsically being "wired differently" as an engineer vs. non-engineer?

[sp332]

The engineer thinks of the problem as a technical problem with a technical solution: wrong browser, switch browsers. Simple!

Out of curiosity, how would someone with good customer skills handle this situation?

[brendan]

In my experience, the best response is one in which you make it clear that you personally care about the customer's problem and will do your best to get it resolved quickly. This trumps everything else, so long as it's the truth. If your engineers don't actually care about your customers' problems, then having them do support will only hurt your business.

[brendan]

If it comes down to that, yes. Though I'd first try to track down their requests in the logs and see if it's something we can fix on our end.

Obviously, some companies make a conscious decision not to support all browsers, so there might be no way around it in that case.

[sp332]

So you would, eventually, get around to asking the user to use another browser? Just not as abruptly?

[jeffclark]

Well sure, that would be ideal.

But as an engineer, are you even remotely interested in learning good customer service skills... or making sure the site doesn't come crashing down in an hour?

[mjpizz]

sure, as far as "job responsibilities" go, I agree that keeping the site running trumps answering support emails. That's the primary job of an engineer or ops guy/gal. But hopefully urgent events like this aren't the hour-to-hour norm for a company.

To answer the first half of your question: as an engineer myself, I am personally very invested in good customer service skills. Admittedly, doing a startup (vs. being part of a much larger organization) probably drives my customer interest quite a bit. However, even from an engineering perspective the customer interaction has definitely helped to focus my work on solving real (often recurring) customer pain points and requests, and communicating those back to the customer in a way they understand.

anybody out there with similar experiences as an engineer doing both customer support and development?

[jeffclark]

Totally understandable, especially in a startup area.

This specific case is my day job. We're still startupy-ish, but a little more established (you've definitely heard of us). We have a support team and all that, and the engineers are working on new features and scaling more-so than bug fixes.

I (of course) am working on my own thing and handle 99% of the customer service on it - not only because I want my customers to be happy, but just like you said, I want to work on what really pains my customers.

[brendan]

Right on. I'm an engineer (and one of the founders of Wistia), and I really enjoy talking to customers and doing support. I can understand that this type of behavior might not be typical, but it's such a huge advantage to have the people building the product interacting directly with the people who are using/buying it. I love it.