27 ms·

Engineers should do customer support and success

108 points by 0xferruccio 4y ago

rrgok 4y ago
Why it is isn't the other way around? Customer support should start learning SWE and UX/UI. UX/UI people should learn SWE and customer support. Why this expectation only for SWE?
feintruled 4y ago
Great idea until an engineer tells a customer they aren't prioritizing that bug because it's too hard to fix and they aren't a major customer.
- wildrhythms 4y ago
  The salespeople and managers already do that today.
pier25 4y ago
That's the wrong way to approach the problem. The problem is not about engineers doing support but about the whole company being aware of the real customer needs and experience with the product.
- deleted 4y ago
  [deleted]
- throwawaysleep 4y ago
  It’s irrelevant for engineers to know. We don’t make product decisions.
erellsworth 4y ago
Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?
hellisothers 4y ago
I worked at a company that mandated this, I’m sure management thought it sounded great but it felt lazy on the part of Product/Management. Is deploying an an engineer to field support tickets really the best use of their time? How about Product and Management field tickets and distill from that what is most impactful for engineering to work on.
- RandallBrown 4y ago
  I worked at a (mostly retail) company that had us not only answer the emails about our app but had us answering emails for all customers, including processing refunds and returns. At first it felt like a pretty huge waste of time, but it was a great way to get to know our customers better. Eventually our app team started just handling the app emails because the knowledge was a bit too specialized for the non app team members. Our team was small so we handled most of the product/management decisions on our own. It was a little annoying sometimes, but it was generally pretty awesome.
jackblemming 4y ago
Yep they should also do frontend, backend, dev ops, security, and on-call. Hey why dont we throw in project management and product management while we're at it. And it's not like those UI/UX people do much either, so let's just make the devs do that too. Finally to wrap it all up we'll have like 5 mandatory meetings a week to check in on them.
- ls15 4y ago
  While they are at it, they could also get new coffee beans for the machine, clean the toilets and do some sales so we can get rid of the dedicated roles for that.
  - autotune 4y ago
    One of the downsides of work from home being the new norm is that has already become part of the job.
    - Beached 4y ago
      coffee is much better now though :)
  - _jal 4y ago
    If you empty the coffee machine, hell yes you better refill it. Or do you have a valet where you work?
    - ls15 4y ago
      I wouldn't trust an engineer with my coffee.
- uri4 4y ago
  Devs should also do HR, project management, CEO... I do all of that stuff. But at my own company for myself...
- pjmlp 4y ago
paxys 4y ago
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.
- jahewson 4y ago
  Wontfix: User error.
  - justinjlynn 4y ago
    "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."
    - lucasyvas 4y ago
      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.
- Areading314 4y ago
  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.
efficax 4y ago
i completely agree. the best product work i've done was at a company that had engineers spend 1 hour a week answering customer support tickets. you get to know the customer and how they use the product intimately, and you get to know aspects of the product itself that you normally might not touch, just by trying to solve a customer problem. plus, there is no better feeling than getting a customer complaint that you realize right away is a 10 minute bugfix, making the change, deploying the code and emailing them back that the problem should be resolved. really satisfying and morale boosting.
markmark 4y ago
I worked at a small company where Engineering rotated through support. There was some value in it, but also it sucked doing it and there were other companies out there with interesting work, good pay and _not_ asking you to do support. It was absolutely part of the reason I left. Admittedly the company was small and you were doing support a lot (up to one week a month depending on team). Something more like one week every six months would have given you the customer visibility benefits without all the engineers absolutely hating it.
- bee_rider 4y ago
  When I was an undergrad, we ordered parts for some project and it turned out there was a Real Live Engineer in customer service. I guess that wouldn't be as impressive in a business-to-business context, but it impressed the heck out of us.
ultrasaurus 4y ago
Sigh. I wish this worked. Maybe we'll get to a point where AI handles a lot of the rote issues but until then, a lot of support is things like routine billing questions or even spam. Even if there is a meaty usability problem, there's no reason that it should be prioritized just because an engineer caught 1 ticket about it vs something that happened 100 times to regular support To make it work, you need to have it be part of the onboarding or there's an engineering rotation of who's on-call to help with support escalations.
ano88888 4y ago
The best way to do it is dont let your enginners do support but expose them to customers pain points and complaints.
- trap_goes_hot 4y ago
  For most humans, experiential learning/knowledge hits us differently than just reading a wall of text/bullet point list. For me personally, I started incorporating a mental model of real people who struggled to use a feature that I had previously developed.
coding123 4y ago
I've noticed this dark pattern on sub stack where you get to read the first page and then gotcha... It really sucks.
semireg 4y ago
As a solo developer I don’t have much non-obvious stuff to add, but I will say handling 100% email and phone(!) support for my business-focused electron app makes me relentlessly write guides/FAQs and polish UX. I’m guessing I’ve reduced support requests by 90% while growing the business 1000% which leaves me about as busy with support but with much more revenue. My goal is to do keep doing this… for how long, I don’t know. I’m 50% terrified of losing touch with customers and 50% wishing for an amazing support helper to pop out of the woodwork and start answering tickets.
- tothrowaway 4y ago
  I'm in a similar boat. But try as I might, I have yet to find a solution for the "I forgot the email address I registered with, and I am too nervous/confused/unimaginative to try my other email addresses, nor will I click the 'Trouble logging in link?' to help myself, so I'll send you an email from an address you have no record of (using my maiden name), while providing no further information to help identify myself, demanding that you tell me my credentials" people. I get just the right amount of these emails so it's not worth hiring someone for, while still enough to drive me nuts. I wish there was a support-as-a-service company that had non-outsourced employees (not contractors) and charged per-minute (or 6 minutes) for support, with some fixed cost for training them how to use your app, and handle basic support questions.
  - club_tropical 4y ago
    You could consider getting rid of such customers in some systematic way. Not everyone is worth it; curated customer base can save a lot of headache. And pretty cool startup idea on the small-scale Support aaS thing.
  - austinjp 4y ago
    I kiiiinda agree with sibling comment about getting rid of such customers, although obviously doing it in a way that doesn't piss people off :) First, though, you need a way to distinguish toxic users from others. This is useful because it reduces the decision-making cognitive burden to nearly zero. You can also explain it to colleagues if/when you have them. Suggestion: Keep a tally or produce an estimate of what it "costs" you to service the customers who piss you off. Compare it with time lost, work you could have been doing, impact on your mood, etc. There's no simple formula but you could get a basic metric with some imaginative plugging of guesstimates into a spreadsheet. I wonder if there's a way for you to foster users supporting users? A community forum perhaps? Obviously these can become toxic too, with entitled users spreading rancour. Strong moderation might work, by you and users you elevate to admin status. Sure, forum moderation may take up your time, but it might be simpler than per-user emails (or whatever). Community fora aren't magic bullets, but good examples exist. Just a thought! :)
acjohnson55 4y ago
This certainly can work, especially in the earliest days, when you have very product-minded and entrepreneurial engineers. But once you start growing past that founding team, you probably end up with engineers who will burn out if they have to do this, or otherwise you are limiting your engineering talent pool to people who are excited (or tolerant) to work this way. It also becomes a problem when the engineering org begins to split into teams and individual engineers no longer work with the entire customer experience. I would suggest thinking of the results you want to achieve and figuring out what's the most efficient way of getting there. If it's understanding the customer pain points, can you do it by shadowing support periodically, in lieu of actually doing support?
- NAHWheatCracker 4y ago
  I agree that a lot of engineers would be put off if they had to do this. The problem I see is managers - project, product, and engineering - who think engineers shouldn't be doing this stuff. Whether the engineers are product-minded isn't considered. Sometimes a PM sees the engineer interacting with users as a sort of intrusion on their domain. Other times an EM thinks they're saving cycles by keeping engineers away from the "non-productive" work of interacting with users.
mkl95 4y ago
This is a bad idea unless you are paying really well. I would even consider taking a small pay cut to run from a place that forced me to do that stuff. Instead of fixing those problems like a donkey, you should fix your database schema and data inconsistencies. Increase observability and monitoring budgets and whatever tooling is needed, so engineers know what is breaking and where before customers find out. I want to work at places that are one step ahead of their users, not the other way around.
- bilekas 4y ago
  > I would even consider taking a small pay cut to run from a place that forced me to do that stuff. There is something wrong with taking a paycut to not do work that's not in your job description. I wouldn't settle for this.
nxpnsv 4y ago
That is as arrogant as saying: "customer support and success teams should do the engineering". Engineers really should do engineering, it does helps if they have some idea about other stuff of course.
keithnz 4y ago
no "should". Maybe if your company is having problems with support requests MAYBE it might be useful to get engineers involved, maybe they will notice some kind of problem with the right information getting to engineering or something going wrong with prioritization of what to build. But then again, getting other roles in the company involved with support MIGHT also find what the issues are, it might be just the engineers need to talk with support to find out what they think.
faangiq 4y ago
In a real tech company, engineers should do everything. There’s no need for non engineers.
- jehb 4y ago
  What does it say about the state of our industry that I can't tell if this comment is trolling or a genuine belief?
bmitc 4y ago
Suddenly a lot of "this is working as designed" will start showing up in the resolution field.
TheCapeGreek 4y ago
I agree with paxys here that this is generally not a great idea for most orgs. IMO The better approach is for engineers to be on a rotation to support customer success teams. Unless CS somehow has every tool they need to solve all customer queries, they'll still need to divert to a technical expert if they encounter issues or need system updates that they can't action (whether due to permissions or lack of admin panel functionality).
cplusplusfellow 4y ago
Just stop trying to make developers solve 100% of your problems since they already solve 99% of your problems.
gigatexal 4y ago
Totally agree. Helps these engineers have empathy for their users. I once worked with a staff level engineer on the team was on. He lead that team. He said many times: “I don’t care about users. I care about the code. The code has to be perfect.” Yikes.
faeriechangling 4y ago
DevSecOpsSupport
boomahora 4y ago
I think a clearly summarized report on key issues and takeaways each month can deliver the same result.
tlogan 4y ago
And what is role of product managers then? What should they do? The idea of product managers to be cross functional team between sales, support and engineering. Sure you can make engineers to do sales too: but you will end up with product managers. Anyway I 100% understand the point here: in small teams you don’t have so many roles. An engineer who is good engough in support and sales will become product managers (in future). Or support guy who understand code and feels the sales. I think that is a valid approach to grow.
bergenty 4y ago
It’s probably a good idea but if I were a software engineer I wouldn’t want to do all that work. Sure one person doing everything would be great because you’ll understand every part of the business but as a salaried employee no thank you. I’m also wary of doing any job that isn’t specifically in the jd because inevitable when there is a crunch you will be called on to do it again.
ericbarrett 4y ago
The job that started my tech career was in tech support. It was for a storage company in the very early 2000s. I ended up becoming a technical account manager, then went to a startup where I continued the role but also got into light sustaining engineering (digging for kernel bugs using core files uploaded by customers). It was incredibly informing. I learned so much about people, and process, and business that I never would have seen on the pure developer side. For the last 15 years I've had a fruitful career as a storage engineer, devops, and in cloud development. I owe my career, my debugging skills, and my understanding of business to those first roles in support. I'd never do it again.
- MisterSandman 4y ago
  That last line got me, haha.
biehl 4y ago
I am a fan of having some element of the team and solution architect also do the support. It is useful for aligning incentives, and it kills some of the risky and useless refactorings that a "sheltered" engineering team can be tempted to do..
ChicagoDave 4y ago
Engineers talking to customers? I’ll wait for that freight train to ram straight through a Prius. No two groups should remain further apart.
goodpoint 4y ago
LOL, no.
GiorgioG 4y ago
And DevOps, QA, and while we’re at it project management too. We’re spending far too little time writing code these days.
throwaway0asd 4y ago
In my full time job I am a senior software engineer and in my part time job I am an IT director that deals with customer support, so I already do this. Here is my perspective: * Nobody really knows what the technical people do. Something with electrons… The IT people don’t own your coffee pot or the power station. At some point this willful ignorance (maybe stupidity) becomes a self justifying excuse for the IT people to carry your water. * Developers are (far more commonly than naught) not interested in the customer experience. This becomes painfully obvious when you watch developers throw away benchmarks and performance measures. What’s most important, the majority of the time, is a developers pet framework. Developers will twist themselves into knots forming all kinds of illogical bullshit arguments to qualify a knowingly (measurably) bad tool that harms the customer experience.
ivanhoe 4y ago
This is perhaps doable in a very early stages where the team is just a few people and there's little tickets and customers, and perhaps the customers are also tech ppl/early adopters, so they'll appreciate talking to someone who knows all the details - but as soon as you grow a bit this becomes just unsustainable. First, engineers cost a lot of money. IME 90% of support tickets quickly boil down to a few same questions repeated over and over, and with a proper knowledge base in place anyone can answer them. You certainly don't want to pay engineers to do it. Second engineers hate dealing with customers because most of those problems are stupid and repetitive. You'll be both loosing money and employees. If there's an unknown issue, then escalate it to the engineers, but let someone less skillful/easier to replace do the triage first. That said, you definitely want your support to have technical/domain skills, because nothing is worse for a customer than realizing that you talk to a person who knows less about the app than yourself, and keeps sending you back the predefined template answers, just wasting your time. I left more than one SaaS because of such (lack of real) support. So put your interns/juniors there for onboarding. They'll learn a lot about the app, customers will get good support, win-win.
belter 4y ago
I know of a well known software company, producing enterprise integration software, who once got a major escalation. A large deal of several million dollars was in jeopardy. A decision was made, to send onsite to the complaining customer, the lead software engineer who originally coded their enterprise broker. His role was not disclosed, just another helpful consultant...Being sent on site to help stabilize the project. Feedback from the customer: "Please send us another person. This one did not seem to know much about the product..."
rrgok 4y ago
I didn't the whole article, but just reading the title has been enough to make me raged. I'm sick of it. I'm sick and tired of people expecting Software Engineers to do other non-related activities. Am I the only to think that the activities a SWE should do are design/devise (as in code), implement and test. That's it. What color Mary likes and whether Jack agrees with, it is not my concern. Likewise, it is not my concern listening customers and giving them support.
- deleted 4y ago
  [deleted]
jiggawatts 4y ago
Talking to the end-users has been, for me, the most enjoyable and productive part of developing software. Conversely, it frustrates me to no end that it's basically impossible to communicate my issues as an end-user to the only people that can actually fix it... the developers. A random example of the former scenario: I was once having home-made muffins for morning tea, baked by the lovely old ladies working in the support centre. I had developed a GUI support console for them. While chatting away, I noticed (and they complained) that looking up customer contact details was time consuming. Most developers stick within their "vertical stovepipes" and would never dream of pulling in data from unrelated systems managed by other teams. Getting contact data from an LDAP directory is "just a query" however and takes minutes to whip up. I added this feature by lunch time, and walked back to the support centre and demoed this. This cut wasted time for half a dozen people in half. A trivial bit of code that eliminated mindnumbing labour, allowing these people to help other people faster and better. As a converse example: I can take apart a commercial product and diagnose the key flaws in mere hours. I'll tell you every fundamental flaw you've made, and the list the trivial fixes that would make your customers jump for joy. Generally speaking, I'm not permitted to do so. Just like how most of my customers weren't permitted to speak to me, and a few lucky ones only got the chance because they happened to be within walking distance and were generous with their muffins.
ckdarby 4y ago
Developers should watch customer care calls via Gong, but not do the actual calls. Could you imagine if we said that customer support and success should do development?
- mikkergp 4y ago
  > Could you imagine if we said that customer support and success should do development? What’s wrong with this idea? in fact I have said this, though the context was technical b2b open source where familiarity with the code is part of the job of CS.”
potatohead00 4y ago
People need empathy for the customer. One possible way to do that is mix up roles but like many other commenters have pointed out, that may not always be the best use of their time. At a minimum, the devs should have regular updates, even anecdotal user stories about frustrating experiences. Perhaps if there are feedback loops customer context is getting removed from it either via unintended optimization or normal 'corporate telephone' .
- q-big 4y ago
  > People need empathy for the customer. One possible way to do that is mix up roles but like many other commenters have pointed out, that may not always be the best use of their time. Rather: if you want your developers to become deeply misanthropic and hateful of the users/customers, let your developers do user support.
raygelogic 4y ago
it's really interesting how polarizing of an issue this is with engineers. I definitely think it's a good idea, but you can really mess it up royally with bad implementation (plus there are scaling considerations). considering how polarizing it is though, it might be one of the best signals to attract the kinds of engineers who care about how their product is used. actually I think the best targetting is for all engineers to play a support role with their stakeholders, whoever they may be. devops supporting with full-stacks, data eng working with DS, (these already happen), and UX working with the masses.
ergonaught 4y ago
No. 1) Humans don’t scale. I assume that’s self-evident. 2) Humans actually aren’t interchangeable pieces. Very, very few people can perform good work in each of those domains. Even fewer can rotate roles like that. Those unicorns are rarely employees. 3) Companies can begin like that (I have been through this kind of role evolution) because there is work to be done and insufficient staff to do it, and the roles split off when growth demands and rewards specialization, but see above, goto 1. It is great (transformative even) for people in these roles to be able to take perspectives of the other roles. That mostly requires leadership, not rotations. This rotation does not serve customers. .02
- thr0wawayf00 4y ago
  > It is great (transformative even) for people in these roles to be able to take perspectives of the other roles. That's pretty much the point of the piece, and I disagree, one can't truly gain the perspectives of other roles until they take the time to do those roles themselves. Whenever I want to look for low-hanging fruit that improves efficiency in an org, I start talking to CS/CX.
  - ergonaught 4y ago
    Information exchange ("talking to them") is vital, but directly performing the role simply isn't necessary (however valuable it might be to try it sometime). If it were necessary to directly do a thing in order to gain the perspective, we wouldn't have fiction or pretty much anything else. Brains that cannot perform this function will not successfully perform Success or Support roles, underscoring the point. :)
- deleted 4y ago
  [deleted]
jasonladuke0311 4y ago
Though my time in customer success was integral to my career trajectory,I disagree with the premise. I simply would not have gotten where I am (nothing impressive, I assure you) without that experience, but not everyone should have to go through that.
commandlinefan 4y ago
> as engineers we can better prioritise work that has an impact When and where do engineers prioritize anything? Everywhere I've ever worked has had a task queue (these days its JIRA, but it was always something) that were prioritized by almost anybody except a programmer.
- Hackbraten 4y ago
  More often than not, you do have a say in prioritization as an engineer. But that won’t happen unless you speak up.
  - sharemywin 4y ago
    And have a convincing argument.
- jesuscript 4y ago
  It’s a new job that software provides. There is now a bug curator (usually non technical) that serves almost like an account manager for a client. They are in the middle. Usually, developers would prioritize based on the frequency of certain bugs. The faux account manager might prioritize by importance of the client.
- throwawaysleep 4y ago
  Yeah, I suppose it depends on the org, but engineering is really execution only in many places. We get told which tickets to work on by someone who does make those decisions, work on them, and get new tickets. I like it as it means I don’t need to pay attention in meetings :). Context isn’t my job.
- deleted 4y ago
  [deleted]
flamebreath447 4y ago
I’ve done this at my current company. They ask us to join sales calls or support engineer calls and read the filed ticket before hand. It is very useful to understand how a customer thinks and how they view features vs bugs. Sometimes you can help them distinguish that something is working as intended (due to time constraints or scope creep). The one part that I didn’t like is that some customers are just assholes, plain and simple. You will inevitably meet customers who say some obtuse things over an email as if it’s Facebook and there’s no accountability to their words. I’ve even heard it over video calls but much less frequent. After a few calls I asked to no longer do it because it made me lose empathy for the customers. Thank God for infrastructure work is all I can say.
sharemywin 4y ago
One thing I'm not seeing in the discussion is usually the customers start by-passing support all together and you end up with that guy that gets like a million emails and doesn't have time to do his normal job.
sharemywin 4y ago
How do you make sure the developers are trained to handle support. Sorry, that feature isn't scheduled to happen anytime soon. What happens if the customer blows up at the developer.
roberthahn 4y ago
I am very much in favor of putting engineers on customer support/success. I believe it is important to develop empathy and understanding of the user's experience with the product you build. Not only will it help you implement what they need, it will also serve as a way to call BS against product managers who try to get you to build things that look good on their resume (but don't help the customer. But after reading through the comments from those who are against the idea, I wonder if there might be a productive middle ground - have engineers listen in on (but not participate in) any calls between the customer and the Support/Success team. This doesn't need to be done for a solid week, but perhaps a steady diet of 2 calls per week for a few weeks would help. I'm sure you could imagine other 'middle-ground' ways to achieve this - but clearly nothing will work until engineers at a minimum buy into the reasons why some direct exposure to customers would be a good idea.
marssaxman 4y ago
What is "customer support and success"? Is this just a new euphemism for "customer service" or is there something else going on here?
forgotmypw17 4y ago
I remember reading/hearing about a company (or several) where every employee was required to spend a few hours here and there on support. I think this is the right way to go about it.
deleted 4y ago
[deleted]

108 points by 0xferruccio 4y ago

Why it is isn't the other way around? Customer support should start learning SWE and UX/UI. UX/UI people should learn SWE and customer support. Why this expectation only for SWE?

feintruled 4y ago

Great idea until an engineer tells a customer they aren't prioritizing that bug because it's too hard to fix and they aren't a major customer.

wildrhythms 4y ago
The salespeople and managers already do that today.

pier25 4y ago

That's the wrong way to approach the problem. The problem is not about engineers doing support but about the whole company being aware of the real customer needs and experience with the product.

deleted 4y ago
[deleted]
throwawaysleep 4y ago
It’s irrelevant for engineers to know. We don’t make product decisions.

erellsworth 4y ago

Well--well look. I already told you: I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?

hellisothers 4y ago

I worked at a company that mandated this, I’m sure management thought it sounded great but it felt lazy on the part of Product/Management. Is deploying an an engineer to field support tickets really the best use of their time? How about Product and Management field tickets and distill from that what is most impactful for engineering to work on.

RandallBrown 4y ago
I worked at a (mostly retail) company that had us not only answer the emails about our app but had us answering emails for all customers, including processing refunds and returns. At first it felt like a pretty huge waste of time, but it was a great way to get to know our customers better. Eventually our app team started just handling the app emails because the knowledge was a bit too specialized for the non app team members. Our team was small so we handled most of the product/management decisions on our own. It was a little annoying sometimes, but it was generally pretty awesome.

jackblemming 4y ago

Yep they should also do frontend, backend, dev ops, security, and on-call. Hey why dont we throw in project management and product management while we're at it. And it's not like those UI/UX people do much either, so let's just make the devs do that too. Finally to wrap it all up we'll have like 5 mandatory meetings a week to check in on them.

ls15 4y ago
While they are at it, they could also get new coffee beans for the machine, clean the toilets and do some sales so we can get rid of the dedicated roles for that.
- autotune 4y ago
  One of the downsides of work from home being the new norm is that has already become part of the job.
  - Beached 4y ago
    coffee is much better now though :)
- _jal 4y ago
  If you empty the coffee machine, hell yes you better refill it. Or do you have a valet where you work?
  - ls15 4y ago
    I wouldn't trust an engineer with my coffee.
uri4 4y ago
Devs should also do HR, project management, CEO... I do all of that stuff. But at my own company for myself...
pjmlp 4y ago

paxys 4y ago

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.

jahewson 4y ago
Wontfix: User error.
- justinjlynn 4y ago
  "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."
  - lucasyvas 4y ago
    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.
Areading314 4y ago
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.

efficax 4y ago

i completely agree. the best product work i've done was at a company that had engineers spend 1 hour a week answering customer support tickets. you get to know the customer and how they use the product intimately, and you get to know aspects of the product itself that you normally might not touch, just by trying to solve a customer problem. plus, there is no better feeling than getting a customer complaint that you realize right away is a 10 minute bugfix, making the change, deploying the code and emailing them back that the problem should be resolved. really satisfying and morale boosting.

markmark 4y ago

I worked at a small company where Engineering rotated through support. There was some value in it, but also it sucked doing it and there were other companies out there with interesting work, good pay and _not_ asking you to do support. It was absolutely part of the reason I left. Admittedly the company was small and you were doing support a lot (up to one week a month depending on team). Something more like one week every six months would have given you the customer visibility benefits without all the engineers absolutely hating it.

bee_rider 4y ago
When I was an undergrad, we ordered parts for some project and it turned out there was a Real Live Engineer in customer service. I guess that wouldn't be as impressive in a business-to-business context, but it impressed the heck out of us.

ultrasaurus 4y ago

Sigh. I wish this worked. Maybe we'll get to a point where AI handles a lot of the rote issues but until then, a lot of support is things like routine billing questions or even spam. Even if there is a meaty usability problem, there's no reason that it should be prioritized just because an engineer caught 1 ticket about it vs something that happened 100 times to regular support To make it work, you need to have it be part of the onboarding or there's an engineering rotation of who's on-call to help with support escalations.

ano88888 4y ago

The best way to do it is dont let your enginners do support but expose them to customers pain points and complaints.

trap_goes_hot 4y ago
For most humans, experiential learning/knowledge hits us differently than just reading a wall of text/bullet point list. For me personally, I started incorporating a mental model of real people who struggled to use a feature that I had previously developed.

coding123 4y ago

I've noticed this dark pattern on sub stack where you get to read the first page and then gotcha... It really sucks.

semireg 4y ago

As a solo developer I don’t have much non-obvious stuff to add, but I will say handling 100% email and phone(!) support for my business-focused electron app makes me relentlessly write guides/FAQs and polish UX. I’m guessing I’ve reduced support requests by 90% while growing the business 1000% which leaves me about as busy with support but with much more revenue. My goal is to do keep doing this… for how long, I don’t know. I’m 50% terrified of losing touch with customers and 50% wishing for an amazing support helper to pop out of the woodwork and start answering tickets.

tothrowaway 4y ago
I'm in a similar boat. But try as I might, I have yet to find a solution for the "I forgot the email address I registered with, and I am too nervous/confused/unimaginative to try my other email addresses, nor will I click the 'Trouble logging in link?' to help myself, so I'll send you an email from an address you have no record of (using my maiden name), while providing no further information to help identify myself, demanding that you tell me my credentials" people. I get just the right amount of these emails so it's not worth hiring someone for, while still enough to drive me nuts. I wish there was a support-as-a-service company that had non-outsourced employees (not contractors) and charged per-minute (or 6 minutes) for support, with some fixed cost for training them how to use your app, and handle basic support questions.
- club_tropical 4y ago
  You could consider getting rid of such customers in some systematic way. Not everyone is worth it; curated customer base can save a lot of headache. And pretty cool startup idea on the small-scale Support aaS thing.
- austinjp 4y ago
  I kiiiinda agree with sibling comment about getting rid of such customers, although obviously doing it in a way that doesn't piss people off :) First, though, you need a way to distinguish toxic users from others. This is useful because it reduces the decision-making cognitive burden to nearly zero. You can also explain it to colleagues if/when you have them. Suggestion: Keep a tally or produce an estimate of what it "costs" you to service the customers who piss you off. Compare it with time lost, work you could have been doing, impact on your mood, etc. There's no simple formula but you could get a basic metric with some imaginative plugging of guesstimates into a spreadsheet. I wonder if there's a way for you to foster users supporting users? A community forum perhaps? Obviously these can become toxic too, with entitled users spreading rancour. Strong moderation might work, by you and users you elevate to admin status. Sure, forum moderation may take up your time, but it might be simpler than per-user emails (or whatever). Community fora aren't magic bullets, but good examples exist. Just a thought! :)

acjohnson55 4y ago

This certainly can work, especially in the earliest days, when you have very product-minded and entrepreneurial engineers. But once you start growing past that founding team, you probably end up with engineers who will burn out if they have to do this, or otherwise you are limiting your engineering talent pool to people who are excited (or tolerant) to work this way. It also becomes a problem when the engineering org begins to split into teams and individual engineers no longer work with the entire customer experience. I would suggest thinking of the results you want to achieve and figuring out what's the most efficient way of getting there. If it's understanding the customer pain points, can you do it by shadowing support periodically, in lieu of actually doing support?

NAHWheatCracker 4y ago
I agree that a lot of engineers would be put off if they had to do this. The problem I see is managers - project, product, and engineering - who think engineers shouldn't be doing this stuff. Whether the engineers are product-minded isn't considered. Sometimes a PM sees the engineer interacting with users as a sort of intrusion on their domain. Other times an EM thinks they're saving cycles by keeping engineers away from the "non-productive" work of interacting with users.

mkl95 4y ago

This is a bad idea unless you are paying really well. I would even consider taking a small pay cut to run from a place that forced me to do that stuff. Instead of fixing those problems like a donkey, you should fix your database schema and data inconsistencies. Increase observability and monitoring budgets and whatever tooling is needed, so engineers know what is breaking and where before customers find out. I want to work at places that are one step ahead of their users, not the other way around.

bilekas 4y ago
> I would even consider taking a small pay cut to run from a place that forced me to do that stuff. There is something wrong with taking a paycut to not do work that's not in your job description. I wouldn't settle for this.

nxpnsv 4y ago

That is as arrogant as saying: "customer support and success teams should do the engineering". Engineers really should do engineering, it does helps if they have some idea about other stuff of course.

keithnz 4y ago

no "should". Maybe if your company is having problems with support requests MAYBE it might be useful to get engineers involved, maybe they will notice some kind of problem with the right information getting to engineering or something going wrong with prioritization of what to build. But then again, getting other roles in the company involved with support MIGHT also find what the issues are, it might be just the engineers need to talk with support to find out what they think.

faangiq 4y ago

In a real tech company, engineers should do everything. There’s no need for non engineers.

jehb 4y ago
What does it say about the state of our industry that I can't tell if this comment is trolling or a genuine belief?

bmitc 4y ago

Suddenly a lot of "this is working as designed" will start showing up in the resolution field.

TheCapeGreek 4y ago

I agree with paxys here that this is generally not a great idea for most orgs. IMO The better approach is for engineers to be on a rotation to support customer success teams. Unless CS somehow has every tool they need to solve all customer queries, they'll still need to divert to a technical expert if they encounter issues or need system updates that they can't action (whether due to permissions or lack of admin panel functionality).

cplusplusfellow 4y ago

Just stop trying to make developers solve 100% of your problems since they already solve 99% of your problems.

gigatexal 4y ago

Totally agree. Helps these engineers have empathy for their users. I once worked with a staff level engineer on the team was on. He lead that team. He said many times: “I don’t care about users. I care about the code. The code has to be perfect.” Yikes.

faeriechangling 4y ago

DevSecOpsSupport

boomahora 4y ago

I think a clearly summarized report on key issues and takeaways each month can deliver the same result.

tlogan 4y ago

And what is role of product managers then? What should they do? The idea of product managers to be cross functional team between sales, support and engineering. Sure you can make engineers to do sales too: but you will end up with product managers. Anyway I 100% understand the point here: in small teams you don’t have so many roles. An engineer who is good engough in support and sales will become product managers (in future). Or support guy who understand code and feels the sales. I think that is a valid approach to grow.

bergenty 4y ago

It’s probably a good idea but if I were a software engineer I wouldn’t want to do all that work. Sure one person doing everything would be great because you’ll understand every part of the business but as a salaried employee no thank you. I’m also wary of doing any job that isn’t specifically in the jd because inevitable when there is a crunch you will be called on to do it again.

ericbarrett 4y ago

The job that started my tech career was in tech support. It was for a storage company in the very early 2000s. I ended up becoming a technical account manager, then went to a startup where I continued the role but also got into light sustaining engineering (digging for kernel bugs using core files uploaded by customers). It was incredibly informing. I learned so much about people, and process, and business that I never would have seen on the pure developer side. For the last 15 years I've had a fruitful career as a storage engineer, devops, and in cloud development. I owe my career, my debugging skills, and my understanding of business to those first roles in support. I'd never do it again.

MisterSandman 4y ago
That last line got me, haha.

biehl 4y ago

I am a fan of having some element of the team and solution architect also do the support. It is useful for aligning incentives, and it kills some of the risky and useless refactorings that a "sheltered" engineering team can be tempted to do..

ChicagoDave 4y ago

Engineers talking to customers? I’ll wait for that freight train to ram straight through a Prius. No two groups should remain further apart.

goodpoint 4y ago

LOL, no.

GiorgioG 4y ago

And DevOps, QA, and while we’re at it project management too. We’re spending far too little time writing code these days.

throwaway0asd 4y ago

In my full time job I am a senior software engineer and in my part time job I am an IT director that deals with customer support, so I already do this. Here is my perspective: * Nobody really knows what the technical people do. Something with electrons… The IT people don’t own your coffee pot or the power station. At some point this willful ignorance (maybe stupidity) becomes a self justifying excuse for the IT people to carry your water. * Developers are (far more commonly than naught) not interested in the customer experience. This becomes painfully obvious when you watch developers throw away benchmarks and performance measures. What’s most important, the majority of the time, is a developers pet framework. Developers will twist themselves into knots forming all kinds of illogical bullshit arguments to qualify a knowingly (measurably) bad tool that harms the customer experience.

ivanhoe 4y ago

This is perhaps doable in a very early stages where the team is just a few people and there's little tickets and customers, and perhaps the customers are also tech ppl/early adopters, so they'll appreciate talking to someone who knows all the details - but as soon as you grow a bit this becomes just unsustainable. First, engineers cost a lot of money. IME 90% of support tickets quickly boil down to a few same questions repeated over and over, and with a proper knowledge base in place anyone can answer them. You certainly don't want to pay engineers to do it. Second engineers hate dealing with customers because most of those problems are stupid and repetitive. You'll be both loosing money and employees. If there's an unknown issue, then escalate it to the engineers, but let someone less skillful/easier to replace do the triage first. That said, you definitely want your support to have technical/domain skills, because nothing is worse for a customer than realizing that you talk to a person who knows less about the app than yourself, and keeps sending you back the predefined template answers, just wasting your time. I left more than one SaaS because of such (lack of real) support. So put your interns/juniors there for onboarding. They'll learn a lot about the app, customers will get good support, win-win.

belter 4y ago

I know of a well known software company, producing enterprise integration software, who once got a major escalation. A large deal of several million dollars was in jeopardy. A decision was made, to send onsite to the complaining customer, the lead software engineer who originally coded their enterprise broker. His role was not disclosed, just another helpful consultant...Being sent on site to help stabilize the project. Feedback from the customer: "Please send us another person. This one did not seem to know much about the product..."

rrgok 4y ago

I didn't the whole article, but just reading the title has been enough to make me raged. I'm sick of it. I'm sick and tired of people expecting Software Engineers to do other non-related activities. Am I the only to think that the activities a SWE should do are design/devise (as in code), implement and test. That's it. What color Mary likes and whether Jack agrees with, it is not my concern. Likewise, it is not my concern listening customers and giving them support.

deleted 4y ago
[deleted]

jiggawatts 4y ago

Talking to the end-users has been, for me, the most enjoyable and productive part of developing software. Conversely, it frustrates me to no end that it's basically impossible to communicate my issues as an end-user to the only people that can actually fix it... the developers. A random example of the former scenario: I was once having home-made muffins for morning tea, baked by the lovely old ladies working in the support centre. I had developed a GUI support console for them. While chatting away, I noticed (and they complained) that looking up customer contact details was time consuming. Most developers stick within their "vertical stovepipes" and would never dream of pulling in data from unrelated systems managed by other teams. Getting contact data from an LDAP directory is "just a query" however and takes minutes to whip up. I added this feature by lunch time, and walked back to the support centre and demoed this. This cut wasted time for half a dozen people in half. A trivial bit of code that eliminated mindnumbing labour, allowing these people to help other people faster and better. As a converse example: I can take apart a commercial product and diagnose the key flaws in mere hours. I'll tell you every fundamental flaw you've made, and the list the trivial fixes that would make your customers jump for joy. Generally speaking, I'm not permitted to do so. Just like how most of my customers weren't permitted to speak to me, and a few lucky ones only got the chance because they happened to be within walking distance and were generous with their muffins.

ckdarby 4y ago

Developers should watch customer care calls via Gong, but not do the actual calls. Could you imagine if we said that customer support and success should do development?

mikkergp 4y ago
> Could you imagine if we said that customer support and success should do development? What’s wrong with this idea? in fact I have said this, though the context was technical b2b open source where familiarity with the code is part of the job of CS.”

potatohead00 4y ago

People need empathy for the customer. One possible way to do that is mix up roles but like many other commenters have pointed out, that may not always be the best use of their time. At a minimum, the devs should have regular updates, even anecdotal user stories about frustrating experiences. Perhaps if there are feedback loops customer context is getting removed from it either via unintended optimization or normal 'corporate telephone' .

q-big 4y ago
> People need empathy for the customer. One possible way to do that is mix up roles but like many other commenters have pointed out, that may not always be the best use of their time. Rather: if you want your developers to become deeply misanthropic and hateful of the users/customers, let your developers do user support.

raygelogic 4y ago

it's really interesting how polarizing of an issue this is with engineers. I definitely think it's a good idea, but you can really mess it up royally with bad implementation (plus there are scaling considerations). considering how polarizing it is though, it might be one of the best signals to attract the kinds of engineers who care about how their product is used. actually I think the best targetting is for all engineers to play a support role with their stakeholders, whoever they may be. devops supporting with full-stacks, data eng working with DS, (these already happen), and UX working with the masses.

ergonaught 4y ago

No. 1) Humans don’t scale. I assume that’s self-evident. 2) Humans actually aren’t interchangeable pieces. Very, very few people can perform good work in each of those domains. Even fewer can rotate roles like that. Those unicorns are rarely employees. 3) Companies can begin like that (I have been through this kind of role evolution) because there is work to be done and insufficient staff to do it, and the roles split off when growth demands and rewards specialization, but see above, goto 1. It is great (transformative even) for people in these roles to be able to take perspectives of the other roles. That mostly requires leadership, not rotations. This rotation does not serve customers. .02

thr0wawayf00 4y ago
> It is great (transformative even) for people in these roles to be able to take perspectives of the other roles. That's pretty much the point of the piece, and I disagree, one can't truly gain the perspectives of other roles until they take the time to do those roles themselves. Whenever I want to look for low-hanging fruit that improves efficiency in an org, I start talking to CS/CX.
- ergonaught 4y ago
  Information exchange ("talking to them") is vital, but directly performing the role simply isn't necessary (however valuable it might be to try it sometime). If it were necessary to directly do a thing in order to gain the perspective, we wouldn't have fiction or pretty much anything else. Brains that cannot perform this function will not successfully perform Success or Support roles, underscoring the point. :)
deleted 4y ago
[deleted]

jasonladuke0311 4y ago

Though my time in customer success was integral to my career trajectory,I disagree with the premise. I simply would not have gotten where I am (nothing impressive, I assure you) without that experience, but not everyone should have to go through that.

commandlinefan 4y ago

> as engineers we can better prioritise work that has an impact When and where do engineers prioritize anything? Everywhere I've ever worked has had a task queue (these days its JIRA, but it was always something) that were prioritized by almost anybody except a programmer.

Hackbraten 4y ago
More often than not, you do have a say in prioritization as an engineer. But that won’t happen unless you speak up.
- sharemywin 4y ago
  And have a convincing argument.
jesuscript 4y ago
It’s a new job that software provides. There is now a bug curator (usually non technical) that serves almost like an account manager for a client. They are in the middle. Usually, developers would prioritize based on the frequency of certain bugs. The faux account manager might prioritize by importance of the client.
throwawaysleep 4y ago
Yeah, I suppose it depends on the org, but engineering is really execution only in many places. We get told which tickets to work on by someone who does make those decisions, work on them, and get new tickets. I like it as it means I don’t need to pay attention in meetings :). Context isn’t my job.
deleted 4y ago
[deleted]

flamebreath447 4y ago

I’ve done this at my current company. They ask us to join sales calls or support engineer calls and read the filed ticket before hand. It is very useful to understand how a customer thinks and how they view features vs bugs. Sometimes you can help them distinguish that something is working as intended (due to time constraints or scope creep). The one part that I didn’t like is that some customers are just assholes, plain and simple. You will inevitably meet customers who say some obtuse things over an email as if it’s Facebook and there’s no accountability to their words. I’ve even heard it over video calls but much less frequent. After a few calls I asked to no longer do it because it made me lose empathy for the customers. Thank God for infrastructure work is all I can say.

sharemywin 4y ago

One thing I'm not seeing in the discussion is usually the customers start by-passing support all together and you end up with that guy that gets like a million emails and doesn't have time to do his normal job.

sharemywin 4y ago

How do you make sure the developers are trained to handle support. Sorry, that feature isn't scheduled to happen anytime soon. What happens if the customer blows up at the developer.

roberthahn 4y ago

I am very much in favor of putting engineers on customer support/success. I believe it is important to develop empathy and understanding of the user's experience with the product you build. Not only will it help you implement what they need, it will also serve as a way to call BS against product managers who try to get you to build things that look good on their resume (but don't help the customer. But after reading through the comments from those who are against the idea, I wonder if there might be a productive middle ground - have engineers listen in on (but not participate in) any calls between the customer and the Support/Success team. This doesn't need to be done for a solid week, but perhaps a steady diet of 2 calls per week for a few weeks would help. I'm sure you could imagine other 'middle-ground' ways to achieve this - but clearly nothing will work until engineers at a minimum buy into the reasons why some direct exposure to customers would be a good idea.

marssaxman 4y ago

What is "customer support and success"? Is this just a new euphemism for "customer service" or is there something else going on here?

forgotmypw17 4y ago

I remember reading/hearing about a company (or several) where every employee was required to spend a few hours here and there on support. I think this is the right way to go about it.

deleted 4y ago

[deleted]