4 ms·

I've done plenty of direct customer support as an engineer, and I think everyone won because of it. This was usually on some more difficult issues, or issues t

I've done plenty of direct customer support as an engineer, and I think everyone won because of it. This was usually on some more difficult issues, or issues that involved an actual bug. Why bother going through a support person if I can just talk to the customer myself and explain the issue better, or ask the right questions straight away? Seems to me that's not a waste of time, but a time saver for everyone. Same with feature requests; a support person can fob a person off with "thank you for your feedback" and create an internal issue with no context, or I can talk to the customer myself, get a good idea of what problems they're running in to, and discus with them how to best fix it. Sometimes these are almost trivial fixes or changes, but a support person doesn't always realize that. In general keeping an eye on the support inbox gives me a better idea of how customers are using our service and what kind of things they're running in to. The amount of time/money spent on this is minimal, if it even exists at all, especially considering this is the sort of thing you can do a bit later in the day when you're not producing the sharpest code in the first place (I usually don't anyway). Even as a mostly backend engineer I've gotten a lot of value out of it, and I think our customers and the business overall have as well. That said, forcing developers who don't want to do this is probably a bad idea: they will do a shoddy half-job, be unhappy, and no one wins.

ilyt 4y ago
That kinda depends on type of customer. If issue hitting you is actual problem with usability or how the system works, sure, direct contact with customer can solve that quickly and efficiently. Like, if your company is providing API to developer and you get contact with dev that have some errors using it, that can be very productive. But most of customer support is "they didn't read the docs/googled hard enough" type. It might be not for your field but that's what it is.
- Beltalowda 4y ago
  > But most of customer support is "they didn't read the docs/googled hard enough" type. It might be not for your field but that's what it is. Yes, and those weren't the type of support requests I would handle; although keeping an eye on the support inbox every few days to see patterns where customers are struggling with was still useful; sometimes it can just be fixed by changing the wording on a label, or adding a link to the documentation. Customer support isn't always good at communicating these issues to developers, and many PMs are more focused on the "big things" rather than little details like this, but ... they do make a product better and it costs very little effort. Similarly, if a customer started getting difficult/ranty I would just tell support to deal with it. I've had people go off on entire tangents about the Bush presidency and Iraq war (in ~2016-2017...) because of a minor inconvenience. I'm not going to deal with that kind of silliness. There are some very odd people in the world...
  - ilyt 4y ago
    >> But most of customer support is "they didn't read the docs/googled hard enough" type. It might be not for your field but that's what it is. > Yes, and those weren't the type of support requests I would handle I know that already, from the fact you didn't said you hated dealing with customer support. I'm just saying your example is tiny fraction of what most would consider "customer support"
- tstrimple 4y ago
  > But most of customer support is "they didn't read the docs/googled hard enough" type. I'm a strong believer that those are UX issues which should be addressed in the product as well. I'm aware of the Rick Cook quote and while I don't disagree, if your product requires educating the general population in how to use your tool it's likely not going to work too well and you're going to have more support issues.
QuadmasterXLII 4y ago
The "Engineers doing direct customer support" has to be optimized for benefiting the engineer, not the customer. Ideally the engineer, faced with a problem, gets the option to pick customers to help 1 on 1 in order to gain insight into the best solution to the problem.
- Beltalowda 4y ago
  Shouldn't everyone in the business be optimized for benefiting the customer? That's certainly my general mentality anyway.
trynewideas 4y ago
> a support person can fob a person off with "thank you for your feedback" and create an internal issue with no context, or I can talk to the customer myself, get a good idea of what problems they're running in to, and discus with them how to best fix it. As someone who's worked on both support and engineering teams, this bums me out. If your support engineers aren't making useful tickets on their own, maybe the exchange needs to go both ways.
- Beltalowda 4y ago
  Lack of quality on the tickets support created for us was indeed a bit of an issue. I don't know why; I got along pretty well with a lot of the support people and discussed it a few times over beers, this kind of friendly non-accusatory criticism was well received, but concretely things didn't really improve. It was also brought up in more formal settings a few times, also without much results. Maybe it's just the time pressure they had from having to meet targets? I don't really know how that part worked; in the end I was just a developer and didn't really have much insight in all of that. Another problem we had is that a lot of non-developers folk saw the developers as aircraft fighter pilots: super-special hotshots that you need to approach with caution. I'm not sure where that culture originated because none of the developers were very comfterable with that, but it was like that when I joined. I tried to change that, but with very limited success. Overall, it wasn't as bad as I make it sound here. A lot of the support folk were pretty good and most customers were happy with the support they got, but there were certainly some communication issues between support and development. Because I did a bit of support I also used the admin interface support used and made a few small improvements because some things were just awkward. Stuff like small layout improvements, adding a button so you don't have to click 5 times but just once, a basic search feature: real simple stuff I quickly did in-between other things (and usually looked ugly, but it worked). I was the hero of the support department because it was a major annoyance for them too, but ... they never told anyone, and never asked if that button could be added.
flashgordon 4y ago
Also this works for products with "few" teams? Typically in big co products I have seen (working in cloud Saas offerings) development is broken into a dozen teams (observability, ux, service A, service B etc). It gets worse with higher revenue products (org building is norm). Customer support rotations though infrequent need you to understand a lot of things fully across the stack. While the odd eng enjoys the breadth most folks I've seen get burnt out as they are wading through a gazillion playbooks only to have tickets cross over to the "next" support rotations:(

ilyt 4y ago

That kinda depends on type of customer. If issue hitting you is actual problem with usability or how the system works, sure, direct contact with customer can solve that quickly and efficiently. Like, if your company is providing API to developer and you get contact with dev that have some errors using it, that can be very productive. But most of customer support is "they didn't read the docs/googled hard enough" type. It might be not for your field but that's what it is.

Beltalowda 4y ago
> But most of customer support is "they didn't read the docs/googled hard enough" type. It might be not for your field but that's what it is. Yes, and those weren't the type of support requests I would handle; although keeping an eye on the support inbox every few days to see patterns where customers are struggling with was still useful; sometimes it can just be fixed by changing the wording on a label, or adding a link to the documentation. Customer support isn't always good at communicating these issues to developers, and many PMs are more focused on the "big things" rather than little details like this, but ... they do make a product better and it costs very little effort. Similarly, if a customer started getting difficult/ranty I would just tell support to deal with it. I've had people go off on entire tangents about the Bush presidency and Iraq war (in ~2016-2017...) because of a minor inconvenience. I'm not going to deal with that kind of silliness. There are some very odd people in the world...
- ilyt 4y ago
  >> But most of customer support is "they didn't read the docs/googled hard enough" type. It might be not for your field but that's what it is. > Yes, and those weren't the type of support requests I would handle I know that already, from the fact you didn't said you hated dealing with customer support. I'm just saying your example is tiny fraction of what most would consider "customer support"
tstrimple 4y ago
> But most of customer support is "they didn't read the docs/googled hard enough" type. I'm a strong believer that those are UX issues which should be addressed in the product as well. I'm aware of the Rick Cook quote and while I don't disagree, if your product requires educating the general population in how to use your tool it's likely not going to work too well and you're going to have more support issues.

QuadmasterXLII 4y ago

The "Engineers doing direct customer support" has to be optimized for benefiting the engineer, not the customer. Ideally the engineer, faced with a problem, gets the option to pick customers to help 1 on 1 in order to gain insight into the best solution to the problem.

Beltalowda 4y ago
Shouldn't everyone in the business be optimized for benefiting the customer? That's certainly my general mentality anyway.

trynewideas 4y ago

> a support person can fob a person off with "thank you for your feedback" and create an internal issue with no context, or I can talk to the customer myself, get a good idea of what problems they're running in to, and discus with them how to best fix it. As someone who's worked on both support and engineering teams, this bums me out. If your support engineers aren't making useful tickets on their own, maybe the exchange needs to go both ways.

Beltalowda 4y ago
Lack of quality on the tickets support created for us was indeed a bit of an issue. I don't know why; I got along pretty well with a lot of the support people and discussed it a few times over beers, this kind of friendly non-accusatory criticism was well received, but concretely things didn't really improve. It was also brought up in more formal settings a few times, also without much results. Maybe it's just the time pressure they had from having to meet targets? I don't really know how that part worked; in the end I was just a developer and didn't really have much insight in all of that. Another problem we had is that a lot of non-developers folk saw the developers as aircraft fighter pilots: super-special hotshots that you need to approach with caution. I'm not sure where that culture originated because none of the developers were very comfterable with that, but it was like that when I joined. I tried to change that, but with very limited success. Overall, it wasn't as bad as I make it sound here. A lot of the support folk were pretty good and most customers were happy with the support they got, but there were certainly some communication issues between support and development. Because I did a bit of support I also used the admin interface support used and made a few small improvements because some things were just awkward. Stuff like small layout improvements, adding a button so you don't have to click 5 times but just once, a basic search feature: real simple stuff I quickly did in-between other things (and usually looked ugly, but it worked). I was the hero of the support department because it was a major annoyance for them too, but ... they never told anyone, and never asked if that button could be added.

flashgordon 4y ago

Also this works for products with "few" teams? Typically in big co products I have seen (working in cloud Saas offerings) development is broken into a dozen teams (observability, ux, service A, service B etc). It gets worse with higher revenue products (org building is norm). Customer support rotations though infrequent need you to understand a lot of things fully across the stack. While the odd eng enjoys the breadth most folks I've seen get burnt out as they are wading through a gazillion playbooks only to have tickets cross over to the "next" support rotations:(