Hacker News Reader

Comment by paxys | Hacker News Reader

Every engineering-minded founder/CEO will come up with this idea once in their career, get badly burned, and quickly realize why roles like customer success 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. In the worst case they will piss off customers and actually harm your business.

Imagine if the situation was flipped, and your CEO went "sales reps need to understand engineering complexity, so from now on they will each have to fix 10 bugs a month."

If there are problems with bug & feature prioritization, customer satisfaction or the product feedback loop, focus on fixing them the right way (and involving the right roles) instead of taking shortcuts.

View on HN

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.

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.

> 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...

>> 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"

> 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.

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.

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

> 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.

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.

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:(

I came in ready to disagree with you... until I read the article.

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.

> I would quit immediately if I were put on a customer support rotation

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.

Ok but I see that as something totally different. Of course I'm ok with being "on-call" (and do that for 1 week out of around every 8 right now), as a 3rd+ level support. But the impression I got from the article was something totally different.

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

My old job had 5 day-a-year first line support. It was fun, sometimes. There was this one time the customer was explaining an issue over email and I asked for a screen shot. I kid you not, they printed their screen, scanned it, and then emailed that to me.

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.

There's a difference between being a tertiary technical problem solver and a rotational generic customer support person. I wouldn't quit immediately, but I'd start looking seriously for other companies. Why? Because I've done it. It's not something I'm suited for, and it's a dumb thing to expect me to be good at. I can respond to people if it's a fixed set and small set of them, on my team, about technical things. That's all he communication I can be good at, while doing engineering work. Otherwise it burns me out and makes me depressed.

I also make this very clear to my boss. "If you want someone on customer support, you want someone else instead of me."

As an engineer I regularly get pulled into customer calls.

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.

I think we're in agreement, see my other comment in reply to gopalv.

Basically, rotating 3rd level support along with an alert/on-call duty I'm totally fine with. First-level, I'm not.

I agree i learn something everytime i get involved with a support case, its nice to see your system from the other side aswell now and then, but i would absolutely hate to be in full customer support role.

>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.

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, they'll see the rest of your support process as bullshit.

The key element is training. It is indeed idiotic to put you on customer support rotation without training you first on how to deal with customers.

I have not read the article but I disagree with your last statement. When I contracted for the federal reserve, every new engineer was required to moonlight for 6 months on support rotations. Doesn't matter if you were hired as an AD architect or Weblogic admin, you were only on call to assess system failures for that time. Why? Because then you have intimate knowledge of what users were experiencing and that colored your experience to think of how users interact with your system. Lots of engineers rage quit by the second month, but everyone who stayed provided great design and strategy input to their areas.

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

"One test is worth a thousand opinions"

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.

I think theres a middle ground. There is clearly a lot of benefit for having the people building the app experiencing the pain of users using the app. I also think that exposure is a great learning opportunity for engineers. But for certain types of businesses/apps its not scalable to have engineers handle every support call.

The middle ground that I use, as an engineer, is to review customer communication on support tickets that get escalated to my team.

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.

The problem is, as soon as you have multiple people involved in a communication chain, details get lost, and feedback loops become really extensive because of all the latency involved - and CSRs hate to be paper pushers. The worst case is in large organizations when bug reports to a vendor have to go through the company's purchasing department... because that's three transitions where information is delayed, misrepresented and lost: user => purchasing dept, purchasing dept => vendor CSR, vendor CSR => vendor developer. In the worst case, add another step for vendor developer => outsourcing company rep and outsourcing company rep => outsourcing company developer.

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 find it kinda hilarious how many engineers here at a startup-focused message board are so quick to shout "not it!".

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?"

To that, I would say I've done support on a startup and that's totally fine. The customers were familiar and came with real problems or questions, and often helped drive the direction of the product.

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.

Yes, I came to reflect this sentiment.

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.

IIRC wordpress does this for new hires. Everyone spends their first few months in Customer support, which is a nice middle path to the extreme you are suggesting.

This is also good for new hires as they get to a grounding on what matters (customer experience).

my first job ever did this. qa and customer support were combined which made it the best place to learn all the ins and outs of a very complicated product. after 3-6 months i had excellent knowledge of how the product actually functioned on the ground and how the customers approached it.

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's Automattic, not wordpress.

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.

Johnson Controls (they make automotive interiors among other things), has every employee work on the production line for their first two weeks. Even the CEO.

Wontfix: User error.

"Our product isn't right for your needs. What you need is (competitor's product). Here, I'll give their engineer a ring and let them know exactly what you need and why and get you the best price."

I've done many support calls, but I was always the last choice because I was extremely candid with the customer. When something was a bad bug, I'd say "Wow, that's bad. We'll try to fix it as soon as we can"

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.

It only works if developers have the autonomy to make decisions on what to work on.

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.

> Imagine if the situation was flipped, and your CEO went "sales reps need to understand engineering complexity, so from now on they will each have to fix 10 bugs a month."

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.

I think what you mean to say is not everyone can handle more than learning one functional set of skills.

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.

> 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. Every task that isn’t immediately obvious it goes to someone else ends up on a devs desk. Just stop. Or pay me an extra 80k to handle CSR. Your choice.

Poor developers keeping society afloat with no help whatsoever.

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?

If you want the actual answer society pays people commensurate to their individual value. NBA stars make millions because of the level of entertainment they provide, and the value they bring to sponsors. I make a lot of money because not everyone can do my job and I provide an outsized value to tech companies. Despite many attempts to drive developer wages into the ground with code camps and other non-sense apparently it's a difficult enough job not everyone can do it. For comparison, garbage men make a LOT of money (at least where I am) because their job isn't easy and no one wants to do it.

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.

imho these comments demonstrate an insane level of hubris that is difficult to find in any truly talented engineer

Nothing I said was hubris. I literally work a 12x5 on call, sometimes 24xN when things get bad. I don't ever really get the chance to "clock out". I've spent a long time developing a very special set of skills not everyone has. I am paid well for it. I am not going to waste my time doing CSR work. I won't be good at it, it makes my schedule even more complicated, it provides no value to me nor what I am paid to do, etc. The hubris is that PHBs and spreadsheet jockeys think they understand my job better than I do. It's a tale as old as time: clearly the guy who sits in front of a computer all day drinking coffee must have an easy job and can take on more unrelated work.

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.

"The hubris is that PHBs and spreadsheet jockeys think they understand my job better than I do": where are you imagining these things from? Who ever said they understand YOUR job better than you? I think it's safe to say, the article was probably not written with you personally in mind. And I think it's also safe to say, you personally are not the same as every engineer out there.

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.

Reply on news.ycombinator.com