Engineers should do customer support and success
notoriousplg.substack.com
notoriousplg.substack.com
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.
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, 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. 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.
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.
Or do you have a valet where you work?
I do all of that stuff. But at my own company for myself...
At least I know for sure that kids in school clean their own school.
Maybe someone from Japan can chime in.
The truth is, nobody who make an effective company did it because they cleaned the toilets or knew the janitor’s name. They might do those things strategically / instinctively almost with the sole purpose of conspicuous virtue signaling.
I don't understand this sense that everything positive people do is actually negative.
Part of being a good leader is _acting_ like a good leader. You can't be the type of leader who makes people feel special by remembering their name if you don't actually remember anyones name. That means rolling your sleeves up every once in a while. At a 221,000 person company like Microsoft? Ok, maybe that's not accomplishing much(unless the CEO caused the poop-splosion, then it's just good manners) but at a 50 person warehouse? Yeah, sometimes you take on some shitty work. Maybe, every once in a while the CEO is _actually_ the best person to do it. A CEO can strategize while plunging a few toilets, a line worker can't work the line when theyre doing it.
Not knowing the janitor’s name != not knowing your employees’ name; this is false equivalency. The janitor is not part of your employment or business. “Rolling your sleeves” in a 50 person warehouse might look like keeping up with your forklift skills to evaluate new equipment or whatever, not cleaning the toilets.
We have a full time product designer though as doing user interviews is time consuming and hard to do with the routine of an engineer.
> they should also do frontend, backend, dev ops, security, and on-call
this is exactly what a full stack in a small- to mid-sized team does. all things dev + on-call rotations.
> why dont we throw in project management and product management while we're at it
this has been a collaborative effort on most of the teams i've been on, even with a dedicated PM
> it's not like those UI/UX people do much either, so let's just make the devs do that too
in my experience design output from an engineer with junior-to-mid design experience is more successful than that from most mid-to-senior designers without engineering backgrounds
> we'll have like 5 mandatory meetings a week to check in on them
you're bothered by your job checking in once a day during the work week?
It may surprise you, but I do all the things I described for my own company and I keep all the money I make from it. I would never expect someone I hired as a developer to do everything I do, for likely peanuts compared to what I make. But I guess this is how some devs want to be treated. More responsibility isn't always a good thing.
i agree entirely with the substance of your post and don't understand how it conflicts with the substance of mine. i hold to the same standards i laid out whether i'm working for a boss or working with a co-op or other worker-self-directed group
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.
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.
And pretty cool startup idea on the small-scale Support aaS thing.
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! :)
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.
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.
Usually, developers would prioritize based on the frequency of certain bugs. The faux account manager might prioritize by importance of the client.
I like it as it means I don’t need to pay attention in meetings :). Context isn’t my job.
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.
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..."
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.
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
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.
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?
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.
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.
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.
* 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.
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.
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.”
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.
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' .
Rather: if you want your developers to become deeply misanthropic and hateful of the users/customers, let your developers do user support.
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).
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.
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.
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.
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.
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.
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.
I think this is the right way to go about it.