Apparently that's frowned upon since the goal is to beat around the bush with "hmm.. that's not supposed to happen, so sorry" as a means to absolve us of as much accountability to the customer as possible.
I have a philosophy that simply doesn't align with how most businesses want to run customer support, so while I wouldn't mind doing it, I am probably only making it worse in their mind.
Not every day or every issue, or any other regimented basis. But I do try to stay close to raw customer feedback. It can be useful to see what details gets lost between the customer and layers of support before it gets to an engineer.
This is also good for new hires as they get to a grounding on what matters (customer experience).
highly recommended as a training scheme! especially in cases where engineers have a lot of influence on product design.
(although, in a high volume ticket oriented environment, or a highly structured testing environment, the benefits fall off dramatically. the big value was setting things up from scratch in different contexts and seeing where people struggled)
It is also not measured in months.
Rotations into Support (for a week IIRC) once a year used to happen as it was deemed important, until the day it was no longer important and was stopped.
Engineers joining usability tests is a great thing. Engineers talking with PMs and joining early discovery is a great thing.
But I would quit immediately if I were put on a customer support rotation. This seems idiotic.
Why?
I sort of thought similarly about a decade ago, until I actually was on the end of a giant on-call tree almost permanently for 3 years. I wasn't the first person they'd call and not even the second, third or fourth. But eventually someone would call me and ask me to jump in & dig through it - I loved it, because eventually that's just a neat puzzle with an angry customer attached (if I could walk in someone else's shoes for a week, it would be rachelbythebay's).
I also did primary on-call out of solidarity with the team. And 1 week out of every 20-odd wasn't hurting me as much as I thought it would, but the customer contact gave me enough weapons to argue with the PM teams when it came to "customers want 'faster horses', stop working on cars" arguments.
I could actually see the product used and talk to the people who are struggling with it, better than the stage-managed customer advisory board they setup for each year's sales kick-off.
Of course, there's a vastly different "competency rearrangement" disease which you might be referring to, which is spread through out the article.
If engineering is good at doing things, they get things to do that have nothing to do with engineering - QE is slow, get engineering to fix QE process, product has bugs in prod at a customer, get an engineer to fix it reactively, customer conversations aren't closing fast enough, get a credible engineer to talk to their engineers, if product can't figure out what to build in what order, get an engineer into that conversation.
Eventually, engineering is doing a lot of things half-competently and the company chugs along, dragging the other people who aren't failing hard enough to get fired because the engineers stop every buck passed to them.
I'm more than happy to receive a request like "something weird happened with this user's account, can you look into the data/logs?", but not, "Hi, I can't log into my account, what should I do?". That is the customer support I got the impression of from the article
We weren’t allowed to touch the “I can’t access my account” tickets because that usually involves some kind of identification process where getting it wrong could result in huge legal liabilities. But all the other stuff… bugs, people just confused on some process, or whatever. Those were fun.
I also make this very clear to my boss. "If you want someone on customer support, you want someone else instead of me."
It's really important to know how disconnected you are from customers. On every single occasion at every organisation I have worked for I have discovered great disparity between the user's desires and problems and what is communicated through the layers.
Layering communication is dangerous!
Also quite frankly sometimes it's only engineering who can turn an angry customer back into a happy one because they are the only people who can really action change.
Basically, rotating 3rd level support along with an alert/on-call duty I'm totally fine with. First-level, I'm not.
This is a quality problem of the people doing the communicating. We need those people to do better, not drop engineers to get the real story
>Also quite frankly sometimes it's only engineering who can turn an angry customer back into a happy one because they are the only people who can really action change.
This is true, but the engineer doesn't (shouldn't?) have to be the face of that. Once you allow customers to escalate directly with engineers, that's now a route and they'll see the rest of your support process as bullshit.
This is what made me customer obsessed and to this day I will meet with the support team at any new company I work with to understand the plight of the customer
I worked at a SMB where everyone in the company had to perform some customer facing duties every month. No, we weren't terrible at it, and it helped all of us gain an appreciation of a different point of view. No customer was pissed off (in fact some were impressed when they realized they were talking to senior management), and while the company is no longer in business (for various other reasons) there was no noticeable harm caused by this.
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.
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.
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...
> 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"
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.
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.
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.
Each communication step, unless it's a critical bug that warrants putting everyone in a shared call, adds anything from two to sixteen hours worth of latency, leading to feedback taking days or weeks.
I have found to like the model of:
1. Customer contacts a project manager / support rep (depending on the organization - the former will be prevalent in the agency world, the latter in the classic SaaS/old-school software world), to inform them about a bug.
2. CSR/PM does an initial triage: can they reproduce the bug, is it an already known bug? If it is a valid and new bug, the known-to-that-point details get passed to a developer.
3. Developer contacts the customer for further information and direct troubleshooting, and involves other departments (ops, dba) as needed on their own
4. In case of higher effort bugs / feature requests, developer coordinates with PM for bureaucracy (creating tickets, test cases, ...)
5. Bug gets fixed, tested, and deployed
6. CSR/PM contacts customer and asks them for re-testing on their end.
I've done tons of direct customer support over my career. I still do sometimes, and I lead my department. (No, this is not a waste, it has a strategic use of my time to keep people happy.)
The message I'm responding to doesn't point in this direction, but so many other comments make it clear it is a status thing for them, that they consider themselves above directly serving customers.
All I can say to those people is don't leave your cushy HugeCo job for a real startup. You will have to humble yourself in far worse ways than asking, "how can I help you?"
That's completely different to doing a week of enterprise support for a large company on a product with millions of users.
One is more like helping a product find its product-market fit, validating ideas, or even realising the company needs to pivot.
The other is mindless, boring and in 99.99% of cases unproductive for the product.
In startups there's a push for founder-led sales because it's the best way to learn from your target customers.
It's the same for engineers. The quickest way to validate your assumptions, see where the rough edges are, identify an easy bug, etc. is directly from the customer.
I found that doing it myself with a support rotation was the best way to do this. That said, it's not "throw engineers into the deep end". It was managed by support team to optimize my time and their benefit. We were able to mutually teach each other a ton.
Picking up the telephone and debugging areas of expertise YOU created or are already responsible for is much easier than making a sales guy into a pseudo-engineer.
Also, paradoxically, some of the best product features I've come across literally started as a ghetto-coded-idea by a Technical Account Manager (sales engineer). Said features were later formalized and picked up officially by engineering, but the nexus of the product feature started with a non-dev.
Sorry for the ramble/rant. My point is this: Don't get so married to job titles. It can be limiting in my humble opinion.
It does no good to expose a developer to customer problems if they are unable to make the decision to fix it. At that point it's just wasted effort.
Which is sad and lazy thinking.
If you can drive a car and program a machine you can handle two common “roles” in our economy. Clearly only being capable of one role is a joke.
Me thinks this feels more like vanity and laziness; the engineer is not to slum it with the call-center rabble.
Lol. It’s not that I have a 10 hour day already. Nor is it because I have a specialized, very expensive skill set that is not properly utilized. Nor is it that I already do 3 different jobs. Nor is it that I am already on 12x5 pagerduty rotation.
No, it is because I am filled with vanity and laziness. I don’t want to slum it with customer support.
Lol. On the contrary this is just yet another MBA spreadsheet jockey trying to “get their moneys worth” out of developers. We already do much more than nearly every other job title in this industry. Just stop.
Let’s give the food producers your benefits. They’re probably far more valuable to me than you will ever be. Why empower you with such economic agency then?
No one wants to hear they're worth less than someone they perceive to be doing an "easier" job. Truth is, that's how society values people.
Maybe I'm not truly talented and you're right (nice no true scotsman though). My paycheck and the fact I can leave a job tomorrow and get a new one for even more money says someone thinks I'm extremely valuable.
Someone simply suggested that VC-backed companies (presumably, often of the startup kind), the company can achieve more economic success when engineers spend some time with customers (and let's not forget that the customer need is the SOLE reason that the engineer's job exists at all).
The hubris is in the failure to acknowledge that you do not represent the entire world of engineers, and the unwillingness to contemplate a scenario where just maybe, an engineer could be better at their job, if they took more time to understand that which created its reason to exist.
Having developers answer support tickets and follow up on leads is a terrible use of their time (especially considering how much you are paying them) and they will be terrible at it.
If there are problems with your customer feedback loop, focus on fixing it instead of taking shortcuts.