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.
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.
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.
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.
I’ve heard it, too, of course. It is gaslighting. The tyranny of constantly having to signal worship of humility and countersignal pride and pursuit of distinction.
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.
I do not consider the CEO knowing the janitor’s name or cleaning toilets a “positive thing”. It is a vacuous action explicitly made for virtue signaling. No CEO ever quietly plunges toilets and actually thinks this is helping him stay in touch with the business.
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.
your comment describes an interdisciplinarian with basic communication skills, which is exactly the type of engineer most teams should be looking to hire, even if only to strengthen collaboration between dedicated design, engineering, and product functions
> 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?
From the sound of your post, you seem to enjoy the ever increasing set of responsibilities tacked onto the "fullstack" title. Many do not. Especially because pay does not seem to increase at the rate new responsibilities are added. But if you enjoy making your boss richer for no increased pay, have at it.
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.
a broader set of responsibilities doesn't necessarily equate to more work. in my experience there's no correlation at all between the scope, intensity, and exploitativeness of work
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
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.
"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.
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.
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)
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.
> 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 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.
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
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'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.
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.
> 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:(
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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! :)
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?
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.
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.
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.
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.
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).
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.
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.
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.
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 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..
138 comments
[ 32.1 ms ] story [ 3237 ms ] threadAt 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.
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
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.
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.
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.
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! :)
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.
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).
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.
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.
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.