6 ms·

This exists in almost every company by design. Engineering teams wouldn't make any progress towards their mission if they are constantly dealing with outside in

This exists in almost every company by design. Engineering teams wouldn't make any progress towards their mission if they are constantly dealing with outside interruptions, but at the same time there are things which should be qualified. Customer support is a cost center and the focus is on mitigating the cost of providing that support. If you fail to do this you can burn through a lot of cash quickly. What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent. It's important for at least the following to happen: 1. Bad issues that engineering will fix don't get stuck in support. 2. Product management review and respond to feature requests, or enable support to respond to customers. 3. Support have a reasonable level of technical and communication skill, and are empowered to answer for the company. 4. The organization works through rather than around support. What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size. Your role as the back channel is helping to provide some coherence here. However, things can go bad if you left. Inevitably, this is the fault of the company, but when I've found myself in this position I've tried to "promote" people in support to take the lead on this role. Further, formalizing the special request process to be minimally tracked helps visibility with my manager and others. Eventually managers ask why you have become a gopher. Improving the workflow often involves helping support build relationships with engineering. Management can buy in if support attrition is high (it often is if there is a limited career ladder for support) and it can also improve their perception when people are focused on trimming support cost.

coliveira 6y ago
The biggest problem we have in software engineering is the lack of support staff. You don't think a civil engineer has to deal with minutiae of paperwork, but software engineers for some strange reason think it is ok to be inundated by clerical work all the time. The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc.
- techsupporter 6y ago
  > The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc. In my opinion, we had this. They were your senior support staff or were operations; some companies combined this into a formal role called "Support" or "Service" "Operations." But then we as an industry decided that operations is bad[0] and if you write the code then you can obviously test the code, deploy the code, maintain the code, and support the code. Then every Hip And Cool Start-Up adopted the model of "sysadmins and support staff are bad because we've had bad experiences in the past so we will also have our devs talk directly to customers until they get tired of doing that and we just replace it with a contact form encumbered by CAPTCHA and a no-reply e-mail address." As someone who has greatly enjoyed, been very good, and very well paid (so my employers agreed that I was good at it), at support and operations roles only to see them disappear into the inky void of Everyone Codes All Of The Time, I am both biased and frustrated. 0 - Because money, I suspect.
  - coliveira 6y ago
    I think this is an indictment of the lack of organizational skills in the area of software engineering. It is still an industry run by the sit of their pants. There is no clear separation of responsibilities and everyone wants to do everything (and usually badly).
  - tylerfontaine 6y ago
    There are still lots of good support organizations out there, and not every place looks at support as a burden. It's a pretty critical piece in the "new" 'as a service' world, helping folks use complex systems that they don't control, etc. I've been heavy in the data space, and get to do some fascinating work with folks, helping design data models, implement analysis, and other things in a wide variety of verticals. It's support, so sometimes there's some more tedious things too - there's no avoiding that. :) But, and perhaps I'm biased, it's still a great career path, even if it's not as flash as "code all the time" work.
- duxup 6y ago
  It's funny you mention that. I was a support drone when I was in the situation I described above. But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles. When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).
jkaptur 6y ago
The binary distinction between "cost centers" and "profit centers" has always seemed arbitrary to me (especially since, as an engineer, I've been in both without my work being substantially different). To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be." It seems like this leads to incredibly predictable problems: brain drain, demoralized workers, the bare minimum being aimed for and not actually being achieved, etc. I feel like a better organization has no "cost centers" - every single role at the company contributes to the mission and to the bottom line. If they didn't, that position wouldn't exist. What am I missing?
- noizejoy 6y ago
  x% of support requests are of questionable nature - to mention just a few categories: * people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training) * people unwilling to RTFM, google, youtube, etc. * people whining when a general purpose tool doesn’t fit their exact workflow to a tee
  - ddingus 6y ago
    Those are all sales and service opportunities, BTW. Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads. Fact is, people do what they do and they have their reasons. Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does. Net happiness goes up too. True for the enterprise and users, people at large.
    - noizejoy 6y ago
      Not all sales and service opportunities have positive ROI
indymike 6y ago
There is a fine line between running interference and sales prevention.
duxup 6y ago
Yup that's accurate. I was a regular old support drone who had some connections that allowed for some special paths to engineering. We had 'official' faster escalation paths but those inevitably are determined by $$$ and there's always more ways to measure 'important customer' than can be defined / shown in $$$. Management was totally aware of it all and supportive. But eventually I got tired of the land of 'support' and moved on for a variety of reasons, mostly because time and again I saw support treated like the usual 'cost center' and I didn't want to be a part of that.
magicalhippo 6y ago
> Customer support is a cost center For us, great customer support is one of our stronger sales arguments. In fact we've not had to push hard on sales due to our customers calling former colleagues who moved to a competitor to tell them "you have got to get this software". Having great support has been key to this experience. Most of our support people have been recruited from our customers, so they know not just our software well but the processes and regulations around it, allowing them to quickly understand the issue at hand and offer relevant help. So while it might look like a cost center on paper, I'm quite certain it's a massive net gain overall. Of course as you say, we work hard to mitigate the cost of providing that support, like routinely looking at implementing changes that'll reduce repeat support issues. Maybe as simple as reworking a dialog text, to adding more automation.
cosmie 6y ago
> What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent. > What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size. The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane. You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent. ... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it. An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.
InfiniteRand 6y ago
In my company, there is a blurriness between support and technical sales, and while that can be a little chaotic, one benefit of that approach is support is looked at as a profit center to a degree. This is because the support people keep an eye out on upselling, maintaining subscriptions, and promoting consulting work. We're not obnoxious about it, but there's some awareness that part of the role of support is to promote the long-term growth of the customer relationship and sales. I think if there was a stricter division between support and technical sales, there would be more of a temptation to focus on burning through support requests as quickly as possible. The flip side of this is that it is easy for us to get bogged down in a complex half-support half-sales opportunity situation and that can sometimes cause other support requests to fall through the cracks.

coliveira 6y ago

The biggest problem we have in software engineering is the lack of support staff. You don't think a civil engineer has to deal with minutiae of paperwork, but software engineers for some strange reason think it is ok to be inundated by clerical work all the time. The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc.

techsupporter 6y ago
> The industry eventually must evolve to create software assistants capable of running code, triaging bugs, etc. In my opinion, we had this. They were your senior support staff or were operations; some companies combined this into a formal role called "Support" or "Service" "Operations." But then we as an industry decided that operations is bad[0] and if you write the code then you can obviously test the code, deploy the code, maintain the code, and support the code. Then every Hip And Cool Start-Up adopted the model of "sysadmins and support staff are bad because we've had bad experiences in the past so we will also have our devs talk directly to customers until they get tired of doing that and we just replace it with a contact form encumbered by CAPTCHA and a no-reply e-mail address." As someone who has greatly enjoyed, been very good, and very well paid (so my employers agreed that I was good at it), at support and operations roles only to see them disappear into the inky void of Everyone Codes All Of The Time, I am both biased and frustrated. 0 - Because money, I suspect.
- coliveira 6y ago
  I think this is an indictment of the lack of organizational skills in the area of software engineering. It is still an industry run by the sit of their pants. There is no clear separation of responsibilities and everyone wants to do everything (and usually badly).
- tylerfontaine 6y ago
  There are still lots of good support organizations out there, and not every place looks at support as a burden. It's a pretty critical piece in the "new" 'as a service' world, helping folks use complex systems that they don't control, etc. I've been heavy in the data space, and get to do some fascinating work with folks, helping design data models, implement analysis, and other things in a wide variety of verticals. It's support, so sometimes there's some more tedious things too - there's no avoiding that. :) But, and perhaps I'm biased, it's still a great career path, even if it's not as flash as "code all the time" work.
duxup 6y ago
It's funny you mention that. I was a support drone when I was in the situation I described above. But support being support ... it is eventually devalued and I chose to learn to code to move out of those types of roles. When I moved on (through a somewhat handy acquisition and layoff and etc) some engineers reached out to me to join the support team there.... but I was done with support (and other factors).

jkaptur 6y ago

The binary distinction between "cost centers" and "profit centers" has always seemed arbitrary to me (especially since, as an engineer, I've been in both without my work being substantially different). To be frank, it seems like an organizational way to say "we don't find this work to be valuable or interesting, and we'd like to do the bare minimum of it - in fact, we'd like to unleash smart people to explore new frontiers of just how minimal the bare minimum could possibly be." It seems like this leads to incredibly predictable problems: brain drain, demoralized workers, the bare minimum being aimed for and not actually being achieved, etc. I feel like a better organization has no "cost centers" - every single role at the company contributes to the mission and to the bottom line. If they didn't, that position wouldn't exist. What am I missing?

noizejoy 6y ago
x% of support requests are of questionable nature - to mention just a few categories: * people expecting to use a sophisticated tool (for doing complex business processes requiring special know-how) without paying for and spending time on adequate training) * people unwilling to RTFM, google, youtube, etc. * people whining when a general purpose tool doesn’t fit their exact workflow to a tee
- ddingus 6y ago
  Those are all sales and service opportunities, BTW. Back in my support role for higher end software, I flat out hit numbers comparable to sales and generated a ton of great leads. Fact is, people do what they do and they have their reasons. Judging them and acting on that judgement by marginalizing an important and necessary part of the process has a higher net cost to the world, and often the enterprise, than just doing those things reasonably does. Net happiness goes up too. True for the enterprise and users, people at large.
  - noizejoy 6y ago
    Not all sales and service opportunities have positive ROI

indymike 6y ago

There is a fine line between running interference and sales prevention.

duxup 6y ago

Yup that's accurate. I was a regular old support drone who had some connections that allowed for some special paths to engineering. We had 'official' faster escalation paths but those inevitably are determined by $$$ and there's always more ways to measure 'important customer' than can be defined / shown in $$$. Management was totally aware of it all and supportive. But eventually I got tired of the land of 'support' and moved on for a variety of reasons, mostly because time and again I saw support treated like the usual 'cost center' and I didn't want to be a part of that.

magicalhippo 6y ago

> Customer support is a cost center For us, great customer support is one of our stronger sales arguments. In fact we've not had to push hard on sales due to our customers calling former colleagues who moved to a competitor to tell them "you have got to get this software". Having great support has been key to this experience. Most of our support people have been recruited from our customers, so they know not just our software well but the processes and regulations around it, allowing them to quickly understand the issue at hand and offer relevant help. So while it might look like a cost center on paper, I'm quite certain it's a massive net gain overall. Of course as you say, we work hard to mitigate the cost of providing that support, like routinely looking at implementing changes that'll reduce repeat support issues. Maybe as simple as reworking a dialog text, to adding more automation.

cosmie 6y ago

> What management needs to realize is that this is also an important interface point which requires attention. This doesn't happen at all, or is inconsistent. > What I've always found interesting, is that all of these are often failing in some way at the same time in an organization of any size. The formalization of it is frequently the cause of it failing or being inconsistent. Once it's a workflow that's explicitly acknowledged and condoned by management, it will start to lose its effectiveness. As an official express lane between customers and engineering, every account/sales person will become aware of it and overload it, either in the general course of supporting their client portfolio as much as possible, or even worse, by making this internal express route known to clients, as they can get incremental revenue by branding it as a "VIP Support" service or to make at-risk clients feel special. Which will eventually end up in actual client contracts in some form or another, opening the door to client abuse (or misuse) as well as causing legit cases that would have gone through this implicit channel to get routed to and trapped in normal support because the client at hand didn't pay up for the express lane. You've also replaced a channel built off of relationships and mutual trust/respect into one based on official responsibilities and inertia, and all the hazards that entails. Such as political/managerial turf wars that add friction to the process, as well as cost minimization efforts that deskill the role over time and profit maximization efforts that overwhelm the capacity of the role, alienating the engineering team and undermining the entire intent. ... not to say it's impossible. But that's generally why you'll see it failing in some capacity any time you witness it, because it's almost impossible to maintain equilibrium the moment you officiate it. An alternative that tends to be more lasting is for management to _actively facilitate organic growth_ of these sorts of things. Enable and encourage and provide opportunities for inter-departmental relationships and lines of communications to form. That way there is no single "back channel", and organic lines of communication between different parts of the org are robust against the loss of a single node.

InfiniteRand 6y ago

In my company, there is a blurriness between support and technical sales, and while that can be a little chaotic, one benefit of that approach is support is looked at as a profit center to a degree. This is because the support people keep an eye out on upselling, maintaining subscriptions, and promoting consulting work. We're not obnoxious about it, but there's some awareness that part of the role of support is to promote the long-term growth of the customer relationship and sales. I think if there was a stricter division between support and technical sales, there would be more of a temptation to focus on burning through support requests as quickly as possible. The flip side of this is that it is easy for us to get bogged down in a complex half-support half-sales opportunity situation and that can sometimes cause other support requests to fall through the cracks.